在閱讀團(tuán)隊(duì)一項(xiàng)目源碼時(shí)，發(fā)現(xiàn)Method Swizzling的寫(xiě)法有些瑕疵。這篇文章主要就介紹iOS Method Swizzling的正確寫(xiě)法應(yīng)該是什么樣的。

下面是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);}

這種寫(xiě)法在一些時(shí)候能正常工作，但實(shí)際上有些問(wèn)題。那么問(wèn)題在哪里呢？

一個(gè)例子

為了說(shuō)明這個(gè)問(wèn)題，我們先來(lái)假設(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

看樣子沒(méi)什么問(wèn)題，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è)問(wèn)題，還是要回到原理上。

首先明確一點(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ì)通過(guò)「消息查找」找到Father的easeapi方法實(shí)現(xiàn)。

重點(diǎn)來(lái)了！

由于已經(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中并沒(méi)有new_easeapi的SEL，找不到對(duì)應(yīng)的SEL，自然就會(huì)CRASH。

什么情況下不會(huì)有問(wèn)題？

上面說(shuō)了：「這種寫(xiě)法在一些時(shí)候能正常工作」。那么，到底什么時(shí)候直接執(zhí)行method_exchangeImplementations不會(huì)有問(wèn)題呢？

至少在下面幾種場(chǎng)景中都不會(huì)有問(wèn)題：

Son2中有easeapi的實(shí)現(xiàn)

在上例中，如果我們?cè)赟on2中重寫(xiě)了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ì)有問(wèn)題。但這樣就達(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ù)交換（第一次交換成功，下次又換回來(lái)了...），造成邏輯混亂。

增加了class_addMethod判斷class_addMethod & class_replaceMethod還是從定義上理解。

class_addMethod給指定Class添加一個(gè)SEL的實(shí)現(xiàn)（或者說(shuō)是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的原因。顯然易見(jiàn)，因?yàn)閕OS Runtime消息傳遞機(jī)制的影響，只執(zhí)行method_exchangeImplementations操作時(shí)可能會(huì)影響到父類的方法。基于這個(gè)原理，如果HOOK的就是本類中實(shí)現(xiàn)的方法，那么直接用method_exchangeImplementations也是完全沒(méi)問(wèn)題的。

class_replaceMethod

如果該Class不存在指定SEL，則class_replaceMethod的作用就和class_addMethod一樣； 如果該Class存在指定的SEL，則class_replaceMethod的作用就和method_setImplementation一樣。

到此這篇關(guān)于詳解iOS Method Swizzling使用陷阱的文章就介紹到這了,更多相關(guān)iOS Method Swizzling內(nèi)容請(qǐng)搜索好吧啦網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持好吧啦網(wǎng)！