ios runtime浅析(三)：Method Swizzling【思维走】
method swizzling也许是runtime中最有争议的技术，它的作用就是改变已经存在selector的实现，之所以可以这样是因为方法调用可以在运行时改变：通过改变类的分发表( dispatch table，该表包含selector的名称及对应实现函数的地址)里selector和实现之间的对应关系。
举个例子，比如你想记录一个iOS应用里每个view controller显示的次数：可以在每个view controller添加记录的代码，但这会导致大量的重复代码；通过继承也是一个方法，但需要同时创建UIViewController, UITableViewController, UINavigationController及其它中view controller的子类，同样也会产生许多重复的代码出现。
Swizzling应该只在load方法中使用
oc会在运行时自动调用每个类的两个方法，+load 会在类初始化加载的时候调用；+initialize方法会在程序调用类的第一个实例或者类方法的时候调用。这两个方法都是可选的，只会在实现的时候才去调用。由于method swizzling会影响到全局的状态，因此最小化竞争条件的出现变得很重要，+load方法能够确保在类的初始化时候调用，这能够保证改变应用行为的一致性，而+initialize在执行时并不提供这种保证，实际上，如果没有直接给这个类发送消息，该方法可能都不会调用到。
dispatch_once
Swizzling应该只在dispatch_once中完成
如上，由于swizzling会改变全局状态，所以我们需要在运行时采取一些预防措施。原子性就是其中的一种预防措施，因为它能保证不管有多少个线程，代码只会执行一次。GCD的dispatch_once 能够满足这种需求，因此在method swizzling应该将其作为最佳的实践方式。
选择器，方法和实现
在oc中，选择器、方法和实现是运行时的特殊方面，虽然在一般情况下，这些术语是用在消息发送的过程中。
下面是Apple对它们的几个描述：
选择器(Selector-typedef struct objc_selector *SEL )：用于在运行时表示一个方法的名称，一个方法选择器就是一个C字符串，在运行时会被注册或者映射，选择器是由编译器生成的，并在类被加载的时候由运行时自动进行映射。
方法(Method-typedef struct objc_method *Method)：在类的定义中代表一个方法的类型。
实现(Implementation- typedef id (*IMP)(id, SEL, ...))：这是一个指向方法实现函数起始地址的指针，这个函数的第一个参数是指向self的指针，第二个参数是方法选择器，然后是方法的参数。
理解它们之间关系的最好方式是：一个类维护着一张分发表(dispatch table)，用来解析运行时发来的消息；该表的每个入口是一个方法(Method)，其中的key就是选择器(SEL)，对应一个实现(IMP)，即一个指向底层c函数的指针。
swizzle 一个方法就是改变类的分发表，使它在解析消息的时候，将一个选择器selector对应到别的实现，并且将该选择器对应的原始实现关联到新的选择器中。
调用 _cmd
看起来下面的代码可能导致无限循环：
- (void)xxx_viewWillAppear:(BOOL)animated { [selfxxx_viewWillAppear:animated];NSLog(@"viewWillAppear: %@",NSStringFromClass([selfclass]));}
可奇怪的是，它并不会。在swizzling的过程中，xxx_viewWillAppear:已经被重新指向UIViewController 的原始实现-viewWillAppear:，但是如果我们在这个方法中调用viewWillAppear:则会导致无限循环。
注意事项
通常认为Swizzling是一个比较危险的技术，容易产生不可预料的行为和无法预见的后果，但只要遵循以下几个注意事项，其实method swizzlin还是相对安全的。
总是调用一个方法的原始实现(除非你有足够好的理由不这么做):API提供了输入和输出的约定，但其中的实现却是黑盒。Swizzling 一个方法但不去调用其原始实现，可能造成私有状态的底层假设被打破，影响程序的其它部分。
避免冲突: 给category方法加前缀，确保不会跟其它依赖的代码产生冲突。
知道到底发生啥了：简单的复制粘贴swizzling 代码，而不清楚其如何工作不仅非常危险，而且浪费了好多深入学习objective-c运行时的机会，可以通过查看 Objective-C Runtime Reference 和头文件了解其中的一些来龙去脉。
小心的处理：不管你在swizzling Foundation、UIKit或者其它内建framework方法时多么的充满自信，必须清楚在下一个版本这些可能都改变了，所以为了不出差错，还是需要多花点心思的。
网友评论