iOS之深入解析objc_msgSend消息转发机制的底层原理

一、抛砖引玉

• objc_msgSend() 消息发送的过程就是 通过 SEL 查找 IMP 的过程 。
• objc_msgSend() 是用 汇编语言 实现的，使用汇编实现的优势是：
  • 消息发送的过程需要足够的快速，高级语言在执行的时候都是需要翻译成汇编语言，经过编译成被机器识别的 二进制文件 ，使用汇编可以省去这一翻译过程，可以更快速被机器识别；
  • 对于消息的发送，存在很多未知的参数，这有很多不确定性，使用 汇编的寄存器 要比 C 或者 C++ 表现好的多。
• objc_msgSend() 通过汇编 快速查找方法缓存 ，如果能找到则调用 TailCallCachedImp 直接将方法缓存起来然后进行调用，objc_msgSend() 的快速查找请参考之前的文章：iOS之深入解析Runtime的objc_msgSend“快速查找”底层原理。
• 如果在缓存中查找不到，则就跳转到 CheckMiss ，然后执行 慢速查找流程 。objc_msgSend() 的慢速查找请参考之前的文章：iOS之深入解析Runtime的objc_msgSend“慢速查找”底层原理。
• 如果在“快速查找”和“慢速查找”两种流程都没找到方法实现的情况下，Apple给了 动态方法决议 和 消息转发 两个方式，如果这两个方式都没有做任何操作，就会报我们日常开发中常见的 方法未实现的崩溃报错 ：
  • 动态方法决议 ：慢速查找流程未找到后，会执行一次动态方法决议；
  • 消息转发 ：如果动态方法决议仍然没有找到实现，则进行消息转发；

二、方法未实现的崩溃报错

① 报错

• 定义YDWPerson类，其中 say666 实例方法和 sayNB 类方法均只有声明，并没有实现：

@interface YDWPerson : NSObject

@property (nonatomic, copy)   NSString *Name;
@property (nonatomic, strong) NSString *nickName;

- (void)sayNB;
- (void)sayMaster;
- (void)say666;
- (void)sayHello;

+ (void)sayNB;
+ (void)ydwClassMethod;

@end

@implementation YDWPerson

 - (void)sayHello{
    
    
    NSLog(@"%s",__func__);
}

 - (void)sayMaster{
    
    
    NSLog(@"%s",__func__);
}

 - (void)ydwClassMethod{
    
    
    NSLog(@"%s",__func__);
}
@end

• 在 main 中分别调用 YDWPerson 的实例方法 say666 和类方法 sayNB，运行程序，均会报错，提示方法未实现，如下所示：

-[YDWPerson say666]:unrecognized selector sent to instance 0x102937660
+[YDWPerson sayNB]:unrecognized selector sent to instance 0x102937660

② 源码分析

• 根据慢速查找的源码，我们发现，其报错最后都是走到 __objc_msgForward_impcache 方法，以下是报错流程的源码：

	STATIC_ENTRY __objc_msgForward_impcache
	
	// No stret specialization.
	b   __objc_msgForward
	
	END_ENTRY __objc_msgForward_impcache
	
	ENTRY __objc_msgForward
	
	adrp    x17, __objc_forward_handler@PAGE
	ldr p17, [x17, __objc_forward_handler@PAGEOFF]
	TailCallFunctionPointer x17
	    
	END_ENTRY __objc_msgForward

• 汇编实现中查找 __objc_forward_handler ，并没有找到，在源码中去掉一个下划线进行全局搜索 _objc_forward_handler ，可以看到有如下实现，本质是调用的 objc_defaultForwardHandler 方法：

	// Default forward handler halts the process.
	__attribute__((noreturn, cold)) void
	objc_defaultForwardHandler(id self, SEL sel) {
    
    
	    _objc_fatal("%c[%s %s]: unrecognized selector sent to instance %p "
	                "(no message forward handler is installed)", 
	                class_isMetaClass(object_getClass(self)) ? '+' : '-', 
	                object_getClassName(self), sel_getName(sel), self);
	}
	void *_objc_forward_handler = (void*)objc_defaultForwardHandler;

