iOS runtime 黑魔法 方法交换 Method swiz
Method Swizzling 是什么
Method Swizzling是objective-c中的黑魔法，算是runtime中的一种实战使用模式，它允许我们动态的替换方法，实现Hook功能。
但是它也是一把双刃剑，用得好的人可以用它来很轻松的实现一些复杂的功能，而如果用的不好，后果就真的是毁灭性的伤害，这样的黑魔法，我们一定要尽力去掌握并驾驭它。
Method Swizzling 能做什么
先从名字来看，Method方法Swizzling混合，那他的意思就是方法混合？？？ 好像也没有一个准确的翻译，我们就姑且翻译成方法交换吧。
也就是说把原来 A方法实现的a，原来B方法实现的b交换一下，让A来实现b的功能，让B来实现a的功能。咋一看好像没什么厉害的地方，不就是交换个方法么，有什么用呢？您先别急，往下看。
Method Swizzling 原理
我们来看看 Method Swizzling 的原理。
虽然之前我们说Method Swizzling是一把双刃剑，用不好就容易把自己砍死，但是如果我们知道如何使用，这些就不会那么可怕了。
在Method方法中，有两个关键的成员变量：SEL和IMP。
SEL就是我们平时看到的方法的名称，比如@selector(viewWillAppear:)。
IMP是一个函数指针，指向的是方法的实现。
原则上，方法名SEL和IMP是一一对应的，那Method Swizzling的本质就是改变他们的对应关系，达到交换方法实现的目的。
MethodSwizzlingBefore.png
MethodSwizzlingAfter.png
Method Swizzling实现&实践
好了，废话说了一大堆，接下来我们就来说说到底是怎么实现Method Swizzling吧。
我们用一个日常开发中都会用到的需求作为例子，平时我们可能会被产品要求在页面中添加监听事件，监听每个页面的访问，那我们需要再每个页面都添加这样的代码：
我们可以直接在每个页面中都添加这样的代码，简单粗暴，但是缺点也很明显，这样不仅要干很多体力活儿，还容易漏写某些页面，后期可能会被后边的程序员骂死。
或者我们写一个UIViewController的基类，让其他类都继承他，但是对于已经写好的代码，几十个类这样修改还是非常麻烦。
这时候就用到了我们的黑魔法Method Swizzling。
Method Swizzling 相关函数介绍
在真正使用黑魔法之前，我们先熟悉一下需要用到的函数：
获取一个方法名称（SEL）： class_getInstanceMethod
获取一个方法的实现（IMP）：method_getImplementation
获取一个实现编码类型：method_getTypeEncoding
给方法添加实现：class_addMethod
用一个方法实现替换另一个方法的实现：class_replaceMethod
交换两个方法的实现：method_exchangeImplementations
Method Swizzling 实现
在进行方法替换前，我们要考虑两种情况：
要替换的方法在target class中有实现
要替换的方法在target class中没有实现，而是在其父类中实现
对于第一种情况，很简单，我们直接调用method_exchangeImplementations即可达成方法。
而对于第二种情况，我们要仔细想想了。
因为在target class中没有对应的方法实现，方法实际上是在target class的父类中实现的，因此当我们要交换方法实现时，其实是交换了target class父类的实现。这样当其他地方调用这个父类的方法时，也会调用我们所替换的方法，这显然使我们不想要的。
比如，我想替换UIViewController类中的methodForSelector:方法，其实该方法是在其父类NSObject类中实现的。如果我们直接调用method_exchangeImplementations，则会替换掉NSObject的方法。这样当我们在别的地方，比如UITableView中再调用methodForSelector:方法时，其实会调用到父类NSObject，而NSObject的实现，已经被我们替换了。
为了避免这种情况，我们在进行方法替换前，需要检查target class是否有对应方法的实现，如果没有，则要讲方法动态的添加到class的method list中。
+ (void)load{
staticdispatch_once_tonceToken;
dispatch_once(&onceToken, ^{
// 获取类方法
// Class selfClass = object_getClass([self class]);
// 获取实例方法
Class selfClass = [selfclass];
//获取原方法的名称和实现
SEL oriSEL =@selector(viewWillAppear:);
Method oriMethod = class_getInstanceMethod(selfClass, oriSEL);
//获取替换方法的名称和实现
SEL swizzlingSEL =@selector(swizzlingViewWillAppear:);
Method swizzlingMethod = class_getInstanceMethod(selfClass, swizzlingSEL);
//给原方法添加替换方法实现，为了避免原方法没有实现
BOOL addSucc = class_addMethod(selfClass, oriSEL, method_getImplementation(swizzlingMethod), method_getTypeEncoding(swizzlingMethod));
//成功，将原方法的实现替换到替换方法的实现
if(addSucc) {
class_replaceMethod(selfClass, swizzlingSEL, method_getImplementation(oriMethod), method_getTypeEncoding(oriMethod)); }
//失败，说明原方法已经实现，直接交换方法
else{ method_exchangeImplementations(oriMethod, swizzlingMethod);
}
});
}
另外附上替换方法的实现，这里我直接打印了类的名称，具体需要怎么做直接按需求来就行了。
- (void)swizzlingViewWillAppear(BOOL)animated{
NSLog(@"%@",self.class);
return[selfswizzlingViewWillAppear:animated];
}
Method Swizzling类簇
之前我也说到，在我们项目开发过程中，经常因为NSArray数组越界或者NSDictionary的key或者value值为nil等问题导致的崩溃，对于这些问题苹果并不会报一个警告，而是直接崩溃，感觉苹果这样确实有点“太狠了”。
由此，我们可以根据上面所学，对NSArray、NSMutableArray、NSDictionary、NSMutableDictionary等类进行Method Swizzling，实现方式还是按照上面的例子来做。但是....你发现Method Swizzling根本就不起作用，代码也没写错啊，到底是什么鬼？
这是因为Method Swizzling对NSArray这些的类簇是不起作用的。因为这些类簇类，其实是一种抽象工厂的设计模式。抽象工厂内部有很多其它继承自当前类的子类，抽象工厂类会根据不同情况，创建不同的抽象对象来进行使用。例如我们调用NSArray的objectAtIndex:方法，这个类会在方法内部判断，内部创建不同抽象类进行操作。
所以也就是我们对NSArray类进行操作其实只是对父类进行了操作，在NSArray内部会创建其他子类来执行操作，真正执行操作的并不是NSArray自身，所以我们应该对其“真身”进行操作。
代码示例
下面我们实现了防止NSArray因为调用objectAtIndex:方法，取下标时数组越界导致的崩溃：
大家发现了吗，__NSArrayI才是NSArray真正的类，而NSMutableArray又不一样😂。我们可以通过runtime函数获取真正的类：objc_getClass("__NSArrayI");
举例
下面我们列举一些常用的类簇的“真身”：
Method Swizzling 注意要点
功能虽然实现完了，但是这里边有几个部分我们要注意一下。
1.为什么要在+load中实现，不要调用【super load】方法
因为+load方法是在类被加载的时候调用的，与之相似的有类的+initialize方法，但是他是一种懒加载模式，当这个类或子类收到第一条消息之前才会调用他，所以+load方法是最好的实现场所。
由于load类方法是程序运行时这个类被加载到内存中就调用的一个方法，执行比较早，并且不需要我们手动调用。而且这个方法具有唯一性，也就是只会被调用一次，不用担心资源抢夺的问题。
Swizzling在+load中执行时，不要调用[super load]。如果多次调用了[super load]，可能会出现“Swizzle无效”的假象。
2.+load只会被调用一次，为什么还要用dispatch_once?
首先我们要确认我们的Method Swizzling只实现一次，因为多次实现会反复交换方法，导致偶数次调用的实现没有交换，造成不必要的麻烦，添加dispatch_once算是添加一个双保险，因为谁知道有没有人会手动调用+load呢？
3.为什么不直接交换方法，而是先要添加方法？
一般情况下，我们都是为了和我们未知的系统方法添加Method Swizzling，而不是完全替换某个功能，所以我们一般都需要再自定义的实现中调用原始的实现，所以就会出现两种情况：
**.本身就有实现要替换的方法，这个时候比较简单，class_addMethod返回NO，我们直接交换方法就好。
**.本身没有实现要替换的方法，而是继承了父类的实现，class_addMethod返回YES，这个时候，我们需要使用class_getInstanceMethod函数获取到原始实现方法指向的方法，也就是父类中的实现，再通过实现class_replaceMethod来实现调用。
4.在swizzlingViewWillAppear:方法里调用swizzlingViewWillAppear:，不会引起死循环么？
因为Method Swizzling的原理为方法互换，所以这时候用执行的swizzlingViewWillAppear:方法，实际上是执行的viewWillAppear:方法，因为我们并不知道OC的viewWillAppear:方法实现了什么内容，所以我们通过这个调用来实现系统的功能。
相关参考文章：
iOS 黑魔法 Runtime Method Swizzling 背后的原理 - 一个帅气潇洒的豆子 - CSDN博客
iOS开发-runtime-黑魔法Method swizzling - 简书
iOS开发·runtime原理与实践: 方法交换篇(Method Swizzling)(iOS“黑魔法”，埋点统计，禁止UI控件连续点击，防奔溃处理) - 云+社区 - 腾讯云
