开源 | Objective-C & Swift 最轻量级 Hook 方案

本文从一个 iOS 平常开发的 hook 案例入手，首先简要介绍了 Objective-C 的动态特性以及传统 hook 方式常见的命名冲突、操做繁琐、hook 链意外断裂、hook 做用范围不可控制等缺陷，而后详细介绍了一套基于消息转发机制的 instance 粒度的轻量级 hook 方案：SDMagicHook。

Github 项目地址：github.com/larksuite/S…。

背景

某年某月的某一天，产品小 S 向开发君小 Q 提出了一个简约而不简单的需求：扩大一下某个 button 的点击区域。小 Q 听完暗自窃喜：还好，这是一个我自定义的 button，只须要重写一下 button 的 pointInside:withEvent:方法便可。只见小 Q 手起刀落在产品小 S 崇拜的目光中轻松完成。代码以下：

第二天，产品小 S 又一次满怀期待地找到开发君小 Q：欧巴~，帮我把这个 button 也扩大一下点击区域吧。小 Q 此次却犯了难，心中暗自思忖：这是系统提供的标准 UI 组件里面的 button 啊，我只能拿来用无法改呀，我看你这分明就是故意为难我胖虎！我…我…我.----小 Q 卒。

在这个 case 中，小 Q 的遭遇着实使人同情。可是痛定思痛，难道产品提出的这个问题真的无解吗？其实否则，各位看官静息安坐，且听我慢慢分析：

1. Objective-C 的动态特性

Objective-C 做为一门古老而又灵活的语言有不少动态特性为开发者所津津乐道，这其中尤为以动态类型（Dynamic typing）、动态绑定（Dynamic binding）、动态加载（Dynamic loading）等特性最为著名，许多在其余语言中看似不可能实现的功能也能够在 OC 中利用这些动态特性达到事半功倍的效果。

1.1 动态类型（Dynamic typing）

动态类型就是说运行时才肯定对象的真正类型。例如咱们能够向一个 id 类型的对象发送任何消息，这在编译期都是合法的，由于类型是能够动态肯定的，消息真正起做用的时机也是在运行时这个对象的类型肯定之后，这个下面就会讲到。咱们甚至能够在运行时动态修改一个对象的 isa 指针从而修改其类型，OC 中 KVO 的实现正是对动态类型的典型应用。

1.2 动态绑定（Dynamic binding）

当一个对象的类型被肯定后，其对应的属性和可响应的消息也被肯定，这就是动态绑定。绑定完成以后就能够在运行时根据对象的类型在类型信息中查找真正的函数地址而后执行。

1.3 动态加载（Dynamic loading）

根据需求加载所须要的素材资源和代码资源，用户可根据需求加载一些可执行的代码资源，而不是在在启动的时候就加载全部的组件，可执行代码能够含有新的类。

了解了 OC 的这些动态特性以后，让咱们再次回顾一下产品的需求要领：产品只想任性地修改任何一个 button 的点击区域，而恰巧此次这个 button 是系统原生组件中的一个子 View。因此当前要解决的关键问题就是如何去改变一个用系统原生类实例化出来的组件的“点击区域检测方法”。刚才在 OC 动态类型特性的介绍中咱们说过“消息真正起做用的时机是在运行时这个对象的类型肯定之后”、“咱们甚至能够在运行时动态修改一个对象的 isa 指针从而修改其类型，OC 中 KVO 的实现正是对动态类型的典型应用”。看到这里，你应该大概有了一些思路，咱们不妨照猫画虎模仿 KVO 的原理来实现一下。

2. 第一版 SDMagicHook 方案

要想使用这种相似 KVO 的替换 isa 指针的方案，首先须要解决如下几个问题：

2.1 如何动态建立一个新的类

在 OC 中，咱们能够调用 runtime 的 objc_allocateClassPair、objc_registerClassPair 函数动态地生成新的类，而后调用 object_setClass 函数去将某个对象的 isa 替换为咱们自建的临时类。

2.2 如何给这些新建的临时类命名

