下面是iOS Method Swizzling的一種實(shí)現(xiàn)：
+ (void)load {
Class class = [self class];
SEL fromSelector = @selector(func);
SEL toSelector = @selector(easeapi_func);
Method fromMethod = class_getInstanceMethod(class, fromSelector);
Method toMethod = class_getInstanceMethod(class, toSelector);
method_exchangeImplementations(fromMethod, toMethod);
}
這種寫法在一些時(shí)候能正常工作捞烟，但實(shí)際上有些問題吓蘑。那么問題在哪里呢深寥？
一個(gè)例子
為了說明這個(gè)問題忙迁，我們先來假設(shè)一個(gè)場(chǎng)景：
@interface Father: NSObject
-(void)easeapi;
@end
@implementation Father
-(void)easeapi {
//your code
}
@end
//Son1繼承自Father
@interface Son1: Father
@end
@implementation Son1
@end
//Son2繼承自Father，并HOOK了easeapi方法徙歼。
@interface Son2: Father
@end
@implementation Son2
+ (void)load {
Class class = [self class];
SEL fromSelector = @selector(easeapi);
SEL toSelector = @selector(new_easeapi);
Method fromMethod = class_getInstanceMethod(class, fromSelector);
Method toMethod = class_getInstanceMethod(class, toSelector);
method_exchangeImplementations(fromMethod, toMethod);
}
-(void)new_easeapi {
[self new_easeapi];
//your code
}
@end
看樣子沒什么問題犁河，Son2的方法也交換成功，但當(dāng)我們執(zhí)行[Son1 easeapi]時(shí)魄梯，發(fā)現(xiàn)CRASH了桨螺。
'-[Son1 new_easeapi]: unrecognized selector sent to instance 0x600002d701f0''
這就奇怪了，我們HOOK的是Son2的方法酿秸，怎么會(huì)產(chǎn)生Son1的崩潰灭翔？
為什么會(huì)發(fā)生崩潰
要解釋這個(gè)問題，還是要回到原理上辣苏。
首先明確一點(diǎn)肝箱，class_getInstanceMethod會(huì)查找父類的實(shí)現(xiàn)哄褒。
在上例中，easeapi是在Son2的父類Father中實(shí)現(xiàn)的煌张，執(zhí)行method_exchangeImplementations之后呐赡，F(xiàn)ather的easeapi和Son2的new_easeapi進(jìn)行了方法交換。
交換之后骏融，當(dāng)Son1（Father的子類）執(zhí)行easeapi方法時(shí)链嘀，會(huì)通過「消息查找」找到Father的easeapi方法實(shí)現(xiàn)。
重點(diǎn)來了绎谦！
由于已經(jīng)發(fā)生了方法交換管闷，實(shí)際上執(zhí)行的是Son2的new_easeapi方法。
-(void)new_easeapi {
[self new_easeapi];
//your code
}
可惡的是窃肠，在new_easeapi中執(zhí)行了[self new_easeapi]包个。此時(shí)這里的self是Son1實(shí)例，但Son1及其父類Father中并沒有new_easeapi的SEL冤留，找不到對(duì)應(yīng)的SEL碧囊，自然就會(huì)CRASH。
什么情況下不會(huì)有問題纤怒？
上面說了：「這種寫法在一些時(shí)候能正常工作」糯而。那么，到底什么時(shí)候直接執(zhí)行method_exchangeImplementations不會(huì)有問題呢泊窘？
至少在下面幾種場(chǎng)景中都不會(huì)有問題：
- Son2中有easeapi的實(shí)現(xiàn)
在上例中熄驼，如果我們?cè)赟on2中重寫了easeapi方法，執(zhí)行class_getInstanceMethod(class, fromSelector)獲取到的是Son2的easeapi實(shí)現(xiàn)烘豹，而不是Father的瓜贾。這樣，執(zhí)行method_exchangeImplementations后携悯，不會(huì)影響到Father的實(shí)現(xiàn)祭芦。
- new_easeapi實(shí)現(xiàn)改進(jìn)
- (void) new_easeapi {
//[self new_easeapi];//屏蔽掉這句代碼
//your code
}
在這個(gè)場(chǎng)景中，由于不會(huì)執(zhí)行[self new_easeapi]憔鬼，也不會(huì)有問題龟劲。但這樣就達(dá)不到HOOK的效果。
改進(jìn)優(yōu)化
推薦的Method Swizzling實(shí)現(xiàn)：
+ (void)load {
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
Class class = [self class];
SEL fromSelector = @selector(easeapi);
SEL toSelector = @selector(new_easeapi);
Method fromMethod = class_getInstanceMethod(class, fromSelector);
Method toMethod = class_getInstanceMethod(class, toSelector);
if(class_addMethod(class, fromSelector, method_getImplementation(toMethod), method_getTypeEncoding(toMethod))) {
class_replaceMethod(class, toSelector, method_getImplementation(fromMethod), method_getTypeEncoding(fromMethod));
} else {
method_exchangeImplementations(fromMethod, toMethod);
}
});
}
可以看到轴或，至少有兩點(diǎn)變化：
- dispatch_once
盡管dyld能夠保證調(diào)用Class的load時(shí)是線程安全的昌跌，但還是推薦使用dispatch_once做保護(hù)，防止極端情況下load被顯示強(qiáng)制調(diào)用時(shí)照雁，重復(fù)交換（第一次交換成功避矢，下次又換回來了...），造成邏輯混亂。
- 增加了class_addMethod判斷
class_addMethod & class_replaceMethod
還是從定義上理解审胸。
class_addMethod
給指定Class添加一個(gè)SEL的實(shí)現(xiàn)（或者說是SEL和指定IMP的綁定），添加成功返回YES卸勺，SEL已經(jīng)存在或添加失敗返回NO砂沛。
它有兩個(gè)需要注意的點(diǎn)：
- 如果該SEL在父類中有實(shí)現(xiàn)，則會(huì)添加一個(gè)覆蓋父類的方法曙求；
- 如果該Class中已經(jīng)有SEL碍庵，則返回NO。
執(zhí)行class_addMethod能避免干擾到父類悟狱，這也是為什么推薦大家盡量先使用class_addMethod的原因静浴。顯然易見，因?yàn)閕OS Runtime消息傳遞機(jī)制的影響挤渐，只執(zhí)行method_exchangeImplementations操作時(shí)可能會(huì)影響到父類的方法苹享。基于這個(gè)原理浴麻，如果HOOK的就是本類中實(shí)現(xiàn)的方法得问，那么直接用method_exchangeImplementations也是完全沒問題的。
class_replaceMethod
- 如果該Class不存在指定SEL软免，則class_replaceMethod的作用就和class_addMethod一樣宫纬；
- 如果該Class存在指定的SEL，則class_replaceMethod的作用就和method_setImplementation一樣膏萧。
