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

背景

某年某月的某一天，产品小 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 如何给这些新建的临时类命名

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 开发体验。

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

  点击阅读原文，直达 GitHub！