消息转发流程分析

我们之前分析了消息查找流程

首先，调用objc_msgSend，从cache中快速查找，命中就执行对应的imp

其次，如果cache中没有找到，就调用lookUpImpOrForward进行慢速查找，找到就插入cache，便于下次执行时能快速的查找调用，并执行对应的imp

最后，如果还是没有找到，那么就进入了消息转发流程，下面我们就来分析一下消息转发流程

消息转发的入口在lookUpImpOrForward里

    // No implementation found. Try method resolver once.

    if (slowpath(behavior & LOOKUP_RESOLVER)) {
        behavior ^= LOOKUP_RESOLVER;
        return resolveMethod_locked(inst, sel, cls, behavior);
    }

如果没有找到，只做一次转发

再来看看resolveMethod_locked 

static NEVER_INLINE IMP
resolveMethod_locked(id inst, SEL sel, Class cls, int behavior)
{
    runtimeLock.assertLocked();
    ASSERT(cls->isRealized());

    runtimeLock.unlock();

    if (! cls->isMetaClass()) {
        // try [cls resolveInstanceMethod:sel]
        resolveInstanceMethod(inst, sel, cls);
    } 
    else {
        // try [nonMetaClass resolveClassMethod:sel]
        // and [cls resolveInstanceMethod:sel]
        resolveClassMethod(inst, sel, cls);
        if (!lookUpImpOrNilTryCache(inst, sel, cls)) {
            resolveInstanceMethod(inst, sel, cls);
        }
    }

    // chances are that calling the resolver have populated the cache
    // so attempt using it
    return lookUpImpOrForwardTryCache(inst, sel, cls, behavior);
}

如果是类，那么尝试把sel转发给+resolveInstanceMethod:方法处理

如果是元类，那么首先尝试把sel转发给+ resolveClassMethod:方法处理，如果没有处理，那么再尝试转发给+resolveInstanceMethod:方法处理

