消息轉(zhuǎn)發(fā)流程分析

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

首先，調(diào)用objc_msgSend，從cache中快速查找，命中就執(zhí)行對應(yīng)的imp

其次，如果cache中沒有找到，就調(diào)用lookUpImpOrForward進行慢速查找，找到就插入cache，便于下次執(zhí)行時能快速的查找調(diào)用，并執(zhí)行對應(yīng)的imp

最后，如果還是沒有找到，那么就進入了消息轉(zhuǎn)發(fā)流程，下面我們就來分析一下消息轉(zhuǎn)發(fā)流程

消息轉(zhuǎn)發(fā)的入口在lookUpImpOrForward里

    // No implementation found. Try method resolver once.

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

如果沒有找到，只做一次轉(zhuǎn)發(fā)

再來看看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轉(zhuǎn)發(fā)給+resolveInstanceMethod:方法處理

如果是元類，那么首先嘗試把sel轉(zhuǎn)發(fā)給+ resolveClassMethod:方法處理，如果沒有處理，那么再嘗試轉(zhuǎn)發(fā)給+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:方法有沒有處理，都調(diào)用lookUpImpOrNilTryCache查找一下，并把結(jié)果寫到cache里，方便下次查找

最后，再調(diào)用lookUpImpOrForwardTryCache查找結(jié)果，因為前面剛剛把結(jié)果存到了cache里，所以這里是從cache里快速的得到處理結(jié)果，并返回

//  這個函數(shù)只是快速的從cache里得到結(jié)果，并返回
return lookUpImpOrForwardTryCache(inst, sel, cls, behavior);

我們下面來看看+ resolveInstanceMethod:處理函數(shù)

這個函數(shù)要我們自己重寫，把沒有實現(xiàn)的方法，重定向到另一個方法
我們先實現(xiàn)一個空方法，運行看看

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

調(diào)用一個未實現(xiàn)重定向的空方法，輸出結(jié)果：

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

在報錯之前，這個函數(shù)被調(diào)用了兩次，為什么會被調(diào)用兩次呢？我們明明只調(diào)用了一次，我們設(shè)個符號斷點來看看，到底再哪里還被調(diào)來一次。注意：直接在代碼行號左側(cè)點一下設(shè)置的斷點斷不住，要下符號斷點，看看第一次輸出調(diào)用堆棧：

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直接過來的

再看下一次進入的斷點，輸出調(diào)用堆棧：

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發(fā)起

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

從調(diào)用堆?？闯?，又走了一次消息慢速查找流程，并轉(zhuǎn)發(fā)到resolveInstanceMethod:處理，這個轉(zhuǎn)發(fā)機制又是從哪里觸發(fā)的呢，我們之后的文章會揭曉

實現(xiàn)+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];
    
}

動態(tài)的往方法列表里添加一個條目，把say1的sel和另一個方法sayNB的實現(xiàn)綁定，調(diào)用say1的時候，就會重定向到sayNB

輸出結(jié)果：

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

程序正常結(jié)束，沒有報方法未實現(xiàn)的錯誤

resolveInstanceMethod:這樣的轉(zhuǎn)發(fā)機制，就是著名的AOP，面向切面編程，是runtime對AOP編程的支持

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容