• 看着 objc_defaultForwardHandler 有没有很眼熟，这就是我们在日常开发中最常见的错误： 没有实现函数时崩溃报的错误提示 。
• 那么如何在崩溃前，如何操作可以防止方法未实现的崩溃呢？

③ 三次方法查找的避免崩溃机会

• 动态方法决议；
• 消息转发流程的快速转发；
• 消息转发流程的慢速转发；

三、动态方法决议

• 在慢速查找流程未找到方法实现时，首先会尝试一次 动态方法决议 ，其源码实现如下：

	static NEVER_INLINE IMP
	resolveMethod_locked(id inst, SEL sel, Class cls, int behavior) {
    
    
	    runtimeLock.assertLocked();
	    ASSERT(cls->isRealized());
	
	    runtimeLock.unlock();
	   
	    if (! cls->isMetaClass()) {
    
     
	        resolveInstanceMethod(inst, sel, cls);
	    } else {
    
    
	        resolveClassMethod(inst, sel, cls);
	  
	        if (!lookUpImpOrNil(inst, sel, cls)) {
    
    
	            resolveInstanceMethod(inst, sel, cls);
	        }
	    }
	
	    // chances are that calling the resolver have populated the cache
	    // so attempt using it
	    return lookUpImpOrForward(inst, sel, cls, behavior | LOOKUP_CACHE);
	}

• 源码分析：
  • if (! cls->isMetaClass())：如果类不是元类，调用对象的解析方法 resolveInstanceMethod(inst, sel, cls);
  • if (! cls->isMetaClass())：如果类是元类，调用类的解析方法 resolveClassMethod(inst, sel, cls);
  • if (!lookUpImpOrNil(inst, sel, cls))：如果没有找到或者为空，在元类的对象方法解析方法中查找；
  • return lookUpImpOrForward(inst, sel, cls, behavior | LOOKUP_CACHE);如果方法解析中将其实现指向其他方法，则继续走方法查找流程；
• 结论分析：
  • 如果是类，执行 实例方法 的动态方法决议 resolveInstanceMethod ；
  • 如果类是元类，执行 类方法 的动态方法决议 resolveClassMethod ，如果在元类中没有找到或者为空，则在元类的实例方法的动态方法决议 resolveInstanceMethod 中查找，主要是因为 类方法在元类中是实例方法 ，所以还需要查找元类中实例方法的动态方法决议；
  • 如果 动态方法决议 中，将其 实现指向了其他方法 ，则继续 查找指定的imp ，即继续慢速查找 lookUpImpOrForward 流程；
• 方法解析流程如下：

• 针对实例方法调用，在快速-慢速查找均没有找到实例方法的实现时，我们有一次避免的机会，即尝试一次动态方法决议，由于是实例方法，所以会走到 resolveInstanceMethod 方法，其源码如下：

	static void resolveInstanceMethod(id inst, SEL sel, Class cls) {
    
    
	    runtimeLock.assertUnlocked();
	    ASSERT(cls->isRealized());
	    SEL resolve_sel = @selector(resolveInstanceMethod:);
	    
	    if (!lookUpImpOrNil(cls, resolve_sel, cls->ISA())) {
    
    
	        // Resolver not implemented.
	        return;
	    }
	
	    BOOL (*msg)(Class, SEL, SEL) = (typeof(msg))objc_msgSend;
	    bool resolved = msg(cls, resolve_sel, sel);
	
	    // Cache the result (good or bad) so the resolver doesn't fire next time.
	    // +resolveInstanceMethod adds to self a.k.a. cls
	    IMP imp = lookUpImpOrNil(inst, sel, cls);
	
	    if (resolved  &&  PrintResolving) {
    
    
	        if (imp) {
    
    
	            _objc_inform("RESOLVE: method %c[%s %s] "
	                         "dynamically resolved to %p", 
	                         cls->isMetaClass() ? '+' : '-', 
	                         cls->nameForLogging(), sel_getName(sel), imp);
	        }
	        else {
    
    
	            // Method resolver didn't add anything?
	            _objc_inform("RESOLVE: +[%s resolveInstanceMethod:%s] returned YES"
	                         ", but no new implementation of %c[%s %s] was found",
	                         cls->nameForLogging(), sel_getName(sel), 
	                         cls->isMetaClass() ? '+' : '-', 
	                         cls->nameForLogging(), sel_getName(sel));
	        }
	    }
	}

