快捷導(dǎo)航

詳解iOS Method Swizzling使用陷阱

更新時間：2020年11月05日 16:19:06 作者：大偉不是戴維 blog

這篇文章主要介紹了詳解iOS Method Swizzling使用陷阱，文中通過示例代碼介紹的非常詳細(xì)，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧

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

下面是iOS Method Swizzling的一種實現(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è)一個場景：

@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]時，發(fā)現(xiàn)CRASH了。

'-[Son1 new_easeapi]: unrecognized selector sent to instance 0x600002d701f0''

這就奇怪了，我們HOOK的是Son2的方法，怎么會產(chǎn)生Son1的崩潰？

為什么會發(fā)生崩潰

要解釋這個問題，還是要回到原理上。

首先明確一點，class_getInstanceMethod會查找父類的實現(xiàn)。

在上例中，easeapi是在Son2的父類Father中實現(xiàn)的，執(zhí)行method_exchangeImplementations之后，F(xiàn)ather的easeapi和Son2的new_easeapi進行了方法交換。

交換之后，當(dāng)Son1（Father的子類）執(zhí)行easeapi方法時，會通過「消息查找」找到Father的easeapi方法實現(xiàn)。

重點來了！

由于已經(jīng)發(fā)生了方法交換，實際上執(zhí)行的是Son2的new_easeapi方法。

-(void)new_easeapi {
  [self new_easeapi];
  //your code
}

可惡的是，在new_easeapi中執(zhí)行了[self new_easeapi]。此時這里的self是Son1實例，但Son1及其父類Father中并沒有new_easeapi的SEL，找不到對應(yīng)的SEL，自然就會CRASH。

什么情況下不會有問題？

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

至少在下面幾種場景中都不會有問題：

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

在上例中，如果我們在Son2中重寫了easeapi方法，執(zhí)行class_getInstanceMethod(class, fromSelector)獲取到的是Son2的easeapi實現(xiàn)，而不是Father的。這樣，執(zhí)行method_exchangeImplementations后，不會影響到Father的實現(xiàn)。

new_easeapi實現(xiàn)改進

- (void) new_easeapi {
  //[self new_easeapi];//屏蔽掉這句代碼
  //your code
}

在這個場景中，由于不會執(zhí)行[self new_easeapi]，也不會有問題。但這樣就達不到HOOK的效果。

改進優(yōu)化

推薦的Method Swizzling實現(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);
    }
  });
}

可以看到，至少有兩點變化：

dispatch_once
盡管dyld能夠保證調(diào)用Class的load時是線程安全的，但還是推薦使用dispatch_once做保護，防止極端情況下load被顯示強制調(diào)用時，重復(fù)交換（第一次交換成功，下次又換回來了...），造成邏輯混亂。

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

class_addMethod
給指定Class添加一個SEL的實現(xiàn)（或者說是SEL和指定IMP的綁定），添加成功返回YES，SEL已經(jīng)存在或添加失敗返回NO。

它有兩個需要注意的點：

如果該SEL在父類中有實現(xiàn)，則會添加一個覆蓋父類的方法；
如果該Class中已經(jīng)有SEL，則返回NO。

執(zhí)行class_addMethod能避免干擾到父類，這也是為什么推薦大家盡量先使用class_addMethod的原因。顯然易見，因為iOS Runtime消息傳遞機制的影響，只執(zhí)行method_exchangeImplementations操作時可能會影響到父類的方法。基于這個原理，如果HOOK的就是本類中實現(xiàn)的方法，那么直接用method_exchangeImplementations也是完全沒問題的。

class_replaceMethod