做为一个有意义的临时类名，首先得能够直观地看出这个临时类与其基类的关系，因此咱们能够这样拼接新的类名[NSString stringWithFormat:@“SDHook*%s”, originalClsName]，但这有一个很明显的问题就是没法作到一个对象独享一个专有类，为此咱们能够继续扩充下，不妨在类名中加上一个对象的惟一标记–内存地址，新的类名组成是这样的[NSString stringWithFormat:@“SDHook_%s_%p”, originalClsName, self]，此次看起来彷佛完美了，但在极端的状况下还会出问题，例如咱们在一个一万次的 for 循环中不断建立同一种类型的对象，那么就会大几率出现新对象的内存地址和以前已经释放了的对象的内存地址同样，而咱们会在一个对象析构后很快就会去释放它所使用的临时类，这就会有几率致使那个新生成的对象正在使用的类被释放了而后就发生了 crash。为解决此类问题，咱们须要再在这个临时的类名中添加一个随机标记来下降这种状况发生的几率，最终的类名组成是这样的[NSString stringWithFormat:@“SDHook_%s_%p_%d”, originalClsName, self, mgr.randomFlag]。

2.3 什么时候销毁这些临时类

咱们经过 objc_setAssociatedObject 的方式能够为每一个 NSObject 对象动态关联上一个 SDNewClassManager 实例，在 SDNewClassManager 实例里面持有当前对象所使用的临时类。当前对象销毁时也会销毁这个 SDNewClassManager 实例，而后咱们就能够在 SDNewClassManager 实例的 dealloc 方法里面作一些销毁临时类的操做。但这里咱们又不能当即作销毁临时类的操做，由于此时这个对象尚未彻底析构，它还在作一些其它善后操做，若是此时去销毁那个临时类必然会形成 crash，因此咱们须要稍微延迟一段时间来作这些临时类的销毁操做，代码以下：

好了，到目前为止咱们已经实现了初版 hook 方案，不过这里两个明显的问题：

1. 每次 hook 都要增长一个 category 定义一个函数相对比较麻烦；
2. 若是咱们在某个 Class 的两个 category 里面分别实现了一个同名的方法就会致使只有一个方法最终能被调用到。

为此，咱们研发了第二版针对初版的不足予以改进和优化。

3. 优化版 SDMagicHook 方案

针对上面提到的两个问题，咱们能够经过用 block 生成 IMP 而后将这个 IMP 替换到目标 Selector 对应的 method 上便可，API 示例代码以下：

这个 block 方案看上去确实简洁和方便了不少，但一样面临着任何一个 hook 方案都避不开的问题那就是，如何在 block 里面调用原生的对应方法呢？

3.1 关键点一：如何在 block 里面调用原生方法

在第一版方案中，咱们在一个类的 category 中增长了一个 hook 专用的方法，而后在完成方法交换以后经过向实例发送 hook 专用的方法自身对应的 selector 消息便可实现对原生方法的回调。可是如今咱们是使用的 block 建立了一个“匿名函数”来替换原生方法，既然是匿名函数也就没有明确的 selector，这也就意味着咱们根本没有办法在方法交换后找到它的原生方法了！

那么眼下的关键问题就是找到一个合适的 Selector 来映射到被 hook 的原生函数。而目前来看，咱们惟一能够在当前编译环境下方便调用且和这个 block 还有必定关联关系的 Selector 就是原方法的 Selector 也就是咱们的 demo 中的pointInside:withEvent:了。这样一来pointInside:withEvent:这个 Selector 就变成了一个一对多的映射 key，当有人在外部向咱们的 button 发送 pointInside:withEvent:消息时，咱们应该首先将 pointInside:withEvent:转发给咱们自定义的 block 实现的 IMP，而后当在 block 内部再次向 button 发送 pointInside:withEvent:消息时就将这个消息转发给系统原生的方法实现，如此一来就能够完成了一次完美的方法调度了。

3.2 关键点二：如何设计消息调度方案

在 OC 中要想调度方法派发就须要拿到消息转发的控制权，而要想得到这个消息转发控制权就须要强制让这个 receiver 每次收到这个消息都触发其消息转发机制而后咱们在消息转发的过程当中作对应的调度。在这个例子中咱们将目标 button 的 pointInside:withEvent:对应的 method 的 imp 指针替换为_objc_msgForward，这样每当有人调用这个 button 的 pointInside:withEvent:方法时最终都会走到消息转发方法 forwardInvocation:里面，咱们实现这个方法来完成具体的方法调度工做。