• 源码分析：
  • 在发送 resolveInstanceMethod 消息前，需要查找cls类中是否有该方法的实现，即通过 lookUpImpOrNil 方法又会进入 lookUpImpOrForward 慢速查找流程查找 resolveInstanceMethod 方法，如果没有则直接返回，如果有则发送 resolveInstanceMethod 消息；
  • 再次慢速查找实例方法的实现，即通过 lookUpImpOrNil 方法又会进入 lookUpImpOrForward 慢速查找流程查找实例方法；
• 针对实例方法 say666 未实现的报错崩溃，可以通过在类中重写 resolveInstanceMethod 类方法，并将其指向其他方法的实现，即在YDWPerson中重写 resolveInstanceMethod 类方法，将实例方法say666的实现指向 sayMaster 方法实现，如下所示：

	+ (BOOL)resolveInstanceMethod:(SEL)sel{
    
    
	    if (sel == @selector(say666)) {
    
    
	        NSLog(@"%@ 来了", NSStringFromSelector(sel));
	        // 获取sayMaster方法的imp
	        IMP imp = class_getMethodImplementation(self, @selector(sayMaster));
	        // 获取sayMaster的实例方法
	        Method sayMethod  = class_getInstanceMethod(self, @selector(sayMaster));
	        // 获取sayMaster的丰富签名
	        const char *type = method_getTypeEncoding(sayMethod);
	        // 将sel的实现指向sayMaster
	        return class_addMethod(self, sel, imp, type);
	    }
	    return [super resolveInstanceMethod:sel];
	}

• 重新运行，其打印结果如下：

	say666 来了
	say666 来了
	-[YDWPerson sayMaster]

• 从结果中可以发现，resolveInstanceMethod动态决议方法中“来了”打印了两次，这是为什么呢？通过堆栈信息可以看出:
  • 第一次的“来了”是在查找say666方法时会进入动态方法决议；
  • 第二次“来了”是在慢速转发流程中调用了CoreFoundation框架中的NSObject(NSObject) methodSignatureForSelector:后，会再次进入动态决议。

