Swizzling作为运行时黑魔法，确实为很多问题的分析和处理提供了便利，本文首先援引他山之石记录Swizzling的具体用法和模板，进而通过一组实验分析了其在工程实践中的危险性。
Method Swizzling原理
Method Swizzing是发生在运行时的，主要用于在运行时将两个Method进行交换，我们可以将Method Swizzling代码写到任何地方，但是只有在这段Method Swilzzling代码执行完毕之后互换才起作用。而且Method Swizzling也是iOS中AOP(面相切面编程)的一种实现方式，我们可以利用苹果这一特性来实现AOP编程。
Method Swizzling本质上就是对IMP和SEL进行交换。
一般我们使用都是新建一个分类，在分类中进行Method Swizzling方法的交换。交换的代码模板如下：
#import <objc/runtime.h>
@implementation UIViewController (Swizzling)
+ (void)load {
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
Class class = [self class];
// When swizzling a class method, use the following:
// Class class = object_getClass((id)self);
SEL originalSelector = @selector(viewWillAppear:);
SEL swizzledSelector = @selector(xxx_viewWillAppear:);
Method originalMethod = class_getInstanceMethod(class, originalSelector);
Method swizzledMethod = class_getInstanceMethod(class, swizzledSelector);
BOOL didAddMethod = class_addMethod(class,
originalSelector,
method_getImplementation(swizzledMethod),
method_getTypeEncoding(swizzledMethod));
if (didAddMethod) {
class_replaceMethod(class,
swizzledSelector,
method_getImplementation(originalMethod),
method_getTypeEncoding(originalMethod));
} else {
method_exchangeImplementations(originalMethod, swizzledMethod);
}
});
}
#pragma mark - Method Swizzling
- (void)xxx_viewWillAppear:(BOOL)animated {
[self xxx_viewWillAppear:animated];
NSLog(@"viewWillAppear: %@", self);
}
@end
Method Swizzling可以在运行时通过修改类的方法列表中selector对应的函数或者设置交换方法实现，来动态修改方法。可以重写某个方法而不用继承，同时还可以调用原先的实现。所以通常应用于在category中添加一个方法。
注意要点：
1.Swizzling应该总在+load中执行
Objective-C在运行时会自动调用类的两个方法+load和+initialize。+load会在类初始加载时调用， +initialize方法是以懒加载的方式被调用的，如果程序一直没有给某个类或它的子类发送消息，那么这个类的 +initialize方法是永远不会被调用的。所以Swizzling要是写在+initialize方法中，是有可能永远都不被执行。
和+initialize比较+load能保证在类的初始化过程中被加载。
关于+load和+initialize的比较可以参看这篇文章《Objective-C +load vs +initialize》
2.Swizzling应该总是在dispatch_once中执行
Swizzling会改变全局状态，所以在运行时采取一些预防措施，使用dispatch_once就能够确保代码不管有多少线程都只被执行一次。这将成为Method Swizzling的最佳实践。
这里有一个很容易犯的错误，那就是继承中用了Swizzling。如果不写dispatch_once就会导致Swizzling失效！
举个例子，比如同时对NSArray和NSMutableArray中的objectAtIndex:方法都进行了Swizzling，这样可能会导致NSArray中的Swizzling失效的。
可是为什么会这样呢？
原因是，我们没有用dispatch_once控制Swizzling只执行一次。如果这段Swizzling被执行多次，经过多次的交换IMP和SEL之后，结果可能就是未交换之前的状态。
比如说父类A的B方法和子类C的D方法进行交换，交换一次后，父类A持有D方法的IMP，子类C持有B方法的IMP，但是再次交换一次，就又还原了。父类A还是持有B方法的IMP，子类C还是持有D方法的IMP，这样就相当于咩有交换。可以看出，如果不写dispatch_once，偶数次交换以后，相当于没有交换，Swizzling失效！
3.Swizzling在+load中执行时，不要调用[super load]
原因同注意点二，如果是多继承，并且对同一个方法都进行了Swizzling，那么调用[super load]以后，父类的Swizzling就失效了。
4.上述模板中没有错误
有些人怀疑我上述给的模板可能有错误。在这里需要讲解一下。
在进行Swizzling的时候，我们需要用class_addMethod先进行判断一下原有类中是否有要替换的方法的实现。
如果class_addMethod返回NO，说明当前类中有要替换方法的实现，所以可以直接进行替换，调用method_exchangeImplementations即可实现Swizzling。
如果class_addMethod返回YES，说明当前类中没有要替换方法的实现，我们需要在父类中去寻找。这个时候就需要用到method_getImplementation去获取class_getInstanceMethod里面的方法实现。然后再进行class_replaceMethod来实现Swizzling。
这是Swizzling需要判断的一点。
还有一点需要注意的是，在我们替换的方法- (void)xxx_viewWillAppear:(BOOL)animated中，调用了[self xxx_viewWillAppear:animated];这不是死循环了么？
其实这里并不会死循环。
由于我们进行了Swizzling，所以其实在原来的- (void)viewWillAppear:(BOOL)animated方法中，调用的是- (void)xxx_viewWillAppear:(BOOL)animated方法的实现。所以不会造成死循环。相反的，如果这里把[self xxx_viewWillAppear:animated];改成[self viewWillAppear:animated];就会造成死循环。因为外面调用[self viewWillAppear:animated];的时候，会交换方法走到[self xxx_viewWillAppear:animated];这个方法实现中来，然后这里又去调用[self viewWillAppear:animated]，就会造成死循环了。
所以按照上述Swizzling的模板来写，就不会遇到这4点需要注意的问题啦。
================不知道这个分割线够不够长==============
以上精彩论述摘自神经病院Objective-C Runtime出院第三天——如何正确使用Runtime
诚然这也是我一直使用的Swizzling模板，不过当读至上文有关继承中的Swizzle时，忽然才意识到自己从未对此问题进行过细致的思考和实验，直观上觉得即便使用dispatch_once，也无法限制继承关系中各个子类的Swizzle不会交叉在一起。
闲话少说，一组实验如下：
- 实验1
Class A
|---MethodA
Class B : ClassA
|---MethodA（重写）
Category A
|---+ (void)load 中进行Swizzle: A switch with B
|---MethodB : 调用MethodB
Category B
|---+ (void)load 中进行Swizzle: A switch with C
|---MethodC : 调用MethodC
Invoker:
ClassB *B = [ClassB new];
[B MethodA];
本次实验得到的结果为：
打印顺序：MethodA->MethodC，
由此可见，子类重写的MethodA方法得到调用，之后正常打印MethodC中后面的信息。
- 实验2
Class A
|---MethodA
Category A
|---+ (void)load 中进行Swizzle: A switch with B
|---MethodB : 调用MethodB
Category B
|---+ (void)load 中进行Swizzle: A switch with C
|---MethodC : 调用MethodC
Invoker:
ClassB *B = [ClassB new];
[B MethodA];
本次实验在子类中不去重写父类方法。
本次实验得到的结果为：
打印顺序： MethodA ->MethodB->MethodC，
由此可见，父类和子类的Swizzle都生效了。
结论
- class_getInstanceMethod在本类中没有找到相应SEL的实现会去父类中继续查找。（本句结论文档可查，看似废话但对于实验结果的理解颇为重要）
- 父类Load方法先于子类Load方法执行，虽然load方法底层直接是C的实现，不遵循消息传递机制，但如果父类子类都实现load了的话，其执行顺序还是确定的。
- A先与B交换，A再与C交换。造成的结果是SEL A -> IMP C, SEL C -> IMP B, SEL B -> IMP A. 由此才会在子类调用MethodA时，出现MethodC ->MethodB->MethodA的情形，导致执行顺序为A->B->C.
危险慎行
由于Swizzle属于运行时黑魔法，其影响是全局有效，不利于在调试是发现问题，其较为松散的代码关系和不太透明的底层执行顺序容易造成不可预期的逻辑错误，如本文实验中的继承关系。因此在项目实际应用中，Swizzle最好只在调试，埋点等场景中使用，尽量不要用它来做一些方便业务处理的“小聪明”。
