Runtime原理探究（四）—— 刨根问底消息机制

Runtime系列文章

　上一篇里面，咱们从Class的cache_t做为切入点，完善了咱们对于OC类对象的认识，并且还详细了解了Runtime的消息发送流程和方法缓存策略，不过对于消息机制这个话题只是热身而已。接下来，本文就从源头开始，完整地来研究Runtime的消息机制。架构

消息机制流程框架

[obj message] ➡️ 消息发送 ➡️ 动态方法解析 ➡️ 消息转发app

（一）消息发送

消息发送流程上一篇文章已经分析过，这里再从[obj message]为出发点，从objc源码里进行一次正向梳理。框架

首先，要查看[obj message]的底层表示，能够经过xcode调试工具调出其汇编代码进行分析，可是这个方法须要你至少有熟练的汇编代码阅读能力，有很多难度。若是把要求下降一点，能够在命令行工具里面经过iphone

xcrun -sdk iphoneos clang -arch arm64 -rewrite-objc xxx.m -o yyy.cpp
复制代码

生成一个中间代码，这个中间代码基本上都是C或C++代码，阅读起来相对容易。可是须要说明一下，这个中间代码仅做为参考，由于目前xcode编译器已经不使用用这种格式的中间代码的，取而代之的是另外一种语法格式的中间代码，可是虽然语法不一样，可是实现思路和逻辑大体是相同的，所以老的中间代码仍是可以借来参考一下的。

经过上面的命令行操做，[obj message]编译以后的底层表示是

((void (*)(id, SEL))(void *)objc_msgSend)((id)obj, sel_registerName("message"));
复制代码

去掉类型转换后，简化一下能够表示成

objc_msgSend(obj, sel_registerName("message"));
复制代码

其中第一个参数obj就是消息接受者，后面的sel_registerName，能够在objc源码中搜到它的函数声明

SEL _Nonnull sel_registerName(const char * _Nonnull str) 复制代码

很明显这里是根据一个C字符串返回一个SEL，其实就等同于OC里面的@selector()。这两个参数都没什么太大疑问，而后咱们来从源码里看一看可否找到objc_msgSend的实现。但最终，你没法在源码里面找到对应的C函数实现，由于在objc源码里面，是经过汇编来实现的，而且对应不一样架构有不一样的版本，这里咱们就关注arm64版本的实现。其实objc源码总共也没多少文件，如上图所示，除了msg，还有涉及到block相关的一些内容也是用汇编实现的，还有一个objc-sel-table.s，受限本人知识储备，暂时还解读不了，不过不要紧，它跟咱们如今讨论的话题不相关。

你或许会疑惑，苹果为何要用汇编来实现某些函数呢？主要缘由是由于对于一些调用频率过高的函数或操做，使用汇编来实现可以提升效率。在汇编源码里面，能够按照下面的方法来定位函数实现接下来咱们开始阅读汇编而后查找一下CacheLookup，看看缓存怎么查询的，注意，这里的NORMAL是参数。

若是是命中缓存，找到了方法，那就简单了，直接返回并调用就行了，若是没找，就会进入上图中的__objc_msgSend_uncached __objc_msgSend_uncached中调用了MethodTableLookup 咱们发如今MethodTableLookup里面，调用了__class_lookupMethodAndLoadCache3函数，而这个函数在当前的汇编代码里面是找不到实现的。你去objc源码进行全局搜索，也搜不到，这里通过大佬指点，若是是一个C函数，在底层汇编里面若是须要调用的话，苹果会为其加一个下划线_，所以上面的的函数删去一个下划线，_class_lookupMethodAndLoadCache3，你就能够在源码里面找到它对应的C函数，它是objc-runtime-new.mm里面的一个C函数

IMP _class_lookupMethodAndLoadCache3(id obj, SEL sel, Class cls)
{
    return lookUpImpOrForward(cls, sel, obj, 
                              YES/*initialize*/, NO/*cache*/, YES/*resolver*/);
}
复制代码

