关于ios:无埋点核心技术iOS-Hook-在字节的实践经验

作者：字节挪动技术——段文斌

家喻户晓，字节跳动的举荐在业内处于领先水平，而准确的举荐离不开大量埋点，常见的埋点采集计划是在响应用户行为操作的门路上进行埋点。然而因为 App 通常会有比拟多界面和操作门路，被动埋点的保护老本就会十分大。所以行业的做法是无埋点，而无埋点实现须要 AOP 编程。

一个常见的场景，比方想在 UIViewController 呈现和隐没的时刻别离记录时间戳用于统计页面展示的时长。要达到这个指标有很多种办法，然而 AOP 无疑是最简略无效的办法。Objective- C 的 Hook 其实也有很多种形式，这里以 Method Swizzle 给个示例。

@interface UIViewController (MyHook)

@end

@implementation UIViewController (MyHook)

+ (void)load {
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        /// 惯例的 Method Swizzle 封装
        swizzleMethods(self, @selector(viewDidAppear:), @selector(my_viewDidAppear:));
        /// 更多 Hook
    });
}

- (void)my_viewDidAppear:(BOOL)animated {
  /// 一些 Hook 须要的逻辑
  
  /// 这里调用 Hook 后的办法，其实现其实曾经是原办法了。[self my_viewDidAppear: animated];
}

@end

接下来咱们探讨一个具体场景：

UICollectionView或者 UITableView 是 iOS 中十分罕用的列表 UI 组件，其中列表元素的点击事件回调是通过 delegate 实现的。这里以 UICollectionView 为例，UICollectionView的delegate，有个办法申明，collectionView:didSelectItemAtIndexPath:，实现这个办法咱们就能够给列表元素增加点击事件。

咱们的指标是 Hook 这个 delegate 的办法，在点击回调的时候进行额定的埋点操作。

通常状况下，Method Swizzle 能够满足绝大部分的 AOP 编程需要。因而首次迭代，咱们间接应用 Method Swizzle 来进行 Hook。

@interface UICollectionView (MyHook)

@end

@implementation UICollectionView (MyHook)

// Hook, setMyDelegate: 和 setDelegate: 替换过
- (void)setMyDelegate:(id)delegate {if (delegate != nil) {
        /// 惯例 Method Swizzle
        swizzleMethodsXXX(delegate, @selector(collectionView:didSelectItemAtIndexPath:), self, @selector(my_collectionView:didSelectItemAtIndexPath:));

    }

    [self setMyDelegate:nil];
}

- (void)my_collectionView:(UICollectionView *)ccollectionView didSelectItemAtIndexPath:(NSIndexPath *)index {
  /// 一些 Hook 须要的逻辑

  /// 这里调用 Hook 后的办法，其实现其实曾经是原办法了。[self my_collectionView:ccollectionView didSelectItemAtIndexPath:index];
}

@end

咱们把这个计划集成到今日头条 App 外面进行测试验证，发现没法方法验证通过。

次要起因今日头条 App 是一个宏大的我的项目，其中引入了十分多的三方库，比方 IGListKit 等，这些三方库通常对 UICollectionView 的应用都进行了封装，而这些封装，恰好导致咱们不能应用惯例的 Method Swizzle 来 Hook 这个 delegate。间接的起因总结有以下两点：

setDelegate传入的对象不是实现 UICollectionViewDelegate 协定的那个对象

如图示，setDelegate传入的是一个代理对象 proxy，proxy 援用了理论的实现 UICollectionViewDelegate 协定的 delegate，proxy 实际上并没有实现UICollectionViewDelegate 的任何一个办法，它把所有办法都转发给理论的delegate。这种状况下，咱们不能间接对 proxy 进行 Method Swizzle

屡次setDelegate

在上述图例中，应用方存在间断调用两次 setDelegate 的状况，第一次是实在delegate，第二次是proxy，咱们须要区别对待。

应用 proxy 对原对象进行代理，在解决完额定操作之后再调用原对象，这种模式称为代理模式。而 Objective- C 中要实现代理模式，应用 NSProxy 会比拟高效。具体内容参考下列文章。