由于目标 button 的 pointInside:withEvent:对应的 method 的 imp 指针被替换成了_objc_msgForward，因此咱们须要另外新增一个方法 A 和方法 B 来分别存储目标 button 的 pointInside:withEvent:方法的 block 自定义实现和原生实现。而后当须要在自定义的方法内部调用原始方法时经过调用 callOriginalMethodInBlock:这个 api 来显式告知，示例代码以下：

callOriginalMethodInBlock 方法的内部实现其实就是为这次调用加了一个标识符用于在方法调度时判断是否须要调用原始方法，其实现代码以下：

当目标 button 实例收到 pointInside:withEvent:消息时会启用咱们自定义的消息调度机制，检查若是 OriginalCallFlag 为 false 就去调用自定义实现方法 A，不然就去调用原始实现方法 B，从而顺利实现一次方法调度。流程图及示例代码以下：

想象这样一个应用场景：有一个全局的 keywindow，各个业务都想监听一下 keywindow 的 layoutSubviews 方法，那咱们该如何去管理和维护添加到 keywindow 上的多个 hook 实现之间的关系呢？若是一个对象要销毁了，它须要移除掉以前对 keywindow 的 hook，这时又该如何处理呢？

咱们的解决方案是为每一个被 hook 的目标原生方法生成一张 hook 表，按照 hook 发生的顺序依次为其生成内部 selector 并加入到 hook 表中。当 keywindow 收到 layoutSubviews 消息时，咱们从 hook 表中取出该次消息对应的 hook selector 发送给 keywindow 让它执行对应的动做。若是删除某个 hook 也只需将其对应的 selector 从 hook 表中移除便可。代码以下：

4. 防止 hook 链意外断裂

咱们都知道在对某个方法进行 hook 操做时都须要在咱们的 hook 代码方法体中调用一下被 hook 的那个原始方法，若是遗漏了此步操做就会形成 hook 链断裂，这样就会致使被 hook 的那个原始方法永远不会被调用到，若是有人在你以前也 hook 了这个方法的话就会致使在你以前的全部 hook 都莫名失效了，由于这是一个很隐蔽的问题因此你每每很难意识到你的 hook 操做已经给其余人形成了严重的问题。

为了方便 hook 操做者快速及时发现这一问题，咱们在 DEBUG 模式下增长了一套“hook 链断裂检测机制”，其实现原理大体以下：

前面已经提到过，咱们实现了对 hook 目标方法的自定义调度，这就使得咱们有机会在这些方法调用结束后检测其是否在方法执行过程当中经过 callOriginalMethodInBlock 调用原始方法。若是发现某个方法体不是被 hook 的目标函数的最原始的方法体且此次方法执行结束以后也没有调用过原始方法就会经过 raise(SIGTRAP)方式发送一个中断信号暂停当前的程序以提醒开发者当次 hook 操做没有调用原始方法。

5. SDMagicHook 的优缺点

与传统的在 category 中新增一个自定义方法而后进行 hook 的方案对比，SDMagicHook 的优缺点以下：

优势：

1. 只用一个 block 便可对任意一个实例的任意方法实现 hook 操做，不须要新增任何 category，简洁高效，能够大大提升你调试程序的效率；
2. hook 的做用域能够控制在单个实例粒度内，将 hook 的反作用降到最低；
3. 能够对任意普通实例甚至任意类进行 hook 操做，不管这个实例或者类是你本身生成的仍是第三方提供的；
4. 能够随时添加或去除者任意 hook，易于对 hook 进行管理。

缺点：

1. 为了保证增删 hook 时的线程安全，SDMagicHook 进行增删 hook 相关的操做时在实例粒度内增长了读写锁，若是有在多线程频繁的 hook 操做可能会带来一点线程等待开销，可是大多数状况下能够忽略不计；
2. 由于是基于实例维度的因此比较适合处理对某个类的个别实例进行 hook 的场景，若是你须要你的 hook 对某个类的全部实例都生效建议继续沿用传统方式的 hook。

总结

SDMagicHook 方案在 OC 中和 Swift 的 UIKit 层都可直接使用，并且 hook 做用域能够限制在你指定的某个实例范围内从而避免污染其它不相关的实例。Api 设计简洁易用，你只须要花费一分钟的时间便可轻松快速上手，但愿咱们的这套方案能够给你带来更美妙的 iOS 开发体验。

欢迎关注「字节跳动技术团队」