详解iOS Method Swizzling使用陷阱_IOS

在阅读团队一项目源码时，发现method swizzling的写法有些瑕疵。这篇文章主要就介绍ios method swizzling的正确写法应该是什么样的。

下面是ios method swizzling的一种实现：

+ (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);
}

这种写法在一些时候能正常工作，但实际上有些问题。那么问题在哪里呢？

一个例子

为了说明这个问题，我们先来假设一个场景：

@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的方法也交换成功，但当我们执行[son1 easeapi]时，发现crash了。

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

这就奇怪了，我们hook的是son2的方法，怎么会产生son1的崩溃？

为什么会发生崩溃

要解释这个问题，还是要回到原理上。

首先明确一点，class_getinstancemethod会查找父类的实现。

在上例中，easeapi是在son2的父类father中实现的，执行method_exchangeimplementations之后，father的easeapi和son2的new_easeapi进行了方法交换。

交换之后，当son1（father的子类）执行easeapi方法时，会通过「消息查找」找到father的easeapi方法实现。

重点来了！

由于已经发生了方法交换，实际上执行的是son2的new_easeapi方法。

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

可恶的是，在new_easeapi中执行了[self new_easeapi]。此时这里的self是son1实例，但son1及其父类father中并没有new_easeapi的sel，找不到对应的sel，自然就会crash。

什么情况下不会有问题？

上面说了：「这种写法在一些时候能正常工作」。那么，到底什么时候直接执行method_exchangeimplementations不会有问题呢？

至少在下面几种场景中都不会有问题：

son2中有easeapi的实现

在上例中，如果我们在son2中重写了easeapi方法，执行class_getinstancemethod(class, fromselector)获取到的是son2的easeapi实现，而不是father的。这样，执行method_exchangeimplementations后，不会影响到father的实现。

new_easeapi实现改进

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

在这个场景中，由于不会执行[self new_easeapi]，也不会有问题。但这样就达不到hook的效果。

改进优化

推荐的method swizzling实现：

+ (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能够保证调用class的load时是线程安全的，但还是推荐使用dispatch_once做保护，防止极端情况下load被显示强制调用时，重复交换（第一次交换成功，下次又换回来了...），造成逻辑混乱。

增加了class_addmethod判断
class_addmethod & class_replacemethod
还是从定义上理解。

class_addmethod
给指定class添加一个sel的实现（或者说是sel和指定imp的绑定），添加成功返回yes，sel已经存在或添加失败返回no。

它有两个需要注意的点：

如果该sel在父类中有实现，则会添加一个覆盖父类的方法；
如果该class中已经有sel，则返回no。

执行class_addmethod能避免干扰到父类，这也是为什么推荐大家尽量先使用class_addmethod的原因。显然易见，因为ios runtime消息传递机制的影响，只执行method_exchangeimplementations操作时可能会影响到父类的方法。基于这个原理，如果hook的就是本类中实现的方法，那么直接用method_exchangeimplementations也是完全没问题的。

class_replacemethod