而这个函数里面最终是调用了lookUpImpOrForward函数，从这个函数开始的后面的流程，我在上一篇文章里面已经作过完整解读了，这里再也不作详细论述，只将以前的结论贴出来

(1) 当一个对象接收到消息时[obj message];，首先根据obj的isa指针进入它的类对象cls里面。

(2) 在obj的cls里面，首先到缓存cache_t里面查询方法message的函数实现，若是找到，就直接调用该函数。

(3) 若是上一步没有找到对应函数，在对该cls的方法列表进行二分/遍历查找，若是找到了对应函数，首先会将该方法缓存到obj的类对象cls的cache_t里面，而后对函数进行调用。

(4) 在每次进行缓存操做以前，首先须要检查缓存容量，若是缓存内的方法数量超过规定的临界值(设定容量的3/4)，须要先对缓存进行2倍扩容，原先缓存过的方法所有丢弃，而后将当前方法存入扩容后的新缓存内。

(5) 若是在obj的cls对象里面，发现缓存和方法列表都找不到mssage方法，则经过cls的superclass指针进入它的父类对象f_cls里面

(6) 进入f_cls后，首先在它的cache_t里面查找mssage，若是找到了该方法，那么会首先将方法缓存到消息接受者obj的类对象cls的cache_t里面，而后调用方法对应的函数。

(7) 若是上一步没有找到方法，将会对f_cls的方法列表进行遍历二分/遍历查找，若是找到了mssage方法，那么一样，会首先将方法缓存到消息接受者obj的类对象cls的cache_t里面，而后调用方法对应的函数。须要注意的是，这里并不会将方法缓存到当前父类对象f_cls的cache_t里面。

(8) 若是还没找到方法，则会经过f_cls的superclass进入更上层的父类对象里面，按照(6)->(7)->(8)步骤流程重复。若是此时已经到了基类对象NSObject，仍没有找到mssage，则进入步骤(9)

(9) 接下来将会转到消息机制的 动态方法解析 阶段

到此，消息发送机制的正向解读就到这里。关于上面的汇编代码，我本身也只是借助相关注释说明，间接挖掘苹果的底层思路，其实汇编里面还有更多的细节，只有你本身亲自读一遍，才会有更跟深的体会和领悟。

（二）动态方法解析

接下来，一块儿来认识一下方法的动态解析。上面的章节，咱们讲到了lookUpImpOrForward函数，这个函数我在以前的文章也具体讨论过了，可是仅仅是解读完了消息发送和方法缓存的内容，这里我先贴出该函数的代码

