iOS - 探索动态方法决议和消息转发

面试的时候，面试官经常会问？如果调用的方法找不到时，在奔溃之前系统会给我们三次机会去挽救，避免APP直接崩溃。这三次机会分别是什么？他们的顺序和流程是怎样的？今天我们就来分析一下这三次机会。

一、背景

上一篇文章中，我们分析了objc_msgSend的慢速查找流程，知道了在lookUpImpOrForward中，如果没有找到imp时，会执行一次动态方法决议，即：

    //没有找到方法实现，尝试一次方法解析

    if (slowpath(behavior & LOOKUP_RESOLVER)) {
        //动态方法决议的控制条件，表示流程只走一次
        behavior ^= LOOKUP_RESOLVER; 
        return resolveMethod_locked(inst, sel, cls, behavior);
    }

在Objc中查看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 (!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);
}

主要流程如下：

• 1、判断是否是元类：
  如果是类，执行实例方法的动态方法决议resolveInstanceMethod
  如果是元类，执行类方法的动态方法决议resolveClassMethod，如果在元类中没有找到或者为空，则在元类的实例方法的动态方法决议resolveInstanceMethod中查找，主要是因为类方法在元类中是实例方法，所以还需要查找元类中实例方法的动态方法决议
• 2、如果动态方法决议中，将其实现指向了其他方法，则继续查找指定的imp，即继续慢速查找lookUpImpOrForward流程

二、resolveInstanceMethod和resolveClassMethod

1、resolveInstanceMethod

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

static void resolveInstanceMethod(id inst, SEL sel, Class cls)
{
    runtimeLock.assertUnlocked();
    ASSERT(cls->isRealized());
    SEL resolve_sel = @selector(resolveInstanceMethod:);
    
    // look的是 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); //发送resolve_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));
        }
    }
}

主要流程如下：

• 1、在发送resolveInstanceMethod消息前，需要查找cls类中是否有该方法的实现，即通过lookUpImpOrNil方法又会进入lookUpImpOrForward慢速查找流程查找resolveInstanceMethod方法
  如果没有，则直接返回；如果有，则发送resolveInstanceMethod消息
• 2、再次慢速查找实例方法的实现，即通过lookUpImpOrNil方法又会进入lookUpImpOrForward慢速查找流程查找实例方法

2、resolveClassMethod

类方法，与实例方法类似，同样可以通过重写resolveClassMethod类方法来解决前文的崩溃问题。resolveClassMethod的源码如下：

static void _class_resolveClassMethod(id inst, SEL sel, Class cls)
{
    ASSERT(cls->isMetaClass());
    SEL resolve_sel = @selector(resolveClassMethod:);

    if (!lookUpImpOrNil(inst, resolve_sel, cls)) {
        // Resolver not implemented.
        return;
    }

    BOOL (*msg)(Class, SEL, SEL) = (typeof(msg))objc_msgSend;
    bool resolved = msg(_class_getNonMetaClass(cls, inst), resolve_sel, sel);

    // Cache the result (good or bad) so the resolver doesn't fire next time.
    // +resolveClassMethod adds to self->ISA() 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 resolveClassMethod:%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相比较，从判断类变成了判断元类，也即是查找的继承链不同，其他的都没有什么差别。

接下来我们通过一个案例，来验证下resolveInstanceMethod和resolveClassMethod在实际开发中如果运用和有没有其它的问题。

首先新建工程，新建一个LPPerson类，分别定义一个实例方法和类方法，并在main中调用，具体代码如下：

@interface LPPerson : NSObject
- (void)sayHello;
+ (void)sayHi;

@end
@implementation LPPerson

@end

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        // insert code here...
        
        LPPerson *person = [LPPerson alloc];
        [person sayHello];
        //[LPPerson sayHi];

    }
    return 0;
}

运行工程，查看结果：

image.png

直接崩溃，并报出unrecognized selector sent to instance的错误。
接下来我们就尝试使用动态方法决议来阻止它报错和崩溃，因为sayHello是实例方法，所以我们在LPPerson.m文件中实现resolveInstanceMethod，并重新指向另一个方法replaceInstance。

@implementation LPPerson
- (void)replaceInstance{
    NSLog(@"%s",__func__);
}
+ (BOOL)resolveInstanceMethod:(SEL)sel{
       if (sel == @selector(sayHello)) {
           NSLog(@"%@ 来了",NSStringFromSelector(sel));
           IMP imp           = class_getMethodImplementation(self, @selector(replaceInstance));
           Method sayMMethod = class_getInstanceMethod(self, @selector(replaceInstance));
           const char *type  = method_getTypeEncoding(sayMMethod);
           return class_addMethod(self, sel, imp, type);
       }
    return  [super resolveInstanceMethod:sel];
}