(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 10.1
  * frame #0: 0x0000000100003884 HelloWorld`+[YDWPerson resolveInstanceMethod:](self=YDWPerson, _cmd="resolveInstanceMethod:", sel="sayNB") at YDWPerson.m:19:45
    frame #1: 0x0000000100313d47 libobjc.A.dylib`resolveInstanceMethod(inst=0x0000000000000000, sel="sayNB", cls=YDWPerson) at objc-runtime-new.mm:6000:21
    frame #2: 0x00000001002ff7c3 libobjc.A.dylib`resolveMethod_locked(inst=0x0000000000000000, sel="sayNB", cls=YDWPerson, behavior=0) at objc-runtime-new.mm:6042:9
    frame #3: 0x00000001002ff0ec libobjc.A.dylib`lookUpImpOrForward(inst=0x0000000000000000, sel="sayNB", cls=YDWPerson, behavior=0) at objc-runtime-new.mm:6191:16
    frame #4: 0x00000001002d8cc9 libobjc.A.dylib`class_getInstanceMethod(cls=YDWPerson, sel="sayNB") at objc-runtime-new.mm:5921:5
    frame #5: 0x00007fff316a1c68 CoreFoundation`__methodDescriptionForSelector + 282
    frame #6: 0x00007fff316bd57c CoreFoundation`-[NSObject(NSObject) methodSignatureForSelector:] + 38
    frame #7: 0x00007fff31689fc0 CoreFoundation`___forwarding___ + 408
    frame #8: 0x00007fff31689d98 CoreFoundation`__forwarding_prep_0___ + 120
    frame #9: 0x00000001000033ff HelloWorld`testMessageForward at main.m:164:5
    frame #10: 0x0000000100003444 HelloWorld`main(argc=1, argv=0x00007ffeefbff478) at main.m:169:9
    frame #11: 0x00007fff6b73ecc9 libdyld.dylib`start + 1
    frame #12: 0x00007fff6b73ecc9 libdyld.dylib`start + 1

• 针对类方法，与实例方法类似，同样可以通过重写resolveClassMethod类方法来解决前文的崩溃问题，即在YDWPerson类中重写该方法，并将sayNB类方法的实现指向类方法ydwClassMethod：

	+ (BOOL)resolveClassMethod:(SEL)sel {
    
    
	    if (sel == @selector(sayNB)) {
    
    
	        NSLog(@"%@ 来了", NSStringFromSelector(sel));
	        
	        IMP imp = class_getMethodImplementation(objc_getMetaClass("YDWPerson"), @selector(ydwClassMethod));
	        Method ydwClassMethod  = class_getInstanceMethod(objc_getMetaClass("YDWPerson"), @selector(ydwClassMethod));
	        const char *type = method_getTypeEncoding(ydwClassMethod);
	        return class_addMethod(objc_getMetaClass("YDWPerson"), sel, imp, type);
	    }
	    
	    return [super resolveClassMethod:sel];
	}

• resolveClassMethod类方法的重写需要注意一点，传入的cls不再是类，而是元类，可以通过objc_getMetaClass方法获取类的元类，原因是因为类方法在元类中是实例方法；
• 上面的这种方式是单独在每个类中重写，有没有更好的，一劳永逸的方法呢？其实通过方法慢速查找流程可以发现其查找路径有两条：
  • 实例方法：类 – 父类 – 根类 – nil
  • 类方法：元类 – 根元类 – 根类 – nil
• 它们的共同点是如果前面没找到，都会来到根类即NSObject中查找，所以我们是否可以将上述的两个方法统一整合在一起呢？答案是可以的，可以通过NSObject添加分类的方式来实现统一处理，而且由于类方法的查找，在其继承链，查找的也是实例方法，所以可以将实例方法和类方法的统一处理放在resolveInstanceMethod方法中，如下所示：

	+ (BOOL)resolveInstanceMethod:(SEL)sel{
    
    
	    if (sel == @selector(say666)) {
    
    
	        NSLog(@"%@ 来了", NSStringFromSelector(sel));
	        
	        IMP imp = class_getMethodImplementation(self, @selector(sayMaster));
	        Method sayMethod  = class_getInstanceMethod(self, @selector(sayMaster));
	        const char *type = method_getTypeEncoding(sayMethod);
	        return class_addMethod(self, sel, imp, type);
	    } else if (sel == @selector(sayNB)) {
    
    
	        NSLog(@"%@ 来了", NSStringFromSelector(sel));
	        
	        IMP imp = class_getMethodImplementation(objc_getMetaClass("YDWPerson"), @selector(ydwClassMethod));
	        Method ydwClassMethod  = class_getInstanceMethod(objc_getMetaClass("YDWPerson"), @selector(ydwClassMethod));
	        const char *type = method_getTypeEncoding(ydwClassMethod);
	        return class_addMethod(objc_getMetaClass("YDWPerson"), sel, imp, type);
	    }
	    return NO;
	}

• 这种方式的实现，正好与源码中针对类方法的处理逻辑是一致的，即完美阐述为什么调用了类方法动态方法决议，还要调用对象方法动态方法决议，其根本原因还是类方法在元类中的实例方法。
• 当然，上面这种写法还是会有其他的问题，比如系统方法也会被更改，针对这一点，是可以优化的，即我们可以针对自定义类中方法统一方法名的前缀，根据前缀来判断是否是自定义方法，然后统一处理自定义方法，例如可以在崩溃前pop到首页，主要是用于app线上防崩溃的处理，提升用户的体验。

四、消息转发流程

在慢速查找的流程中，如果“快速查找”和“慢速查找”都没有找到方法实现，并且动态方法决议也不行，就会使用消息转发，但是找遍了源码也没有发现消息转发的相关源码，那该怎么处理呢？其实，可以通过以下方式来了解，方法调用崩溃前都走了哪些方法：

• 通过 instrumentObjcMessageSends 方式打印发送消息的日志；
• 通过 hopper/IDA反编译 ；

① instrumentObjcMessageSends

• 通过 lookUpImpOrForward --> log_and_fill_cache --> logMessageSend ，在logMessageSend源码下方找到 instrumentObjcMessageSends 的源码实现，所以，在 main 中调用 instrumentObjcMessageSends 打印方法调用的日志信息，有以下两点准备工作：
  • 打开 o bjcMsgLogEnabled 开关，即调用 instrumentObjcMessageSends 方法时，传入YES；
  • 在 main 中通过 extern 声明 instrumentObjcMessageSends 方法。

extern void instrumentObjcMessageSends(BOOL flag);

int main(int argc, const char * argv[]) {
    
    
    @autoreleasepool {
    
    

        YDWPerson *person = [YDWPerson alloc];
        instrumentObjcMessageSends(YES);
        [person sayHello];
        instrumentObjcMessageSends(NO);
        NSLog(@"Hello, World!");
    }
    return 0;
}

• 通过 logMessageSend 源码，了解到消息发送打印信息存储在 /tmp/msgSends 目录，如下所示：

• 运行代码，并前往 /tmp/msgSends 目录，发现有msgSends开头的日志文件，打开发现在崩溃前，执行了以下方法：
  • 两次动态方法决议： resolveInstanceMethod 方法
  • 两次消息快速转发： forwardingTargetForSelector 方法
  • 两次消息慢速转发： methodSignatureForSelector + resolveInstanceMethod

② 通过hopper/IDA反编译

Hopper和IDA是一个可以帮助我们静态分析可视性文件的工具，可以将可执行文件反汇编成伪代码、控制流程图等，下面以Hopper为例(注：hopper高级版本是一款收费软件，针对比较简单的反汇编需求来说，demo版本便已足够使用)

• 运行程序崩溃，查看堆栈信息：

• 发现___forwarding___来自CoreFoundation：

• 通过image list，读取整个镜像文件,然后搜索CoreFoundation，查看其可执行文件的路径：

• 通过文件路径，找到CoreFoundation的可执行文件：

• 打开hopper，选择Try the Demo，然后将上一步的可执行文件拖入hopper进行反汇编，选择x86(64 bits)：

• 点击Try the Demo之后，继续：

• 以下是反汇编后的界面，主要使用上面的三个功能，分别是汇编、流程图、伪代码：

• 通过左侧的搜索框搜索__forwarding_prep_0___，然后选择伪代码。forwarding_prep_0___的汇编伪代码，跳转至___forwarding_，如下：

• 以下是 forwarding 的伪代码实现，首先是查看是否实现 forwardingTargetForSelector 方法，如果没有响应，跳转至 loc_6459b 即快速转发没有响应，进入慢速转发流程：

• 跳转至loc_6459b，在其下方判断是否响应 methodSignatureForSelector 方法：

• 如果没有响应，跳转至 loc_6490b ，则直接报错；
• 如果获取 methodSignatureForSelector 的方法签名为nil，也会直接报错：

• 如果 methodSignatureForSelector 返回值不为空，则在 forwardInvocation 方法中对 invocation 进行处理：

• 通过以上两种查找方式可以验证，消息转发的方法有三个：
  • 快速转发： forwardingTargetForSelector ；
  • 慢速转发： methodSignatureForSelector 和 forwardInvocation ；
• 综上所述，消息转发整体的流程如下：

③ 消息转发原理总结

• 当 慢速查找 ，以及 动态方法决议 均没有找到实现时，进行 消息转发 ，首先是进行 快速消息转发 ，即走到 forwardingTargetForSelector 方法：
  • 如果返回 消息接收者 ，在消息接收者中还是没有找到，则进入另一个方法的查找流程；
  • 如果返回nil，则进入 慢速消息转发 ；
• 执行到 methodSignatureForSelector 方法：
  • 如果返回的方法签名为 nil ，则 直接崩溃报错 ；
  • 如果返回的方法签名不为 nil ，走到 forwardInvocation 方法中，对 invocation 事务进行处理，如果不处理也不会报错。