代理模式
NSProxy 应用

这外面 UICollectionView 的setDelegate传入的是一个 proxy 是十分常见的操作，比方 IGListKit，同时 App 基于本身需要，也有可能会做这一层封装。

在 UICollectionView 的setDelegate的时候，把 delegate 包裹在 proxy 中，而后把 proxy 设置给 UICollectionView, 应用proxy 对delegate进行音讯转发。

计划 1 曾经无奈满足咱们的需要了，咱们思考到既然对 delegate 进行代理是一种惯例操作，咱们何不也应用代理模式，对 proxy 再次代理。

先 Hook UICollectionView的 setDelegate 办法
代理delegate

简略的代码示意如下

/// 残缺封装了一些惯例的音讯转发办法
@interface DelegateProxy : NSProxy

@property (nonatomic, weak, readonly) id target;

@end

/// 为 CollectionView delegate 转发音讯的 proxy
@interface BDCollectionViewDelegateProxy : DelegateProxy

@end

@implementation BDCollectionViewDelegateProxy <UICollectionViewDelegate>

- (void)collectionView:(UICollectionView *)collectionView didSelectItemAtIndexPath:(NSIndexPath *)indexPath {
    //track event here
    if ([self.target respondsToSelector:@selector(collectionView:didSelectItemAtIndexPath:)]) {[self.target collectionView:collectionView didSelectItemAtIndexPath:indexPath];

    }
}

- (BOOL)bd_isCollectionViewTrackerDecorator {return YES;}

// 还有其余的音讯转发的代码 先疏忽
- (BOOL)respondsToSelector:(SEL)aSelector {if (aSelector == @selector(bd_isCollectionViewTrackerDecorator)) {return YES;}

    return [self.target respondsToSelector:aSelector];
}


@end

@interface UICollectionView (MyHook)

@end

@implementation UICollectionView (MyHook)

- (void) setDd_TrackerProxy:(BDCollectionViewDelegateProxy *)object {objc_setAssociatedObject(self, @selector(bd_TrackerProxy), object, OBJC_ASSOCIATION_RETAIN_NONATOMIC);
}

- (BDCollectionViewDelegateProxy *) bd_TrackerProxy {BDCollectionViewDelegateProxy *bridge = objc_getAssociatedObject(self, @selector(bd_TrackerProxy));

    return bridge;
}

// Hook, setMyDelegate: 和 setDelegate: 替换过了
- (void)setMyDelegate:(id)delegate {if (delegate == nil) {[self setMyDelegate:delegate];
        return
    }

    // 不会开释，不反复设置
    if ([delegate respondsToSelector:@selector(bd_isCollectionViewTrackerDecorator)]) {[self setMyDelegate:delegate]; 
         return;
    }

    BDCollectionViewDelegateProxy *proxy = [[BDCollectionViewDelegateProxy alloc] initWithTarget:delegate];
    [self setMyDelegate:proxy];
    self.bd_TrackerProxy = proxy;

}

@end

下图实线示意强援用，虚线示意弱援用。

如果应用方没有对 delegate 进行代理，而咱们应用代理模式

UICollectionView，其 delegate 指针指向 DelegateProxy
DelegateProxy，被 UICollectionView 用 runtime 的形式强援用，其 target 弱援用实在 Delegate

如果应用方也对 delegate 进行代理，咱们应用代理模式

咱们只须要保障咱们的 DelegateProxy 处于代理链中的一环即可

从这里咱们能够看出，代理模式有很好的扩展性，它容许代理链一直嵌套，只有咱们都遵循代理模式的准则即可。

到这里，咱们的计划曾经在今日头条 App 上测试通过了。然而事件远还没有完结。

目前的还算比拟能够，然而也不能完全避免问题。这里其实不仅仅是UICollectionView 的 delegate，包含:

UIWebView
WKWebView
UITableView
UICollectionView
UIScrollView
UIActionSheet
UIAlertView

