前言

如果你還不知道什麽是Method Swizzling，你可以看看NSHipster 的文章 ，我簡單介紹一下，method swizzling 可以看成劫持了一個方法。

我們可以看看NSHipster 的文章中有以下代碼：

- (void)xxx_viewWillAppear:(BOOL)animated {
    [self xxx_viewWillAppear:animated];
    NSLog(@"viewWillAppear: %@", self);
}

是不是覺得遞歸無限循環，事實上並不會，你可以這麽理解，一個具體的SEL是個名字，一個具體的IMP是個函數指針，在類裏面它們是靠一個表建立聯系。

假設（純屬虛構） UIViewController 的 @selector(viewWillAppear:) 對應的內部實現為以下

void _UIKIT_Internal_UIViewController_viewWillAppear(id vc, SEL selector, BOOL animated) {
  ...// ^_^蘋果私有代碼
}

假設UIViewController 的 @selector(xxx_viewWillAppear:) 的實現為以下

void my_xxx_viewWillAppear(id vc, SEL selector, BOOL animated) {
  [vc performSelector:@selector(xxx_viewWillAppear) withObject:@(animated)];  
  NSLog(@"viewWillAppear: %@", vc);
}
 

那麽未替換方法前@selector(viewWillAppear:)對應的指針就是&_UIKIT_Internal_UIViewController_viewWillAppear

那麽未替換方法前@selector(xxx_viewWillAppear:)對應的指針就是&my_xxx_viewWillAppear

一旦替換方法後，@selector(viewWillAppear:)對應的指針就是&my_xxx_viewWillAppear，
@selector(xxx_viewWillAppear:)對應的指針就是&_UIKIT_Internal_UIViewController_viewWillAppear

my_xxx_viewWillAppear 中的 [vc performSelector:@selector(xxx_viewWillAppear) withObject:@(animated)];
相當於什麽，相當於 調用@selector(xxx_viewWillAppear:)所指的函數&_UIKIT_Internal_UIViewController_viewWillAppear， 也就是相當於調用原來的函數，所以這並不是遞歸。

存在的危險

1. 有些NSObject類是類簇，替換方法要找到真正的類，如NSArray替換方法，通常用‘_NSArrayM‘或‘_NSArrayI‘
2. 執行順序問題，ViewController是自己寫的類，ViewController的load方法和UIViewController的category裏的load方法哪個先執行，如果是ViewController的先執行，那麽UIViewController的swizzling就對ViewController無效，如果ViewController的後執行就一切正常，代碼如下

@implementation UIViewController (Tracking)

+ (void)load {
  static dispatch_once_t onceToken;
  dispatch_once(&onceToken, ^{
    [self replaceOriginalSelector:@selector(viewWillAppear:) withNewSelector:@selector(xxx_viewWillAppear:)];
  });
}

- (void)xxx_viewWillAppear:(BOOL)animated {
  [self xxx_viewWillAppear:animated];
  NSLog(@"x_viewWillAppear: %@", self);
}
@end

@interface ViewController ()

@end

@implementation ViewController

+ (void)load {
  static dispatch_once_t onceToken;
  dispatch_once(&onceToken, ^{
    [self replaceOriginalSelector:@selector(viewWillAppear:) withNewSelector:@selector(yyy_viewWillAppear:)];
  });
}

- (void)yyy_viewWillAppear:(BOOL)animated {
  [self yyy_viewWillAppear:animated];
  NSLog(@"y_viewWillAppear: %@", self);
}

@end

3.也是順序問題
以下，來自另一篇文章defagos.github.io
它是這麽說的，NSObject 實現了 -awakeFromNib，但是它的子類UIView，孫類UILabel都沒有在本類實現- awakeFromNib，那麽替換時如果不寫在category +(void) load方法裏，那麽順序也是個問題

假設我們先替換了UILabel的- awakeFromNib方法，然後再替換了UIView的- awakeFromNib，那麽UILabel的- awakeFromNib方法就不會執行UIView的- awakeFromNib方法，因為它們都是獨立替換的是NSObject方法，這篇文章defagos.github.io 提供了一個解決方案，當本類沒有實現方法（如 UILabel -awakeFromNib）時，首先先添加一個block方法 調用[super awakeFromNib];，我初次看到也是覺得這個方式很好，但是我發現兩點不足，

1. 在構建objc_super時，如果父類本身沒有實現方法，.super_class = class_getSuperclass(clazz)，這麽寫好像是沒有用的，似乎super_class要填真正實現方法的祖先類，而不能一概的寫class_getSuperclass

   struct objc_super super = {
           .receiver = self,
           .super_class = class_getSuperclass(clazz)
       };

2. va_list的使用

id (*objc_msgSendSuper_typed)(struct objc_super *, SEL, va_list) = (void *)&objc_msgSendSuper;

由於 va_list 變量最後是靠宏 va_arg(ap, type) 來獲取的，type又是未知的，這個函數指針的強制轉換轉換可能會出現問題

結語

可見，Swizzling正確的順序是十分重要的，（共同點：類本身沒有真正實現方法）

• 如果你的Swizzling是靜態的，那麽就保證父類的Swizzling發生在子類的Swizzling前
• 如果你的Swizzling是動態的或者你管不好他們先後順序，那麽就要用defagos的方法動態的call objc_msgSendSuper，
• 或許你勤快一點還可以直接在category裏面重寫，

  - (void)awakeFromNib {
  [super awakeFromNib];
  }

iOS 開發：Method Swizzling