/*********************************************************************** * lookUpImpOrForward. * The standard IMP lookup. ------------->⚠️⚠️⚠️标准的IMP查找流程 * initialize==NO tries to avoid +initialize (but sometimes fails) * cache==NO skips optimistic unlocked lookup (but uses cache elsewhere) * Most callers should use initialize==YES and cache==YES. * inst is an instance of cls or a subclass thereof, or nil if none is known. * If cls is an un-initialized metaclass then a non-nil inst is faster. * May return _objc_msgForward_impcache. IMPs destined for external use * must be converted to _objc_msgForward or _objc_msgForward_stret. * If you don't want forwarding at all, use lookUpImpOrNil() instead. **********************************************************************/
IMP lookUpImpOrForward(Class cls, SEL sel, id inst, bool initialize, bool cache, bool resolver) {
    IMP imp = nil;
    bool triedResolver = NO;

    runtimeLock.assertUnlocked();

    // Optimistic cache lookup
    if (cache) {//------------------>⚠️⚠️⚠️查询当前Class对象的缓存，若是找到方法，就返回该方法
        imp = cache_getImp(cls, sel);
        if (imp) return imp;
    }

    // runtimeLock is held during isRealized and isInitialized checking
    // to prevent races against concurrent realization.

    // runtimeLock is held during method search to make
    // method-lookup + cache-fill atomic with respect to method addition.
    // Otherwise, a category could be added but ignored indefinitely because
    // the cache was re-filled with the old value after the cache flush on
    // behalf of the category.

    runtimeLock.read();

    if (!cls->isRealized()) {//--------------->⚠️⚠️⚠️当前Class若是没有被realized，就进行realize操做
        // Drop the read-lock and acquire the write-lock.
        // realizeClass() checks isRealized() again to prevent
        // a race while the lock is down.
        runtimeLock.unlockRead();
        runtimeLock.write();

        realizeClass(cls);

        runtimeLock.unlockWrite();
        runtimeLock.read();
    }

    if (initialize  &&  !cls->isInitialized()) {//--------->⚠️⚠️⚠️当前Class若是没有初始化，就进行初始化操做
        runtimeLock.unlockRead();
        _class_initialize (_class_getNonMetaClass(cls, inst));
        runtimeLock.read();
        // If sel == initialize, _class_initialize will send +initialize and 
        // then the messenger will send +initialize again after this 
        // procedure finishes. Of course, if this is not being called 
        // from the messenger then it won't happen. 2778172
    }

    
 retry:    
    runtimeLock.assertReading();

    // Try this class's cache.//------------>⚠️⚠️⚠️尝试从该Class对象的缓存中查找，若是找到，就跳到done处返回该方法

    imp = cache_getImp(cls, sel);
    if (imp) goto done;

    // Try this class's method lists.//---------------->⚠️⚠️⚠️尝试从该Class对象的方法列表中查找，找到的话，就缓存到该Class的cache_t里面，并跳到done处返回该方法
    {
        Method meth = getMethodNoSuper_nolock(cls, sel);
        if (meth) {
            log_and_fill_cache(cls, meth->imp, sel, inst, cls);
            imp = meth->imp;
            goto done;
        }
    }

    // Try superclass caches and method lists.------>⚠️⚠️⚠️进入当前Class对象的superclass对象
    {
        unsigned attempts = unreasonableClassCount();
        for (Class curClass = cls->superclass;//------>⚠️⚠️⚠️该for循环每循环一次，就会进入上一层的superclass对象，进行循环内部方法查询流程
             curClass != nil;
             curClass = curClass->superclass)
        {
            // Halt if there is a cycle in the superclass chain.
            if (--attempts == 0) {
                _objc_fatal("Memory corruption in class list.");
            }
            
            // Superclass cache.------>⚠️⚠️⚠️在当前superclass对象的缓存进行查找
            imp = cache_getImp(curClass, sel);
            if (imp) {
                if (imp != (IMP)_objc_msgForward_impcache) {
                    // Found the method in a superclass. Cache it in this class.
                    log_and_fill_cache(cls, imp, sel, inst, curClass);
                    goto done;//------>⚠️⚠️⚠️若是在当前superclass的缓存里找到了方法，就调用log_and_fill_cache进行方法缓存，注意这里传入的参数是cls，也就是将方法缓存到消息接受对象所对应的Class对象的cache_t中，而后跳到done处返回该方法
                }
                else {
                    // Found a forward:: entry in a superclass.
                    // Stop searching, but don't cache yet; call method 
                    // resolver for this class first.
                    break;//---->⚠️⚠️⚠️若是缓存里找到的方法是_objc_msgForward_impcache，就跳出该轮循环，进入上一层的superclass，再次进行查找
                }
            }
            // Superclass method list.---->⚠️⚠️⚠️如过画缓存里面没有找到方法，则对当前superclass的方法列表进行查找
            Method meth = getMethodNoSuper_nolock(curClass, sel);
            if (meth) {
            //------>⚠️⚠️⚠️若是在当前superclass的方法列表里找到了方法，就调用log_and_fill_cache进行方法缓存，注意这里传入的参数是cls，也就是将方法缓存到消息接受对象所对应的Class对象的cache_t中，而后跳到done处返回该方法
                log_and_fill_cache(cls, meth->imp, sel, inst, curClass);
                imp = meth->imp;
                goto done;
            }
        }
    }
//**********************✅✅✅消息发送流程结束✅✅✅*************************


//📦📦📦动态方法解析
    // No implementation found. Try method resolver once.//------>⚠️⚠️⚠️若是到基类尚未找到方法，就尝试进行方法解析

    if (resolver  &&  !triedResolver) {
        runtimeLock.unlockRead();
        _class_resolveMethod(cls, sel, inst);
        runtimeLock.read();
        // Don't cache the result; we don't hold the lock so it may have 
        // changed already. Re-do the search from scratch instead.
        triedResolver = YES;
        goto retry;
    }



//📦📦📦消息转发
    // No implementation found, and method resolver didn't help. //------>⚠️⚠️⚠️若是方法解析不成功，就进行消息转发
    // Use forwarding.

    imp = (IMP)_objc_msgForward_impcache;
    cache_fill(cls, sel, imp, inst);

 done:
    runtimeLock.unlockRead();

    return imp;
}
复制代码

