原创:知识点总结性文章
创作不易,请珍惜,之后会持续更新,不断完善
个人比较喜欢做笔记和写总结,毕竟好记性不如烂笔头哈哈,这些文章记录了我的IOS成长历程,希望能与大家一起进步
温馨提示:由于简书不支持目录跳转,大家可通过command + F 输入目录标题后迅速寻找到你所需要的内容
目录
- 一、背景
- 二、Objective-C 的动态特性
- 三、SDMagicHook 的优缺点
- 四、使用方法
- 五、初版 SDMagicHook 方案
- 六、优化版 SDMagicHook 方案
- 七、防止 hook 链意外断裂
一、背景
本文从一个 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 的遭遇着实令人同情。但是痛定思痛,难道产品提出的这个问题真的无解吗?其实不然,各位看官静息安坐,且听我慢慢分析。
二、Objective-C 的动态特性
Objective-C 作为一门古老而又灵活的语言有很多动态特性为开发者所津津乐道,这其中尤其以动态类型(Dynamic typing
)、动态绑定(Dynamic binding
)、动态加载(Dynamic loading
)等特性最为著名,许多在其他语言中看似不可能实现的功能也可以在 OC 中利用这些动态特性达到事半功倍的效果。
动态类型(Dynamic typing)
动态类型就是说运行时才确定对象的真正类型。例如我们可以向一个id
类型的对象发送任何消息,这在编译期都是合法的,因为类型是可以动态确定的,消息真正起作用的时机也是在运行时这个对象的类型确定以后,这个下面就会讲到。我们甚至可以在运行时动态修改一个对象的isa
指针从而修改其类型,OC 中KVO
的实现正是对动态类型的典型应用。
动态绑定(Dynamic binding)
当一个对象的类型被确定后,其对应的属性和可响应的消息也被确定,这就是动态绑定。绑定完成之后就可以在运行时根据对象的类型在类型信息中查找真正的函数地址然后执行。
动态加载(Dynamic loading)
根据需求加载所需要的素材资源和代码资源,用户可根据需求加载一些可执行的代码资源,而不是在在启动的时候就加载所有的组件,可执行代码可以含有新的类。
了解了 OC 的这些动态特性之后,让我们再次回顾一下产品的需求要领:产品只想任性地修改任何一个 button
的点击区域,而恰巧这次这个 button
是系统原生组件中的一个子 View
。所以当前要解决的关键问题就是如何去改变一个用系统原生类实例化出来的组件的“点击区域检测方法”。刚才在 OC 动态类型特性的介绍中我们说过“消息真正起作用的时机是在运行时这个对象的类型确定以后”、“我们甚至可以在运行时动态修改一个对象的 isa
指针从而修改其类型,OC 中 KVO
的实现正是对动态类型的典型应用”。看到这里,你应该大概有了一些思路,我们不妨照猫画虎模仿 KVO
的原理来实现一下。
三、SDMagicHook 的优缺点
传统的使用method_exchangeImplementations
方式进行方法swizzling
虽然操作简单但是却有很多缺陷和不足之处。与传统的在 category
中新增一个自定义方法然后进行 hook
的方案对比,SDMagicHook
的优缺点如下:
对传统swizzling的改进
- 当进行方法
swizzling
时候需要新增一个class category
然后添加一个新的方法 - 不同的
category
里面如果出现了同名方法就会造成方法冲突 - 传统的方法
swizzling
会对目标类的所有实例生效,但是这很多时候不是我们需要的甚至会带来各种副作用
优点
- 只用一个
block
即可对任意一个实例的任意方法实现hook
操作,不需要新增任何category
,简洁高效,可以大大提高你调试程序的效率; -
hook
的作用域可以控制在单个实例粒度内,将hook
的副作用降到最低; - 可以对任意普通实例甚至任意类进行
hook
操作,无论这个实例或者类是你自己生成的还是第三方提供的; - 可以随时添加或去除者任意
hook
,易于对hook
进行管理。
缺点
为了保证增删 hook
时的线程安全,SDMagicHook
进行增删 hook
相关的操作时在实例粒度内增加了读写锁,如果有在多线程频繁的 hook
操作可能会带来一点线程等待开销,但是大多数情况下可以忽略不计;
因为是基于实例维度的所以比较适合处理对某个类的个别实例进行 hook
的场景,如果你需要你的hook
对某个类的所有实例都生效建议继续沿用传统方式的hook
。
总结
SDMagicHook
方案在 OC 中和 Swift 的 UIKit 层均可直接使用,而且 hook
作用域可以限制在你指定的某个实例范围内从而避免污染其它不相关的实例。Api 设计简洁易用,你只需要花费一分钟的时间即可轻松快速上手,希望我们的这套方案可以给你带来更美妙的 iOS 开发体验。
四、使用方法
例一
hook CALayer
的 setBackgroundColor:
方法来调试定位是谁悄悄改变了CALayer
的backgroundcolor:
。
[self.view.layer hookMethod:@selector(setBackgroundColor:) impBlock:^(CALayer *layer, CGColorRef color){
[layer callOriginalMethodInBlock:^{
[layer setBackgroundColor:color];
}];
NSLog(@"%@", [NSString stringWithFormat:@"AHA! Catch it! Here are the clues.\n\n%@", [NSThread callStackSymbols]]);
}];
例二:hook UIButton的 pointInside:withEvent: 方法来扩大其点击区域
- (void)expand:(Boolean)yn {
if (yn) {
__weak typeof(self) weakSelf = self;
_hookID = [_button hookMethod:@selector(pointInside:withEvent:) impBlock:^(UIView *v, CGPoint p, UIEvent *e){
__block BOOL res = false;
[v callOriginalMethodInBlock:^{
res = [v pointInside:p withEvent:e];
}];
if (res) return YES;
return [weakSelf pointCheck:p view:v];
}];
} else {
[_button removeHook:@selector(pointInside:withEvent:) strId:_hookID];
}
}
例三:hook类方法
- (void)hookClassMethod {
[[DemoVC3 class] hookMethod:@selector(testClassMethod) key:&testClassMethodTag impBlock:^(id cls){
[cls callOriginalMethodInBlock:^{
[[DemoVC3 class] testClassMethod];
}];
printf(">> hooked testClassMethod");
}];
}
+ (void)testClassMethod {
printf(">> %s", sel_getName(_cmd));
}
- (void)dealloc {
[[DemoVC3 class] removeHook:@selector(testClassMethod) key:&testClassMethodTag];
}
例四:在Swift中hook UIViewController的 viewDidDisappear:方法:
override func viewDidLoad() {
super.viewDidLoad()
let imp: @convention(block) (UIViewController, Bool) -> Void = { (vc, flag) in
vc.callOriginalMethod {
vc.viewDidDisappear(flag)
}
print(vc)
}
rootVC = navigationController?.children.first
hookID = rootVC?.hookMethod(#selector(UIViewController.viewDidDisappear(_:)), impBlock: imp)
}
五、防止 hook 链意外断裂
我们都知道在对某个方法进行 hook
操作时都需要在我们的 hook
代码方法体中调用一下被 hook
的那个原始方法,如果遗漏了此步操作就会造成 hook
链断裂,这样就会导致被 hook
的那个原始方法永远不会被调用到,如果有人在你之前也 hook
了这个方法的话就会导致在你之前的所有 hook
都莫名失效了,因为这是一个很隐蔽的问题所以你往往很难意识到你的 hook
操作已经给其他人造成了严重的问题。
为了方便 hook
操作者快速及时发现这一问题,我们在 DEBUG
模式下增加了一套“hook
链断裂检测机制”,其实现原理大致如下:前面已经提到过,我们实现了对 hook
目标方法的自定义调度,这就使得我们有机会在这些方法调用结束后检测其是否在方法执行过程中通过 callOriginalMethodInBlock
调用原始方法。如果发现某个方法体不是被 hook
的目标函数的最原始的方法体且这次方法执行结束之后也没有调用过原始方法就会通过 raise(SIGTRAP)
方式发送一个中断信号暂停当前的程序以提醒开发者当次 hook
操作没有调用原始方法。
六、初版 SDMagicHook 方案
要想使用这种类似 KVO
的替换 isa
指针的方案,首先需要解决以下几个问题:
1、如何动态创建一个新的类
在 OC 中,我们可以调用 runtime
的 objc_allocateClassPair
、objc_registerClassPair
函数动态地生成新的类,然后调用 object_setClass
函数去将某个对象的isa
替换为我们自建的临时类。
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]
。

