本文讨论以method_exchangeImplements方式来混写方法的实现原理及可能存在的问题, 然后以自定义C函数的方式来取代, 从而达成一种更为优雅的Swizzling实现方式. 并以一个工程中的应用示例作为结尾.
(一) 原理
方法混写(Method Swizzling)是一种通过交换方法的实现(IMP)来改变方法功能的行为. 方法混写的用途可以有: 内省, 覆盖系统方法和动态方法加载等. 常见的一种方法混写方式是调用下面的runtime函数:
void method_exchangeImplementations(Method m1, Method m2)
该函数接收的参数是两个Method. 在运行期, Objective C方法会转变成Method类型. Method实际上是结构体struct objc_method的指针类型. struct objc_method声明如下:
struct objc_method {
SEL method_name
char *method_types
IMP method_imp
}
Method由选择子(method_name) + 方法签名(method_types)(类型编码) + 方法实现(method_imp)三个成员组成(后文会以 m {sel, types, imp} 的形式简化表示). 其中, 方法实现是一个函数指针, 它接收一个id对象self, 一个选择子_cmd和一个可变参数列表, 并返回一个id类型的值:
由此我们看出任何OC方法的参数列表都隐式的包含两个参数: self和_cmd. 明确这一点至关重要. 而消息传递的实现原理简单的说就是将SEL映射到IMP, 然后调用这个函数指针的过程.
介绍完基本概念, 接下来, 我们要找到相应的Method. 幸运的是, runtime提供了下面两个接口, 用以通过sel在类结构体中找到对应的Method:
由此取得两个要混写的方法并调用method_exchangeImplementations函数即可实现Swizzling. 可是上述方式存在一个潜在的问题(有可能很严重...)!
为形象的说明这个问题, 先举个小例子: 定义一个Dog类的-eat方法, 该方法仅仅打印_cmd的名字; 同样的, 定义要用来混写的方法-__swizzleEat, 它也会打印_cmd的名字:
如上图所示, 在+load中交换两个方法. 然后, 在主程序中创建一个Dog对象并发送消息eat: [[Dog new] eat];. 观察打印结果如下:
方法名搞反了! ! 而且可以预见, 如果我们以后想使用_cmd做点其他事情, 并理所当然的认为_cmd的名字就是当前方法名称的话, 就会不知不觉的酿成错误.
造成这个问题的原因是这样: 对于两个方法m1 {sel1, types1, imp1} 和 m2 {sel2, types2, imp2} (假设m1是原方法), 在调用函数method_exchangeImplementations(m1, m2)后, 分别变成了m1 {sel1, types1, imp2} 和 m2 {sel2, types2, imp1}, 也就是交换了imp成员, 而sel成员并未做交换. 于是在程序中调用m1首先会来到m2的实现, 却把sel1传了进来, 于是会出现上图的第一句打印结果; 然后, 当我们在m2内部再调sel2时(这种伪递归调用在可读性上也比较差劲...)则会来到m1的实现, 而此时传进来的则是sel2, 于是就有了第二句打印. (结合上述例子, sel1, sel2分别对应@selector(eat), @selector(__swizzleEat)).
如何避免这种情况, 即, 在方法混写后不影响_cmd的值呢? 既然所有OC方法都会隐式传递_cmd, 我们不妨自定义一个C函数, 令其显式的接收原方法的所有参数, 这样_cmd至始至终都不曾变化, 一直保持原值(sel1). 为保证这种混写方式的通用性, 在以Dog举例之前, 首先写一个NSObject的分类方法, 该方法将一个选择子(sel)映射到新的实现(imp)上, 并返回原方法的实现(因为大多数混写的目的总是希望为原方法加hook而非单纯的覆盖, 所以获取原方法实现常常是必需滴):
接下来, 仍然以Dog的eat方法为混写目标, 首先定义一个接收id和SEL参数的函数指针用以保存原方法的imp, 然后自定义一个用来混写的C函数显式的接收这两个参数:
这一次, 再执行语句[[Dog new] eat];, 打印结果如下:
这样, 在混写后的-eat方法中所取得的_cmd也是正确的了, 从而让整个混写过程看起来不留任何痕迹!
(二) 应用
上述做法可以抽象成固定模式应用到工程中. 这里再举一个自己用过的小例子, 就是让UIButton在规定时间(例子中的toleranceEventInterval属性)内只响应一次, 混写的目标API是 sendAction:to:forEvent:. 如果清晰了上述流程, 这段代码是很容易理解的. 又因时间紧迫, 所以就只贴代码了...