动态方法解析

根据上面代码里面的📦📦📦动态方法解析标记处，咱们继续解读消息机制的 动态方法解析阶段。首先注意一个细节，这里有一个标签triedResolver用来判断是否进行该类是否进行过动态方法解析。若是首次走到这里，triedResolver = NO，当动态方法解析进行过一次以后，会设置triedResolver = YES，这样下次走到这里的时候，就不会再次进行动态方法解析，由于这个流程只须要进行一次就够了，而且实在首次调用一个该类没有实现的方法的时候，才会进行这个流程，仔细体会一下而最后这个goto retry回到的地方是本函数的以下位置这个就是消息发送和缓存查询流程的开始步骤，啥意思呢？就是说通过动态方法解析流程处理过以后（在这个流程咱们能够动态给类增长方法【新增的方法会存放在消息接受者->ISA() 的rw的方法列表里面去】），会从新走一遍缓存查找和消息发送。

下面再继续看一下方法动态解析里面的核心函数_class_resolveMethod(cls, sel, inst);

***********************************************************************
* _class_resolveMethod
* Call +resolveClassMethod or +resolveInstanceMethod.
* Returns nothing; any result would be potentially out-of-date already.
* Does not check if the method already exists.
**********************************************************************/
void _class_resolveMethod(Class cls, SEL sel, id inst)
{
    if (! cls->isMetaClass()) {
        // try [cls resolveInstanceMethod:sel]
        _class_resolveInstanceMethod(cls, sel, inst);
    } 
    else {
        // try [nonMetaClass resolveClassMethod:sel]
        // and [cls resolveInstanceMethod:sel]
        _class_resolveClassMethod(cls, sel, inst);
        if (!lookUpImpOrNil(cls, sel, inst, 
                            NO/*initialize*/, YES/*cache*/, NO/*resolver*/)) 
        {
            _class_resolveInstanceMethod(cls, sel, inst);
        }
    }
}
复制代码

很明显，if (! cls->isMetaClass()) 这句代码实在判断当前的参数cls是不是一个meta-class对象，也就是说，调用对象方法（-方法）和调用类方法(+方法)过程里面的动态方法解析，走的都是这个方法啊，这里咱们先关注对象方法(-方法)的解析处理逻辑。也就是_class_resolveInstanceMethod(cls, sel, inst);，进入它的函数实现以下

static void _class_resolveInstanceMethod(Class cls, SEL sel, id inst)
{
//---⚠️⚠️⚠️查看cls的meta-class对象的方法列表里面是否有SEL_resolveInstanceMethod函数，
//---⚠️⚠️⚠️也就是看是否实现了+(BOOL)resolveInstanceMethod:(SEL)sel方法
    if (!  lookUpImpOrNil(cls->ISA(), SEL_resolveInstanceMethod, cls, 
                         NO/*initialize*/, YES/*cache*/, NO/*resolver*/)) 
    {

//---⚠️⚠️⚠️若是没找到，直接返回，
        // Resolver not implemented.
        return;
    }

//---⚠️⚠️⚠️若是找到，则经过objc_msgSend调用一下+(BOOL)resolveInstanceMethod:(SEL)sel方法
//---⚠️⚠️⚠️完成里面的动态增长方法的步骤


//---⚠️⚠️⚠️接下来是一些对解析结果的打印信息
    BOOL (*msg)(Class, SEL, SEL) = (typeof(msg))objc_msgSend;
    bool resolved = msg(cls, SEL_resolveInstanceMethod, 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(cls, sel, inst, 
                             NO/*initialize*/, YES/*cache*/, NO/*resolver*/);

    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));
        }
    }
}
复制代码