@end

再次运行：

image.png

不崩溃了，并且走到了我们让它去的地方replaceInstance中。
接下来我们打开sayHi的注释，再次运行发现还是会崩溃。

image.png

类似的，因为sayHi是类方法，所以我们需要重写resolveClassMethod来解决崩溃的问题：

+ (void)replaceClass{
    NSLog(@"%s",__func__);
}
+ (BOOL)resolveClassMethod:(SEL)sel{
    if (sel == @selector(sayHi)) {
        NSLog(@"%@ 来了",NSStringFromSelector(sel));
        IMP imp           = class_getMethodImplementation(objc_getMetaClass("LPPerson"), @selector(replaceClass));
        Method sayMMethod = class_getInstanceMethod(objc_getMetaClass("LPPerson"), @selector(replaceClass));
        const char *type  = method_getTypeEncoding(sayMMethod);
        return class_addMethod(objc_getMetaClass("LPPerson"), sel, imp, type);
    }
 return  [super resolveInstanceMethod:sel];
}

注意：resolveClassMethod是针对类方法的动态决议，传入的cls不再是类，而是元类，可以通过objc_getMetaClass方法获取类的元类。其原理是因为类方法在元类中也是实例方法。

再次运行，发现也不崩溃了。

image.png

实际开发中，我们不可能说每个类都去实现resolveInstanceMethod和resolveClassMethod方式，来避免，有没有办法可以优化呢？这个时候你想到了什么？类别对吗？OC中NSObject是所有类的根类，我们直接创建一个NSObject的分类来实现方法动态决议不就可以了吗？我们来验证下：

+ (BOOL)resolveInstanceMethod:(SEL)sel{
    NSLog(@"%@ 来了",NSStringFromSelector(sel));
    if (sel == @selector(sayHello)) {
        NSLog(@"%@ 来了",NSStringFromSelector(sel));

        IMP imp           = class_getMethodImplementation(self, @selector(replaceInstance));
        Method sayMMethod = class_getInstanceMethod(self, @selector(replaceInstance));
        const char *type  = method_getTypeEncoding(sayMMethod);
        return class_addMethod(self, sel, imp, type);
    }
    else if (sel == @selector(sayHi)) {

        IMP imp           = class_getMethodImplementation(objc_getMetaClass("LPPerson"), @selector(replaceClass));
        Method sayMMethod = class_getInstanceMethod(objc_getMetaClass("LPPerson"), @selector(replaceClass));
        const char *type  = method_getTypeEncoding(sayMMethod);
        return class_addMethod(objc_getMetaClass("LPPerson"), sel, imp, type);
    }
    return NO;
}

运行：

image.png
没毛病，可以解决。
这里注意，我们只是实现了resolveInstanceMethod，在resolveInstanceMethod处理类方法也是可以的，这就可以验证我们阐述为什么调用了类方法动态方法决议，还要调用对象方法动态方法决议，其根本原因还是类方法在元类中的实例方法。

但是这样就真的好吗？如果你有1000个方法要处理，不是要写1000个判断？而且系统的方法可能也会被修改。当然针对这一点，也是可以优化的，即我们可以针对自定义类中方法统一方法名的前缀，根据前缀来判断是否是自定义方法，然后统一处理自定义方法，例如可以在崩溃前pop到首页，主要是用于app线上防崩溃的处理，提升用户的体验。
但是这样还是不够好，接下来我们就来讲一下更好的方式：消息转发

三、消息转发

在慢速查找的流程中，我们了解到，如果快速+慢速没有找到方法实现，动态方法决议也不行，就使用消息转发，但是，我们找遍了源码也没有发现消息转发的相关源码，可以通过instrumentObjcMessageSends方式来了解，方法调用崩溃前都走了哪些方法：

1、instrumentObjcMessageSends

我们在lookUpImpOrForward源码中发现：