咱们都采纳雷同的办法来进行 Hook。同时咱们将计划封装一个 SDK 对外提供，以下统称为 MySDK。

某客户接入咱们的计划之后，在集成过程中反馈有必现 Crash，上面具体介绍一下这一次踩坑的经验。

重点信息是[UIWebView webView:decidePolicyForNavigationAction:request:frame:decisionListener:]。

Thread 0 Crashed:

0   libobjc.A.dylib   0x000000018198443c objc_msgSend + 28

1   UIKit             0x000000018be05b4c -[UIWebView webView:decidePolicyForNavigationAction:request:frame:decisionListener:] + 200

2   CoreFoundation    0x0000000182731cd0 __invoking___ + 144

3   CoreFoundation    0x000000018261056c -[NSInvocation invoke] + 292

4   CoreFoundation    0x000000018261501c -[NSInvocation invokeWithTarget:] + 60

5   WebKitLegacy      0x000000018b86d654 -[_WebSafeForwarder forwardInvocation:] + 156

从堆栈信息不难判断出 crash 起因是 UIWebView 的 delegate 野指针，那为啥呈现野指针呢？

这里先阐明一下 crash 的间接起因，而后再来具体分析为什么就呈现了问题。

MySDK 对 setDelegate 进行了 Hook
客户也对 setDelegate 进行了 Hook
先执行 MySDK 的 Hook 逻辑调用，而后执行客户的 Hook 逻辑调用

@interface UIWebView (JSBridge)

@end

@implementation UIWebView (JSBridge)

- (void)setJsBridge:(id)object {objc_setAssociatedObject(self, @selector(jsBridge), object, OBJC_ASSOCIATION_RETAIN_NONATOMIC);
}

- (WebViewJavascriptBridge *)jsBridge {WebViewJavascriptBridge *bridge = objc_getAssociatedObject(self, @selector(jsBridge));
    return bridge;
}

+ (void)load {
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{swizzleMethods(self, @selector(setDelegate:), @selector(setJSBridgeDelegate:));
        swizzleMethods(self, @selector(initWithFrame:), @selector(initJSWithFrame:));
    });

}

- (instancetype)initJSWithFrame:(CGRect)frame {self = [self initJSWithFrame:frame];
    if (self) {WebViewJavascriptBridge *bridge = [WebViewJavascriptBridge bridgeForWebView:self];
        [self setJsBridge:bridge];
    }
    return self;
}

/// webview.delegate = xxx 会被调用屡次且传入的对象不一样
- (void)setJSBridgeDelegate:(id)delegate {
    WebViewJavascriptBridge *bridge = self.jsBridge;
    if (delegate == nil || bridge == nil) {[self setJSBridgeDelegate:delegate];
    } else if (bridge == delegate) {[self setJSBridgeDelegate:delegate];
    } else {
        /// 第一次进入这里传入 bridge
        /// 第二次进入这里传入一个 delegate
        if (![delegate isKindOfClass:[WebViewJavascriptBridge class]]) {[bridge setWebViewDelegate:delegate];
            /// 上面这一行代码是客户短少的
            /// fix with this
            [self setJSBridgeDelegate:bridge];
        } else {[self setJSBridgeDelegate:delegate];
        }
    }
}

@end

@interface UIWebView (MyHook)

@end

@implementation UIWebView (MyHook)

// Hook, setWebViewDelegate: 和 setDelegate: 替换过
- (void)setWebViewDelegate:(id)delegate {if (delegate == nil) {[self setWebViewDelegate:delegate];
    }
    BDWebViewDelegateProxy *proxy = [[BDWebViewDelegateProxy alloc] initWithTarget:delegate];
    self.bd_TrackerDecorator = proxy;
    [self setWebViewDelegate:proxy];
}

@end

UIWebView 有两次调用 setDelegate 办法，第一次是传的 WebViewJavascriptBridge，第二次传的另一个理论的 WebViewDelegate。暂且称第一次传了 bridge 第二次传了实际上的 delegate。