动态方法解析的核心步骤完成以后，会一层一层往上返回到lookUpImpOrForward函数，跳到retry标记处，从新查询方法，由于在方法解析这一步，若是对某个目标方法名xxx有过处理，为其动态增长了方法实现，那么再次查询该方法，则必定能够在消息发送阶段被找到并调用。对于类方法（+方法）的动态解析其实跟上面的过程大体相同，只不过解析的时候调用的+(BOOL)resolveClassMethod:(SEL)sel方法，来完成类方法的动态添加绑定。

小结

首先用图来总结一下

动态方法解析真的有必要吗？ 其实这个我以为没有固定答案，根据我的的理解因人而异，就我我的的肤浅见解，好像除了在面试里面能够增长一点逼格外，实际项目中好像没太多使用场景，由于与其在动态解析步骤里面动态增长方法，还不如直接在类里面实现该方法呢，不知道你们有什么心得体会，欢迎留言交流。

好了，动态方法解析流程解读完毕。

（三）消息转发

通过前两个流程以后，若是还没能找到方法对应的函数，说明当前类已经尽力了，可是确实没有能力处理目标方法，因子只能把方法抛给别人，也就丢给其余的类去处理，所以最后一个流程为何叫消息转发，顾名思义。下面，咱们来搞定消息转发，入口以下，位于lookUpImpOrForward函数的尾部从截图中能够看出，消息转发这里直接就是返回了一个(IMP)_objc_msgForward_impcache指针。对源码搜索一下，发现它其实也是一段汇编实现

STATIC_ENTRY __objc_msgForward_impcache

	MESSENGER_START
	nop
	MESSENGER_END_SLOW

	// No stret specialization.
	b	__objc_msgForward

	END_ENTRY __objc_msgForward_impcache

//**************************************************************
	
	ENTRY __objc_msgForward

	adrp	x17, __objc_forward_handler@PAGE
	ldr	x17, [x17, __objc_forward_handler@PAGEOFF]
	br	x17
	
	END_ENTRY __objc_msgForward
复制代码

汇编中的调用顺序是这样 _objc_msgForward_impcache->__objc_msgForward->__objc_forward_handler，咱们能够尝试搜索一下objc_forward_handler,最终，咱们能够在objc-runtime.mm里面能够找到与objc_forward_handler相关的信息

__attribute__((noreturn)) 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_forward_handler 实际上是一个函数指针，指向objc_defaultForwardHandler，可是这个函数只有打印信息，再往下深刻，没法看出消息转发更底层的执行逻辑，苹果对此并无开源。若是想要继续挖掘，就只经过汇编码逆向反推C函数的实现，逆向是一个很大的话题，须要不少知识储备，本文没法展开介绍。其实，若是消息机制的前两个流程都没命中，进入消息转发阶段，则会调用 __forwarding__函数。这个能够从xcode的打印信息里面验证，若是调用一个没有实现的方法，而且动态解析和消息转发都没有处理，最终打印结果以下能够看到从底层上来，调用了CF框架的_CF_forwarding_prep_0，而后就调用了___forwarding___。该函数就属于苹果未开源部分，感谢大神MJ老师的分享，如下贴出他为我提供的一份消息转发流程的C函数实现，