static void resolveInstanceMethod(id inst, SEL sel, Class cls)
{
    runtimeLock.assertUnlocked();
    ASSERT(cls->isRealized());
    SEL resolve_sel = @selector(resolveInstanceMethod:);

    if (!lookUpImpOrNilTryCache(cls, resolve_sel, cls->ISA(/*authenticated*/true))) {
        // 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 = lookUpImpOrNilTryCache(inst, sel, cls);
...
}

不管+ resolveInstanceMethod:或+ resolveClassMethod:方法有没有处理，都调用lookUpImpOrNilTryCache查找一下，并把结果写到cache里，方便下次查找

最后，再调用lookUpImpOrForwardTryCache查找结果，因为前面刚刚把结果存到了cache里，所以这里是从cache里快速的得到处理结果，并返回

//  这个函数只是快速的从cache里得到结果，并返回
return lookUpImpOrForwardTryCache(inst, sel, cls, behavior);

我们下面来看看+ resolveInstanceMethod:处理函数

这个函数要我们自己重写，把没有实现的方法，重定向到另一个方法
我们先实现一个空方法，运行看看

+ (BOOL)resolveInstanceMethod:(SEL)sel {
    NSLog(@"%s", __func__);
    return [super resolveInstanceMethod:sel];
}

调用一个未实现重定向的空方法，输出结果：

2021-07-02 00:35:32.361774+0800 KCObjcBuild[22150:1794694] +[LGPerson resolveInstanceMethod:]
2021-07-02 00:35:32.362378+0800 KCObjcBuild[22150:1794694] +[LGPerson resolveInstanceMethod:]
2021-07-02 00:35:32.362518+0800 KCObjcBuild[22150:1794694] -[LGPerson say1]: unrecognized selector sent to instance 0x1012102e0

在报错之前，这个函数被调用了两次，为什么会被调用两次呢？我们明明只调用了一次，我们设个符号断点来看看，到底再哪里还被调来一次。注意：直接在代码行号左侧点一下设置的断点断不住，要下符号断点，看看第一次输出调用堆栈：

2021-07-02 00:47:38.479311+0800 KCObjcBuild[25860:1813837] +[LGPerson resolveInstanceMethod:]
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = instruction step over
  * frame #0: 0x0000000100003de6 KCObjcBuild`+[LGPerson resolveInstanceMethod:] + 38
    frame #1: 0x0000000100311356 libobjc.A.dylib`resolveInstanceMethod(inst=0x0000000101145770, sel="say1", cls=LGPerson) at objc-runtime-new.mm:6232:21 [opt]
    frame #2: 0x0000000100307f9a libobjc.A.dylib`resolveMethod_locked(inst=<unavailable>, sel="say1", cls=LGPerson, behavior=1) at objc-runtime-new.mm:0 [opt]
    frame #3: 0x00000001002edfdb libobjc.A.dylib`_objc_msgSend_uncached at objc-msg-x86_64.s:1153
    frame #4: 0x0000000100003d9a KCObjcBuild`main(argc=<unavailable>, argv=<unavailable>) at main.m:28:9 [opt]
    frame #5: 0x00007fff20388f5d libdyld.dylib`start + 1
    frame #6: 0x00007fff20388f5d libdyld.dylib`start + 1
(lldb)

这个堆栈就比较熟悉了，是从resolveInstanceMethod直接过来的

再看下一次进入的断点，输出调用堆栈：

2021-07-02 00:55:26.554399+0800 KCObjcBuild[25860:1813837] +[LGPerson resolveInstanceMethod:]
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = instruction step over
  * frame #0: 0x0000000100003de6 KCObjcBuild`+[LGPerson resolveInstanceMethod:] + 38
    frame #1: 0x0000000100311356 libobjc.A.dylib`resolveInstanceMethod(inst=0x0000000000000000, sel="say1", cls=LGPerson) at objc-runtime-new.mm:6232:21 [opt]
    frame #2: 0x0000000100307f9a libobjc.A.dylib`resolveMethod_locked(inst=<unavailable>, sel="say1", cls=LGPerson, behavior=0) at objc-runtime-new.mm:0 [opt]
    frame #3: 0x00000001003073f6 libobjc.A.dylib`lookUpImpOrForward(inst=<unavailable>, sel=<unavailable>, cls=<unavailable>, behavior=<unavailable>) at objc-runtime-new.mm:6503:16 [opt] [artificial]
    frame #4: 0x00000001002ecae7 libobjc.A.dylib`class_getInstanceMethod(cls=LGPerson, sel="say1") at objc-runtime-new.mm:6153:5 [opt]
    frame #5: 0x00007fff2045e653 CoreFoundation`__methodDescriptionForSelector + 276
    frame #6: 0x00007fff20477fa0 CoreFoundation`-[NSObject(NSObject) methodSignatureForSelector:] + 30
    frame #7: 0x00007fff204484ef CoreFoundation`___forwarding___ + 396
    frame #8: 0x00007fff204482d8 CoreFoundation`_CF_forwarding_prep_0 + 120
    frame #9: 0x0000000100003d9a KCObjcBuild`main(argc=<unavailable>, argv=<unavailable>) at main.m:28:9 [opt]
    frame #10: 0x00007fff20388f5d libdyld.dylib`start + 1
    frame #11: 0x00007fff20388f5d libdyld.dylib`start + 1
(lldb)

这个就很奇怪了，居然是从CoreFoundation的_CF_forwarding_prep_0发起

=>_CF_forwarding_prep_0
=> ___forwarding___
=> -[NSObject(NSObject) methodSignatureForSelector:]
=> __methodDescriptionForSelector
=> class_getInstanceMethod
=> lookUpImpOrForward
=> resolveMethod_locked
=> resolveInstanceMethod
=> +[LGPerson resolveInstanceMethod:]

从调用堆栈看出，又走了一次消息慢速查找流程，并转发到resolveInstanceMethod:处理，这个转发机制又是从哪里触发的呢，我们之后的文章会揭晓

实现+resolveInstanceMethod:方法

+ (BOOL)resolveInstanceMethod:(SEL)sel {
    
    NSLog(@"%s", __func__);
    
    if (sel == @selector(say1)) {
        
        IMP sayNBImp        = class_getMethodImplementation(self, @selector(sayNB));
        Method method       = class_getInstanceMethod(self, @selector(sayNB));
        const char *type    = method_getTypeEncoding(method);
        
        return class_addMethod(self, sel, sayNBImp, type);
    }
    
    return [super resolveInstanceMethod:sel];
    
}

动态的往方法列表里添加一个条目，把say1的sel和另一个方法sayNB的实现绑定，调用say1的时候，就会重定向到sayNB

输出结果：

2021-07-02 01:21:08.934984+0800 KCObjcBuild[40079:1883135] +[LGPerson resolveInstanceMethod:]
2021-07-02 01:21:08.935505+0800 KCObjcBuild[40079:1883135] -[LGPerson sayNB]
2021-07-02 01:21:08.935576+0800 KCObjcBuild[40079:1883135] Hello, World!
Program ended with exit code: 0

程序正常结束，没有报方法未实现的错误

resolveInstanceMethod:这样的转发机制，就是著名的AOP，面向切面编程，是runtime对AOP编程的支持

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
平台声明：文章内容（如有图片或视频亦包括在内）由作者上传并发布，文章内容仅代表作者本人观点，简书系信息发布平台，仅提供信息存储服务。

推荐阅读更多精彩内容