第一次调用，MySDK Hook 的时候会用 DelegateProxy 包装住 bridge，所有办法通过 DelegateProxy 转发到 bridge，这里传给 setJSBridgeDelegate:(id)delegate的 delegate 实际上是 DelegateProxy而非 bridge。

这里须要留神，UIWebView 的 delegate 指向 DelegateProxy 是客户给设置上的，且这个属性assign 而非 weak，这个 assign 很要害，assigin 在对象开释之后不会主动变为 nil。

第二次调用，MySDK Hook 的时候会用新的 DelegateProxy 包装住 delegate 也就是 WebViewDelegate，这个时候 MySDK 的逻辑是把新的 DelegateProxy 给强援用中，老的 DelegateProxy 就失去了强援用因而开释了。

此时的状态如果不做任何解决，以后状态就如图示：

delegate 指向曾经开释的 DelegateProxy，野指针
UIWebview 触发回调就导致 crash

如果补上那一句，setJSBridgeDelegate:(id)delegate在判断了 delegate 不是 bridge 之后，把 UIWebView 的 delegate 设置为 bridge 就能够实现了。

正文中 fix with this 下一行代码

修复后模型如下图

应用 Proxy 的形式尽管也能够解决肯定的问题，然而也须要应用方遵循肯定的标准，要意识到第三方 SDK 也可能 setDelegate 进行 Hook，也可能应用 Proxy

先补充一些参考资料

RxCocoa 源码参考 https://github.com/ReactiveX/…
rxcocoa 学习 -DelegateProxy

RxCocoa 也应用了代理模式，对 delegate 进行了代理，按情理应该没有问题。然而 RxCocoa 的实现有点出入。

如果独自只应用了 RxCocoa 的计划，和计划是统一，也就不会有任何问题。

RxCocoa+MySDK 之后，变成这样子。UICollectionView 的 delegate 间接指向谁在于谁调用的 setDelegate 办法后调。

实践也应该没有问题，就是援用链多一个 poxy 包装而已。然而实际上有两个问题。

RxCocoa 的 delegate 的 get 办法命中 assert

//  UIScrollView+Rx.swift
extension Reactive where Base: UIScrollView {
    public var delegate: DelegateProxy<UIScrollView, UIScrollViewDelegate> {return RxScrollViewDelegateProxy.proxy(for: base)
        // base 能够了解为一个 UIScrollView 实例
    }
}

open class RxScrollViewDelegateProxy {public static func proxy(for object: ParentObject) -> Self {let maybeProxy = self.assignedProxy(for: object)
        let proxy: AnyObject
        if let existingProxy = maybeProxy {proxy = existingProxy} else {proxy = castOrFatalError(self.createProxy(for: object))
            self.assignProxy(proxy, toObject: object)
            assert(self.assignedProxy(for: object) === proxy)
        }
        let currentDelegate = self._currentDelegate(for: object)
        let delegateProxy: Self = castOrFatalError(proxy)
        if currentDelegate !== delegateProxy {delegateProxy._setForwardToDelegate(currentDelegate, retainDelegate: false)
            assert(delegateProxy._forwardToDelegate() === currentDelegate)
            self._setCurrentDelegate(proxy, to: object)
              /// 命中上面这一行 assert
            assert(self._currentDelegate(for: object) === proxy)
            assert(delegateProxy._forwardToDelegate() === currentDelegate)
        }
        return delegateProxy
    }
}

重点逻辑

delegateProxy 即便 RxDelegateProxy
currentDelegate 为 RxDelegateProxy 指向的对象
RxDelegateProxy._setForwardToDelegate 把 RxDelegateProxy 指向实在的 Delegate
标红的后面一句执行的时候，是调用 setDelegate 办法，把 RxDelegateProxy 的 proxy 设置给 UIScrollView(其实是一个 UICollectionView 实例)
而后进入了 MySDK 的 Hook 办法，把 RxDelegateProxy 给包了一层
最终后果如下图
而后导致 self._currentDelegate(for: object) 是 DelegateProxy 而非 RxDelegateProxy，触发标红断言