int __forwarding__(void *frameStackPointer, int isStret) {
    id receiver = *(id *)frameStackPointer;
    SEL sel = *(SEL *)(frameStackPointer + 8);
    const char *selName = sel_getName(sel);
    Class receiverClass = object_getClass(receiver);

    // 调用 forwardingTargetForSelector:

    if (class_respondsToSelector(receiverClass, @selector(forwardingTargetForSelector:))) {
        id forwardingTarget = [receiver forwardingTargetForSelector:sel];
        if (forwardingTarget && forwardingTarget != receiver) {
            return objc_msgSend(forwardingTarget, sel, ...);
        }
    }

    // 调用 methodSignatureForSelector 获取方法签名后再调用 forwardInvocation
    if (class_respondsToSelector(receiverClass, @selector(methodSignatureForSelector:))) {
        NSMethodSignature *methodSignature = [receiver methodSignatureForSelector:sel];
        if (methodSignature && class_respondsToSelector(receiverClass, @selector(forwardInvocation:))) {
            NSInvocation *invocation = [NSInvocation _invocationWithMethodSignature:methodSignature frame:frameStackPointer];

            [receiver forwardInvocation:invocation];

            void *returnValue = NULL;
            [invocation getReturnValue:&value];
            return returnValue;
        }
    }

    if (class_respondsToSelector(receiverClass,@selector(doesNotRecognizeSelector:))) {
        [receiver doesNotRecognizeSelector:sel];
    }

    // The point of no return.
    kill(getpid(), 9);
}
复制代码

__forwarding__函数逻辑能够简单归纳成 forwardingTargetForSelector:->methodSignatureForSelector->forwardInvocation。我在功过一个流程图来解读一下上面的代码

-(id)forwardingTargetForSelector:(SEL)aSelector—— __forwarding__首先会看类有没有实现这个方法，这个方法返回的是一个id 类型的转发对象forwardingTarget，若是其不为空，则会经过objc_msgSend函数对其直接发送消息objc_msgSend(forwardingTarget, sel, ...);，也就是说让转发对象forwardingTarget去处理当前的方法SEL。若是forwardingTarget为nil，则进入下面的方法

-(NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector——这个方法是让咱们根据方法选择器SEL生成一个NSMethodSignature方法签名并返回，这个方法签名里面其实就是封装了返回值类型，参数类型的信息。

__forwarding__会利用这个方法签名，生成一个NSInvocation，将其做为参数，调用- (void)forwardInvocation:(NSInvocation *)anInvocation方法。若是咱们在这里没有返回方法签名，系统则认为咱们完全不想处理这个方法了，就会调用doesNotRecognizeSelector:方法抛出经典的报错报错unrecognized selector sent to instance 0xXXXXXXXX，结束消息机制的所有流程。

- (void)forwardInvocation:(NSInvocation *)anInvocation ——若是咱们在上面提供了方法签名，__forwarding__则会最终调用这个方法。在这个方法里面，咱们会拿到一个参数(NSInvocation *)anInvocation，这个anInvocation实际上是__forwarding__对以下三个信息的封装：

anInvocation.target -- 方法调用者

anInvocation.selector -- 方法名

- (void)getArgument:(void *)argumentLocation atIndex:(NSInteger)idx; -- 方法参数

所以在此方法里面，咱们能够决定将消息转发给谁（target），甚至还能够修改消息的参数，因为anInvocation会存储消息selector里面带来的参数，而且能够根据消息所对应的方法签名肯定消息参数的个数，因此咱们经过- (void)setArgument:(void *)argumentLocation atIndex:(NSInteger)idx;能够对参数进行修改。总之你能够按照你的意愿，配置好anInvocation，而后简单一句[anInvocation invoke];便可完成消息的转发调用，也能够不作任何处理，轻轻地来，轻轻地走，可是不会致使程序报错。

至此，Runtime的消息机制就所有梳理完毕～～

🦋🦋🦋传送门🦋🦋🦋

Runtime原理探究（一）—— isa的深刻体会（苹果对isa的优化）

Runtime原理探究（二）—— Class结构的深刻分析

Runtime原理探究（三）—— OC Class的方法缓存cache_t

Runtime原理探究（四）—— 刨根问底消息机制

Runtime原理探究（五）—— super的本质

Runtime原理探究（六）—— 面试题中的Runtime