3、何时销毁这些临时类
我们通过 objc_setAssociatedObject
的方式可以为每个 NSObject
对象动态关联上一个 SDNewClassManager
实例,在 SDNewClassManager
实例里面持有当前对象所使用的临时类。当前对象销毁时也会销毁这个 SDNewClassManager
实例,然后我们就可以在 SDNewClassManager
实例的 dealloc
方法里面做一些销毁临时类的操作。但这里我们又不能立即做销毁临时类的操作,因为此时这个对象还没有完全析构,它还在做一些其它善后操作,如果此时去销毁那个临时类必然会造成 crash
,所以我们需要稍微延迟一段时间来做这些临时类的销毁操作,代码如下:

好了,到目前为止我们已经实现了第一版 hook 方案,不过这里两个明显的问题:每次 hook
都要增加一个 category
定义一个函数相对比较麻烦;如果我们在某个 Class
的两个 category
里面分别实现了一个同名的方法就会导致只有一个方法最终能被调用到。为此,我们研发了第二版针对第一版的不足予以改进和优化。
七、优化版 SDMagicHook 方案
针对上面提到的两个问题,我们可以通过用 block
生成 IMP
然后将这个 IMP
替换到目标 Selector
对应的 method
上即可,API 示例代码如下。这个 block
方案看上去确实简洁和方便了很多,但同样面临着任何一个 hook
方案都避不开的问题那就是,如何在 block
里面调用原生的对应方法呢?

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:
消息时就将这个消息转发给系统原生的方法实现,如此一来就可以完成了一次完美的方法调度了。
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
表中移除即可。代码如下:

网友评论