iOS Method Swizzling 使用陷阱

 原创    2020-11-04

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

下面是iOS Method Swizzling的一种实现:

+ (void)load {
    Class class = [self class];
    
    SEL fromSelector = @selector(func);
    SEL toSelector = @selector(new_func);
    
    Method fromMethod = class_getInstanceMethod(class, fromSelector);
    Method toMethod = class_getInstanceMethod(class, toSelector);
    
    method_exchangeImplementations(fromMethod, toMethod);
} 

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

一个例子

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

@interface Father: NSObject
-(void)func;
@end
@implementation Father
-(void)func {
    //your code
}
@end

//Son1继承自Father
@interface Son1: Father
@end
@implementation Son1
@end

//Son2继承自Father,并HOOK了func方法。
@interface Son2: Father
@end
@implementation Son2
+ (void)load {
    Class class = [self class];
    
    SEL fromSelector = @selector(func);
    SEL toSelector = @selector(new_func);
    
    Method fromMethod = class_getInstanceMethod(class, fromSelector);
    Method toMethod = class_getInstanceMethod(class, toSelector);
    
    method_exchangeImplementations(fromMethod, toMethod);
}
-(void)new_func {
    [self new_func];
    //your code
}
@end

看样子没什么问题,Son2的方法也交换成功,但当我们执行[Son1 func]时,发现CRASH了。

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

这就奇怪了,我们HOOK的是Son2的方法,怎么会产生Son1的崩溃?

为什么会发生崩溃

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

首先明确一点,class_getInstanceMethod会查找父类的实现。

在上例中,func是在Son2的父类Father中实现的,执行method_exchangeImplementations之后,Father的func和Son2的new_func进行了方法交换。

交换之后,当Son1(Father的子类)执行func方法时,会通过「消息查找」找到Father的func方法实现。

重点来了!

由于已经发生了方法交换,实际上执行的是Son2的new_func方法。

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

可恶的是,在new_func中执行了[self new_func]。此时这里的self是Son1实例,但Son1及其父类Father中并没有new_func的SEL,找不到对应的SEL,自然就会CRASH。

什么情况下不会有问题?

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

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

  • Son2中有func的实现

在上例中,如果我们在Son2中重写了func方法,执行class_getInstanceMethod(class, fromSelector)获取到的是Son2的func实现,而不是Father的。这样,执行method_exchangeImplementations后,不会影响到Father的实现。

  • new_func实现改进
- (void) new_func {
    //[self new_func];//屏蔽掉这句代码
    //your code
}

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

改进优化

推荐的Method Swizzling实现:

+ (void)load {
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        Class class = [self class];
        
        SEL fromSelector = @selector(func);
        SEL toSelector = @selector(new_func);
        
        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

  • 如果该Class不存在指定SEL,则class_replaceMethod的作用就和class_addMethod一样;
  • 如果该Class存在指定的SEL,则class_replaceMethod的作用就和method_setImplementation一样。
文章最后修改于 2023-08-01

相关文章:

iOS crash log分析实践
分享 AppStore 审核的一些经验教训
iOS 抓取网络数据包
iOS LLVM 混淆插件:Hanabi
iOS 13 中对 dyld 3 的改进和优化

发表留言

您的电子邮箱地址不会被公开,必填项已用*标注。发布的留言可能不会立即公开展示,请耐心等待审核通过。