引言
Method swizzling指的是改变一个已存在的选择器对应的实现的过程,它依赖于Objectvie-C中方法的调用能够在运行时进改变——通过改变类的调度表(dispatch table)中选择器到最终函数间的映射关系。
方法替换,应该是备受争议的一个黑魔法了,很多人对他都敬而远之,因为他会导致很多不可控的问题。那么为什么今天还要提到方法替换这件事?
因为他有合适使用的场景,今天简单说两个操作方式相同的场景。一个是给页面埋点,监控页面被打开的次数。一个是当你接手一个新项目的时候,如何快速的定位每个页面,快速的熟悉项目内容。
这两个场景其实都可以通过同一种方式,对viewWillAppear:方法进行方法替换。子类化可能是另一个选择,但要求你将UIViewController、 UITableViewController、 UINavigationController 以及所有其他视图控制器类都子类化,这也会导致代码重复,不如使用方法替换来的方便。
所以我们通过在分类中进行method swizzling,下面来看怎么做:
|
|
在计算机学科中,指针变换(pointer swizzling)是指将基于名字或位置的引用转变为直接的指针引用。 然而在Objective-C中,这个词的起源并不完全知道,但关于这一借鉴其实也很好理解,method swizzling可以通过选择器来改变它引用的函数指针。
合适的使用场景
|
|
怎么实现Method Swizzing
+load vs. +initialize
Swizzling应该在+load方法中实现。
每个类的这两个方法会被Objective-C运行时系统自动调用,+load是在一个类最开始加载时调用,+initialize是在应用中第一次调用该类或它的实例的方式之前调用。这两个方法都是可选的,只有实现了才会被执行。
因为method swizzling会影响全局,所以减少冒险情况就很重要。+load能够保证在类初始化的时候就会被加载,这为改变系统行为提供了一些统一性。但+initialize并不能保证在什么时候被调用——事实上也有可能永远也不会被调用,例如应用程序从未直接的给该类发送消息。
dispatch_once
Swizzling应该在dispatch_once中实现。
还是因为swizzling会改变全局,我们需要在运行时采取所有可用的防范措施。保障原子性就是一个措施,它确保代码即使在多线程环境下也只会被执行一次。GCD中的diapatch_once就提供这些保障,它应该被当做swizzling的标准实践。
选择器、方法及实现
在Objective-C中,尽管这些词经常被放在一起来描述消息传递的过程,但选择器、方法及实现分别代表运行时的不同方面。
下面是苹果Objective-C Runtime Reference文档中对它们的描述:
- 选择器(
typedef struct objc_selector *SEL
):选择器用于表示一个方法在运行时的名字,一个方法的选择器是一个注册到(或映射到)Objective-C运行时中的C字符串,它是由编译器生成并在类加载的时候被运行时系统自动映射。 - 方法(
typedef struct objc_method *Method
):一个代表类定义中一个方法的不明类型。 - 实现(
typedef id (*IMP)(id, SEL, ...)
):这种数据类型是实现某个方法的函数开始位置的指针,函数使用的是基于当前CPU架构的标准C调用规约。第一个参数是指向self的指针(也就是该类的某个实例的内存空间,或者对于类方法来说,是指向元类(metaclass
)的指针)。第二个参数是方法的选择器,后面跟的都是参数。
理解这些概念之间关系最好的方式是:一个类(
Class
)维护一张调度表(dispatch table
)用于解析运行时发送的消息;调度表中的每个实体(entry
)都是一个方法(Method
),其中key值是一个唯一的名字——选择器(SEL
),它对应到一个实现(IMP
)——实际上就是指向标准C函数的指针。
Method Swizzling就是改变类的调度表让消息解析时从一个选择器对应到另外一个的实现,同时将原始的方法实现混淆到一个新的选择器。
- 选择器(
注意事项
Swizzling被普遍认为是一种巫术,容易导致不可预料的行为和结果。尽管不是最安全的,但是如果你采取下面这些措施,method swizzling还是很安全的。
始终调用方法的原始实现(除非你有足够的理由不这么做):
API为输入和输出提供规约,但它里面具体的实现其实是个黑匣子,在Method Swizzling过程中不调用它原始的实现可能会破坏一些私有状态,甚至是程序的其他部分。
避免冲突:
给分类方法加前缀,一定要确保不要让你代码库中其他代码(或是依赖库)在做与你相同的事。
理解:
只是简单的复制粘贴swizzling代码而不去理解它是怎么运行的,这不仅非常危险,而且还浪费了学习Objective-C运行时的机会。阅读 Objective-C Runtime Reference 和
去理解代码是怎样和为什么这样执行的,努力的用你的理解来消灭你的疑惑。
谨慎行事:不管你多么自信你能够swizzling Foundation、UIKit 或者其他内置框架,请记住所有这些都可能在下一个版本中就不好使。提前做好准备,防范于未然才不至于到时候焦头烂额。
不敢放心大胆的直接使用Objective-C运行时?Jonathan ‘Wolf’ Rentzsch提供了经过实战检验的、支持CocoaPads的库JRSwizzle,它会为你考虑好了一切。
参考原文链接:(http://nshipster.com/method-swizzling/)
现在,当UIViewController或它子类的任何实例触发viewWillAppear:方法都会打印一条log日志。
本作品采用 署名-非商业性使用-相同方式共享 2.5 中国大陆 (CC BY-NC-SA 2.5)协议
进行许可,欢迎转载,但转载请注明来自SarielTang
,并保持转载后文章内容的完整。本人保留所有版权相关权利。
本文永久链接:http://sarieltang.github.io/2016/10/25/总结分析/2016-10-25/index/