前言
在开始之前建议先阅读iOS runtime的基础理解篇:iOS内功篇:runtime
现在IT届流行一个词叫“黑科技”,泛指一些让人“不明觉厉的”新技术或新产品,那在iOS开发中有什么高大上的“黑科技”呢?runtime中的Method Swizzling当仁不让,它是一把双刃剑,高手耍起来威力无限,菜鸟耍起来则可能伤及自身。对于这样的黑科技,我们当然要掌握并努力驾驭之。
什么是Method Swizzling
Method Swizzling(貌似没有很正式的中文名,下文使用暴力的中文来代替:方法交换),顾名思义,就是将两个方法的实现交换,即由原来的A-AImp、B-BImp对应关系变成了A-BImp、B-AImp。
那为什么无缘无故要将两个方法的实现交换呢?
1、hook:在开发中,经常用到系统提供的API,但出于某些需求,我们可能会对某些方法的实现不太满意,就想去修改它以达到更好的效果,Hook由此诞生。iOS开发会使用Method Swizzling来达到这样的效果:当特定的消息发出时,会先到达我们提前预置的消息处理函数,取得控制权来加工消息以及后续处理。
2、面向切面编程:实际上,要改变一个方法的实现有几种方法,比如继承重写、分类重写等等,但在开发中,往往由于业务需要需要在代码中添加一些琐碎的、跟主要业务逻辑无关的东西,使用这两者都有局限性,使用方法交换动态給指定的方法添加代码以达到解耦的效果。
Method Swizzling原理
每个类都维护一个方法(Method)列表,Method则包含SEL和其对应IMP的信息,方法交换做的事情就是把SEL和IMP的对应关系断开,并和新的IMP生成对应关系。
交换前:Asel->AImp Bsel->BImp
交换后:Asel->BImp Bsel->AImp
Method Swizzling相关函数介绍
//获取通过SEL获取一个方法
class_getInstanceMethod
//获取一个方法的实现
method_getImplementation
//获取一个OC实现的编码类型
method_getTypeEncoding
//給方法添加实现
class_addMethod
//用一个方法的实现替换另一个方法的实现
class_replaceMethod
//交换两个方法的实现
method_exchangeImplementations
Method Swizzling实现的过程
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
//case1: 替换实例方法
Class selfClass = [self class];
//case2: 替换类方法
Class selfClass = object_getClass([self class]);
//源方法的SEL和Method
SEL oriSEL = @selector(viewWillAppear:);
Method oriMethod = class_getInstanceMethod(selfClass, oriSEL);
//交换方法的SEL和Method
SEL cusSEL = @selector(customViewWillApper:);
Method cusMethod = class_getInstanceMethod(selfClass, cusSEL);
//先尝试給源方法添加实现,这里是为了避免源方法没有实现的情况
BOOL addSucc = class_addMethod(selfClass, oriSEL, method_getImplementation(cusMethod), method_getTypeEncoding(cusMethod));
if (addSucc) {
//添加成功:将源方法的实现替换到交换方法的实现
class_replaceMethod(selfClass, cusSEL, method_getImplementation(oriMethod), method_getTypeEncoding(oriMethod));
}else {
//添加失败:说明源方法已经有实现,直接将两个方法的实现交换即可
method_exchangeImplementations(oriMethod, cusMethod);
}
});
Method Swizzling注意事项
1、方法交换应该保证唯一性和原子性
唯一性:应该尽可能在+load方法中实现,这样可以保证方法一定会调用且不会出现异常。
原子性:使用dispatch_once来执行方法交换,这样可以保证只运行一次。
2、一定要调用原始实现
由于iOS的内部实现对我们来说是不可见的,使用方法交换可能会导致其代码结构改变,而对系统产生其他影响,因此应该调用原始实现来保证内部操作的正常运行。
3、方法名必须不能产生冲突
这个是常识,避免跟其他库产生冲突。
4、做好记录
记录好被影响过的方法,不然时间长了或者其他人debug代码时候可能会对一些输出信息感到困惑。
5、如果非迫不得已,尽量少用方法交换
虽然方法交换可以让我们高效地解决问题,但是如果处理不好,可能会导致一些莫名其妙的bug。
Method Swizzling应用实例
1、hook: 給全局图片名称添加前缀
想象这样一个场景,你所负责的项目下个版本需要更换所有图标,然而你拿到新的图片资源比旧图片多了一个前缀“new_”,你可以一个个去改标题,当然也可以抖机灵地使用下面这个方法。
@implementation UIImage (Hook)
+ (void)load {
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
Class selfClass = object_getClass([self class]);
SEL oriSEL = @selector(imageNamed:);
Method oriMethod = class_getInstanceMethod(selfClass, oriSEL);
SEL cusSEL = @selector(myImageNamed:);
Method cusMethod = class_getInstanceMethod(selfClass, cusSEL);
BOOL addSucc = class_addMethod(selfClass, oriSEL, method_getImplementation(cusMethod), method_getTypeEncoding(cusMethod));
if (addSucc) {
class_replaceMethod(selfClass, cusSEL, method_getImplementation(oriMethod), method_getTypeEncoding(oriMethod));
}else {
method_exchangeImplementations(oriMethod, cusMethod);
}
});
}
+ (UIImage *)myImageNamed:(NSString *)name {
NSString * newName = [NSString stringWithFormat:@"%@%@", @"new_", name];
return [self myImageNamed:newName];
}
@end
流程分析:
1、在+load方法中将imageNamed和myImageNamed的实现交换了,现在的状态变成了
imageNamed -> myImageNamed(IMP)
myImageNamed -> imageNamed(IMP)
2、当用户调用imageNamed时,其实现是myImageNamed(IMP),在例子中的代码就是:
NSString * newName = [NSString stringWithFormat:@"%@%@", @"new_", name];
return [self myImageNamed:newName];
3、代码中对图片名称做了处理,加上前缀。
4、代码调用了[self myImageNamed:newName],看起来会陷入死循环,但其实myImageNamed的实现已经是imageNamed(IMP),因此该调用相当于调用系统原来的生成图片的实现。
5、一句话总结:方法交换之后,“方法的实现” 变成了 “你的处理代码” + “方法的实现”
结果:
当调用设置图片的方法时
imgV.image = [UIImage imageNamed:@"home_icon"];
实际上相当于自动給图片名称加了前缀
imgV.image = [UIImage imageNamed:@"new_home_icon"];
2、面向切面编程: 数据统计
想象这样一个场景,出于某些需求,我们需要跟踪记录APP中按钮的点击次数和频率等数据,怎么解决?当然通过继承按钮类或者通过类别实现是一个办法,但是带来其他问题比如别人不一定会去实例化你写的子类,或者其他类别也实现了点击方法导致不确定会调用哪一个,抖机灵的方法如下:
@implementation UIButton (Hook)
+ (void)load {
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
Class selfClass = [self class];
SEL oriSEL = @selector(sendAction:to:forEvent:);
Method oriMethod = class_getInstanceMethod(selfClass, oriSEL);
SEL cusSEL = @selector(mySendAction:to:forEvent:);
Method cusMethod = class_getInstanceMethod(selfClass, cusSEL);
BOOL addSucc = class_addMethod(selfClass, oriSEL, method_getImplementation(cusMethod), method_getTypeEncoding(cusMethod));
if (addSucc) {
class_replaceMethod(selfClass, cusSEL, method_getImplementation(oriMethod), method_getTypeEncoding(oriMethod));
}else {
method_exchangeImplementations(oriMethod, cusMethod);
}
});
}
- (void)mySendAction:(SEL)action to:(id)target forEvent:(UIEvent *)event {
[CountTool addClickCount];
[self mySendAction:action to:target forEvent:event];
}
@end
这里只是举了一两个小例子,更多用法读者可以深入理解这两种编程思维,举一反三。
Method Swizzling方法封装
细心的读者已经发现了,这个方法交换的代码好像变化不大,如果多处应用的话显得有些冗余,强迫症绝对不能接受,是的,必须将其封装之。
+ (void)swizzleMethods:(Class)class originalSelector:(SEL)origSel swizzledSelector:(SEL)swizSel {
Method origMethod = class_getInstanceMethod(class, origSel);
Method swizMethod = class_getInstanceMethod(class, swizSel);
BOOL didAddMethod = class_addMethod(class, origSel, method_getImplementation(swizMethod), method_getTypeEncoding(swizMethod));
if (didAddMethod) {
class_replaceMethod(class, swizSel, method_getImplementation(origMethod), method_getTypeEncoding(origMethod));
} else {
method_exchangeImplementations(origMethod, swizMethod);
}
}
后记
个人认为Method Swizzling是OC动态性的最好诠释,深入地去学习并理解其特性,将有助于我们在业务量不断增大的同时还能保持代码的低耦合度,降低维护的工作量和难度。
欢迎大家交流探讨。