这个断言就很王道，相当于 RxCocoa 认为就只有它可能去应用 Proxy 包装 delegate，其他人不能这样做，只有做了，就断言。

进一步剖析

以后状态

再次进入 Rx 的办法
- currentDelegate 是 UICollectionView 指向的 DelegateProxy（MySDK 的包装）
- delegateProxy 指向还是 RxDelegateProxy
- 触发 Rx 的 if 判断,Rx 会把其指向实在的 delegate 改向 UICollectionView 指向的 DelegateProxy
- 导致循环指向，援用链中实在的 Delegate 失落了

下面提到屡次调用导致了循环指向，而循环指向导致了在理论的办法转发的时候变成了死循环。

responds 代码

open class RxScrollViewDelegateProxy {override open func responds(to aSelector: Selector!) -> Bool {return super.responds(to: aSelector)
            || (self._forwardToDelegate?.responds(to: aSelector) ?? false)
            || (self.voidDelegateMethodsContain(aSelector) && self.hasObservers(selector: aSelector))
        }
}

@implementation BDCollectionViewDelegateProxy

- (BOOL)respondsToSelector:(SEL)aSelector {if (aSelector == @selector(bd_isCollectionViewTrackerDecorator)) {return YES;}
    return [super respondsToSelector:aSelector];
}

@end

仿佛只有不屡次调用就没有问题了？

关键在于 Rx 的 setDelegate 办法也调用了 get 办法，导致一次 get 就触发第二次调用。也就是屡次调用是无奈防止。

问题的起因比拟显著，如果革新 RxCocoa 的代码，把第三方可能的 Hook 思考进来，齐全能够解决问题。

参考 MySDK 的 proxy 计划，在 proxy 中退出一个非凡办法，来判断 RxDelegateProxy 是否曾经在援用链中，而不去被动扭转这个援用链。

open class RxScrollViewDelegateProxy {public static func proxy(for object: ParentObject) -> Self {
        ...
        let currentDelegate = self._currentDelegate(for: object)
        let delegateProxy: Self = castOrFatalError(proxy)
        //if currentDelegate !== delegateProxy
        if !currentDelegate.responds(to: xxxMethod) {delegateProxy._setForwardToDelegate(currentDelegate, retainDelegate: false)
            assert(delegateProxy._forwardToDelegate() === currentDelegate)
            self._setCurrentDelegate(proxy, to: object)
            assert(self._currentDelegate(for: object) === proxy)
            assert(delegateProxy._forwardToDelegate() === currentDelegate)
        } else {return currentDelegate}

        return delegateProxy
    }

}

相似这样的革新，就能够解决问题。咱们与 Rx 团队进行了沟通，也提了 PR，惋惜最终被回绝合入了。Rx 给出的阐明是，Hook 是不优雅的形式，不举荐 Hook 零碎的任何办法，也不想兼容任何第三方的 Hook。

有没有可能，RxCocoa 不改代码，MySDK 来兼容？

方才提到，有可能是两种状态。

状态 1
- setDelegate 的时候，先进 Rx 的办法，后进 MySDK 的 Hook 办法，
- 传给 Rx 的就是 delegate
- 传给 MySDK 的是 RxDelegateProxy
- Delegate 的 get 调用就触发 bug

状态 2
- setDelegate 的时候，先进 MySDK 的 Hook 办法，后进 Rx 的办法？
- 传给 Rx 的就是 DelegateProxy

其实如果是状态 2，仿佛 Rxcocoa 的 bug 是不会复现的。

然而认真查看 Rxcocoa 的 setDelegate 代码

extension Reactive where Base: UIScrollView {public func setDelegate(_ delegate: UIScrollViewDelegate)

    -> Disposable {return RxScrollViewDelegateProxy.installForwardDelegate(delegate, retainDelegate: false, onProxyForObject: self.base)
    }
}

