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方法中,有两个关键的成员变量:SELIMP

SEL就是我们平时看到的方法的名称,比如@selector(viewWillAppear:)。

IMP是一个函数指针,指向的是方法的实现。

原则上,方法名SELIMP是一一对应的,那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控件连续点击,防奔溃处理) - 云+社区 - 腾讯云

推荐阅读更多精彩内容