....
    for (unsigned attempts = unreasonableClassCount();;) {
        // curClass method list.
        Method meth = getMethodNoSuper_nolock(curClass, sel);
        if (meth) {
            imp = meth->imp;
            goto done;
        }
...
 done:
    log_and_fill_cache(cls, imp, sel, inst, curClass);
    runtimeLock.unlock();
...

如果有找到imp，就会goto到done，done中会执行log_and_fill_cache方法是答应并存放到cache中，查看log_and_fill_cache源码：

static void
log_and_fill_cache(Class cls, IMP imp, SEL sel, id receiver, Class implementer)
{
#if SUPPORT_MESSAGE_LOGGING
    if (slowpath(objcMsgLogEnabled && implementer)) {
        bool cacheIt = logMessageSend(implementer->isMetaClass(), 
                                      cls->nameForLogging(),
                                      implementer->nameForLogging(), 
                                      sel);
        if (!cacheIt) return;
    }
#endif
    cache_fill(cls, sel, imp, receiver);
}

这里发现objcMsgLogEnabled必须有yes才可以打印，我们再点击进入logMessageSend中，

bool logMessageSend(bool isClassMethod,
                    const char *objectsClass,
                    const char *implementingClass,
                    SEL selector)
{
    char    buf[ 1024 ];

    // Create/open the log file
    if (objcMsgLogFD == (-1))
    {
        snprintf (buf, sizeof(buf), "/tmp/msgSends-%d", (int) getpid ());
        objcMsgLogFD = secure_open (buf, O_WRONLY | O_CREAT, geteuid());
        if (objcMsgLogFD < 0) {
            // no log file - disable logging
            objcMsgLogEnabled = false;
            objcMsgLogFD = -1;
            return true;
        }
    }

    // Make the log entry
    snprintf(buf, sizeof(buf), "%c %s %s %s\n",
            isClassMethod ? '+' : '-',
            objectsClass,
            implementingClass,
            sel_getName(selector));

    objcMsgLogLock.lock();
    write (objcMsgLogFD, buf, strlen(buf));
    objcMsgLogLock.unlock();

    // Tell caller to not cache the method
    return false;
}

搜索objcMsgLogEnabled，发现是在instrumentObjcMessageSends对objcMsgLogEnabled的状态进行控制。我们只要在instrumentObjcMessageSends将objcMsgLogEnabled置为yes即可。打印的日志文件存放在/tmp/msgSends/中。因为instrumentObjcMessageSends是在源码中，我们要在外部调用，就需要使用extern关键字。

新建mac工程，创建LPPerson，在main中修改代码：

extern void instrumentObjcMessageSends(BOOL flag);
int main(int argc, const char * argv[]) {
    @autoreleasepool {
        // insert code here...
        
        LPPerson *person = [LPPerson alloc];
        instrumentObjcMessageSends(YES);
        [person sayHello];
        instrumentObjcMessageSends(NO);

    }
    return 0;
}

需要注意的是不能在源码工程中使用instrumentObjcMessageSends，在源码中使用不会将方法调用流程写进文件中

然后先运行，然后进入/tmp/msgSends/文件中，可以发现，多了一个msgSends开头的文件：

image.png
我们双击打开：
image.png
这里我们发现，在执行了resolveInstanceMethod还执行了forwardingTargetForSelector和methodSignatureForSelector，也就是我们常说的消息转发，消息转发也分为快速转发和慢速转发，接下来我们就具体分析下：

2、快速转发流程：forwardingTargetForSelector

苹果官方对其的定义是该方法为一个实例方法、且需要返回一个处理方法的对象。
通过上面日志文件，我们知道forwardingTargetForSelector的消息接受者是LPPerson，所以我们可以在LPPerson实现forwardingTargetForSelector方法：

- (id)forwardingTargetForSelector:(SEL)aSelector{
    NSLog(@"%s - %@",__func__,NSStringFromSelector(aSelector));
    return [super forwardingTargetForSelector:aSelector];
}

再次运行，我们发现是在崩溃之前走了这里的并打印了sayHello。

2020-10-11 15:41:27.250032+0800 002-instrumentObjcMessageSends[36923:1077690] -[LPPerson forwardingTargetForSelector:] - sayHello

所以我们可以按照官方的定义，指定一个新的接收者去处理。新建LPStudent并实现sayHello方法

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

然后在forwardingTargetForSelector中修改新的处理者为LPStudent，

- (id)forwardingTargetForSelector:(SEL)aSelector{
    NSLog(@"%s - %@",__func__,NSStringFromSelector(aSelector));
    return [LPStudent alloc];
}

再次运行：

2020-10-11 15:45:35.698400+0800 002-instrumentObjcMessageSends[36978:1080659] -[LPPerson forwardingTargetForSelector:] - sayHello
2020-10-11 15:45:35.699273+0800 002-instrumentObjcMessageSends[36978:1080659] -[LPStudent sayHello]
2020-10-11 15:45:35.699617+0800 002-instrumentObjcMessageSends[36978:1080659] Hello, World!

可以看到，完美处理，让LPStudent成功接盘。同理，在实际开发中，我们也可以在这个地方处理崩溃问题，只需要新建一个消息接受者，然后利用RunTime动态的添加imp即可完成。

3、慢速转发：methodSignatureForSelector

苹果官方的定义是：该方法为一个实例方法、且必须调用forwardInvocation:方法并返回NSInvocation对象。所以通常都是methodSignatureForSelector + forwardInvocation一起使用的。同样的，我们在LPPerson中实现methodSignatureForSelector和forwardInvocation并且注释掉forwardingTargetForSelector方法。

- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector {
    NSLog(@"%s -- %@",__func__,NSStringFromSelector(aSelector));
    return [NSMethodSignature signatureWithObjCTypes:"v@:"];
}

// 不处理方法的实现
- (void)forwardInvocation:(NSInvocation *)anInvocation {
    NSLog(@"%s -- %@",__func__, anInvocation);
    NSLog(@"%@ -- %s",anInvocation.target, anInvocation.selector);
}

运行工程，可以看到也没有崩溃。

2020-10-11 15:50:38.223973+0800 002-instrumentObjcMessageSends[37007:1082598] -[LPPerson methodSignatureForSelector:] -- sayHello
2020-10-11 15:50:38.224995+0800 002-instrumentObjcMessageSends[37007:1082598] -[LPPerson forwardInvocation:] -- <NSInvocation: 0x10044fbe0>
2020-10-11 15:50:38.225294+0800 002-instrumentObjcMessageSends[37007:1082598] <LPPerson: 0x100513e20> -- sayHello
2020-10-11 15:50:38.225630+0800 002-instrumentObjcMessageSends[37007:1082598] Hello, World!

接下来，我们在forwardInvocation中来处理实现问题：

- (void)forwardInvocation:(NSInvocation *)anInvocation {
    NSLog(@"%s -- %@",__func__, anInvocation);
    NSLog(@"%@ -- %s",anInvocation.target, anInvocation.selector);
    
    anInvocation.target = [LPStudent alloc];//LPStudent中实现了sayHello方法
    [anInvocation invoke];
    
}

在运行发现已经成功调用LPStudent中方法实现了。

2020-10-11 15:55:27.645633+0800 002-instrumentObjcMessageSends[37139:1085566] -[LPPerson methodSignatureForSelector:] -- sayHello
2020-10-11 15:55:27.647003+0800 002-instrumentObjcMessageSends[37139:1085566] -[LPPerson forwardInvocation:] -- <NSInvocation: 0x100505840>
2020-10-11 15:55:27.647476+0800 002-instrumentObjcMessageSends[37139:1085566] <LPPerson: 0x101808a30> -- sayHello
2020-10-11 15:55:27.647878+0800 002-instrumentObjcMessageSends[37139:1085566] -[LPStudent sayHello]
2020-10-11 15:55:27.648289+0800 002-instrumentObjcMessageSends[37139:1085566] Hello, World!

由此可见实现了methodSignatureForSelector:和forwardInvocation:这两个实例方法后也能解决方法无实现的问题，而且这个两个方法必须同时实现。

快速转发和慢速转发的区别：

• 快速转发：forwardingTargetForSelector可以修改方法的处理的target
• 慢速转发：methodSignatureForSelector不仅可以修改方法的处理的target，可以修改selector

Q:resolveInstanceMethod为什么为执行两次？

来到我们resolveInstanceMethod的源码中，我们在IMP imp = lookUpImpOrNil(inst, sel, cls);行代码添加上断点

image.png

在执行完sayHello的打印后，我们再观察现在的堆栈信息：

image.png

发现这次是因为慢速查找没有找到对应的imp，所以进行了动态方法决议。然后我们再继续执行直到第二次打印，再打印当前堆栈信息：

image.png

可以看到这次，是在慢速消息转发之后再次进行的动态方法决议。

消息转发流程图：

image.png

总结：
objc_msgSend发送消息的流程就分析完成了，在这里简单总结下

-【快速查找流程】首先，在类的缓存cache中查找指定方法的实现

-【慢速查找流程】如果缓存中没有找到，则在类的方法列表中查找，如果还是没找到，则去父类链的缓存和方法列表中查找

-【动态方法决议】如果慢速查找还是没有找到时，第一次补救机会就是尝试一次动态方法决议，即重写resolveInstanceMethod/resolveClassMethod方法

-【消息转发】如果动态方法决议还是没有找到，则进行消息转发，消息转发中有两次补救机会：快速转发+慢速转发

• 如果转发之后也没有，则程序直接报错崩溃unrecognized selector sent to instance

所以篇前所说的三次机会即：

• 动态方法决议：resolveInstanceMethod/resolveClassMethod
• 快速消息转发：forwardingTargetForSelector
• 慢速消息转发：methodSignatureForSelector + forwardInvocation

觉得不错记得点赞哦！听说看完点赞的人逢考必过，逢奖必中。ღ( ´･ᴗ･` )比心