open class RxScrollViewDelegateProxy {public static func installForwardDelegate(_ forwardDelegate: Delegate, retainDelegate: Bool, onProxyForObject object: ParentObject) -> Disposable {
        weak var weakForwardDelegate: AnyObject? = forwardDelegate as AnyObject
        let proxy = self.proxy(for: object)
        assert(proxy._forwardToDelegate() === nil, "")
        proxy.setForwardToDelegate(forwardDelegate, retainDelegate: retainDelegate)
        return Disposables.create {...}
    }
}

emmm？Rx 外面，UICollectionView 的 setDelegate 和 Delegate 的 get 办法 不是 Hook…

collectionView.rx.setDelegate(delegate)

let delegate = collectionView.rx.delegate

最终流程就只能是

setDelegate 的时候，先进 Rx 的办法，传给 Rx 实在的 delegate
后进 MySDK 的 Hook 办法
传给 MySDK 的是 RxDelegateProxy
Rx 外面获取 CollectionView 的 delegate 触发判断
Delegate 的 get 调用就触发 bug

如果 MySDK 还是采纳以后的 Hook 计划，就没法在 MySDK 解决了。

认真看了一下，发现 Rx 外面是通过重写 RxDelegateProxy 的 forwardInvocation 来达到办法转发的目标，即

RxDelegateProxy 没有实现 UICollectionViewDelegate 的任何办法
forwardInvocation 中解决 UICollectionViewDelegate 相干回调

回顾音讯转发机制

咱们能够在 forwardingTargetForSelector 这一步进行解决，这样能够避开与 Rx 相干的抵触，解决完再间接跳过。

forwardingTargetForSelector 中针对 delegate 的回调，target 返回一个 SDK 解决的类，比 DelegateProxy
DelegateProxy 上报实现之后，间接调用跳到 RxDelegateProxy 的 forwardInvocation 办法

这个解决方案其实也不完满，只能临时躲避与 Rx 的抵触。如果后续有其余 SDK 也来在这个阶段解决 Hook 抵触，也容易呈现问题。

的确如 Rx 团队形容的那样，Hook 不是很优雅的形式，任何 Hook 都有可能存在兼容性问题。

审慎应用 Hook
Hook 零碎接口肯定要遵循肯定的标准，不能假想只有你在 Hook 这个接口
不要假想其他人会怎么解决，间接把多种计划集成到一起，构建多种场景，测试兼容性

文章列举的计划可能不全或者不欠缺，如果有更好的计划，欢送探讨。

NSProxy 应用
代理模式
rxcocoa 学习 -DelegateProxy
https://github.com/ReactiveX/…

字节跳动挪动平台团队 (Client Infrastructure) 是大前端根底技术行业领军者，负责整个字节跳动的中国区大前端基础设施建设，晋升公司全产品线的性能、稳定性和工程效率。

当初 客户端/前端/服务端/端智能算法/测试开发 面向寰球范畴招聘！ 一起来用技术扭转世界 ，感兴趣能够分割邮箱 chenxuwei.cxw@bytedance.com，邮件主题 简历 - 姓名 - 求职意向 - 冀望城市 - 电话。

字节跳动终端技术团队在挪动端、Web、Desktop 等各终端都有深入研究。反对的产品包含抖音、今日头条、西瓜视频、火山小视频等 App。依据实际结晶，现推出一站式挪动开发平台 veMARS，致力于帮忙企业打造优质 App，提供挪动开发解决方案，欢送开发者体验。

关于ios:无埋点核心技术iOS-Hook-在字节的实践经验

前言

计划迭代

计划 1 Method Swizzle

代理模式和 NSProxy 介绍

计划 2 应用代理模式

代码实现

模型

状况一

状况二

踩坑之旅

第一次踩坑

堆栈信息

客户 Hook 的代码

MySDK Hook 代码

野指针起因

修复办法

总结

第二次踩坑

RxCocoa

RxCocoa+MySDK

问题 1

问题 2

解决方案

解决方案 1

解决方案 2

解决方案 3

总结

参考文档

对于字节跳动终端技术团队