iOS runtime 黑魔法方法交换 Method swizzling

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