iOS - 消息流程之动态方法决议 & 消息转发

2020-11-06  本文已影响0人  Gumball_a45f

在前面两篇文章iOS- 消息流程之快速查找和iOS- 消息流程之慢速查找中，分别分析了objc_msgSend的快速查找和慢速查找

在这两种都没找到方法实现的情况下，苹果给了两个建议

如果这两个建议都没有做任何操作，就会报我们日常开发中常见的方法未实现的崩溃报错，其步骤如下

方法未实现报错源码

根据慢速查找的源码，我们发现，其报错最后都是走到__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

// 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;

下面，我们来讲讲如何在崩溃前，如何操作，可以防止方法未实现的崩溃。

三次方法查找的挽救机会

根据苹果的两个建议，我们一共有三次挽救的机会：

【第一次机会】动态方法决议

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

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);
}

主要分为以下几步

其流程如下
实例方法

针对实例方法调用，在快速-慢速查找均没有找到实例方法的实现时，我们有一次挽救的机会，即尝试一次动态方法决议，由于是实例方法，所以会走到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
    //查找say666
    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));
        }
    }
}

主要分为以下几个步骤：

崩溃修改

所以，针对实例方法say666未实现的报错崩溃，可以通过在类中重写resolveInstanceMethod类方法，并将其指向其他方法的实现，即在LGPerson中重写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];
}
重新运行，其打印结果如下
类方法

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

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

resolveClassMethod类方法的重写需要注意一点，传入的cls不再是类，而是元类，可以通过objc_getMetaClass方法获取类的元类，原因是因为类方法在元类中是实例方法

优化

上面的这种方式是单独在每个类中重写，有没有更好的，一劳永逸的方法呢？其实通过方法慢速查找流程可以发现其查找路径有两条

+ (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("LGPerson"), @selector(lgClassMethod));
        Method lgClassMethod  = class_getInstanceMethod(objc_getMetaClass("LGPerson"), @selector(lgClassMethod));
        const char *type = method_getTypeEncoding(lgClassMethod);
        return class_addMethod(objc_getMetaClass("LGPerson"), sel, imp, type);
    }
    return NO;
}

当然，上面这种写法还是会有其他的问题，比如系统方法也会被更改，针对这一点，是可以优化的，即我们可以针对自定义类中方法统一方法名的前缀，根据前缀来判断是否是自定义方法，然后统一处理自定义方法，例如可以在崩溃前pop到首页，主要是用于app线上防崩溃的处理，提升用户的体验。

消息转发流程

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

通过instrumentObjcMessageSends

通过lookUpImpOrForward --> log_and_fill_cache --> logMessageSend,在logMessageSend源码下方找到instrumentObjcMessageSends的源码实现，所以，在main中调用
instrumentObjcMessageSends打印方法调用的日志信息，有以下两点准备工作
1、打开 objcMsgLogEnabled 开关，即调用instrumentObjcMessageSends方法时，传入YES

2、在main中通过extern 声明instrumentObjcMessageSends方法

extern void instrumentObjcMessageSends(BOOL flag);

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

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

运行代码，并前往/tmp/msgSends 目录，发现有msgSends开头的日志文件，打开发现在崩溃前，执行了以下方法

所以，综上所述，消息转发整体的流程如下

消息转发的处理主要分为两部分：

【第二次机会】快速转发

针对前文的崩溃问题，如果动态方法决议也没有找到实现，则需要在LGPerson中重写forwardingTargetForSelector方法，将LGPerson的实例方法的接收者指定为LGStudent的对象（LGStudent类中有say666的具体实现），如下所示

- (id)forwardingTargetForSelector:(SEL)aSelector{
    NSLog(@"%s - %@",__func__,NSStringFromSelector(aSelector));

//     runtime + aSelector + addMethod + imp
    //将消息的接收者指定为LGStudent，在LGStudent中查找say666的实现
    return [LGStudent alloc];
}

【第三次机会】慢速转发

针对第二次机会即快速转发中还是没有找到，则进入最后的一次挽救机会，即在LGPerson中重写methodSignatureForSelector，如下所示

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

- (void)forwardInvocation:(NSInvocation *)anInvocation{
    NSLog(@"%s - %@",__func__,anInvocation);
}

forwardInvocation也可以处理invocation事务，如下所示，修改invocation的target为[LGStudent alloc]，调用[anInvocation invoke]触发 即LGPerson类的say666实例方法的调用会调用LGStudent的say666方法

- (void)forwardInvocation:(NSInvocation *)anInvocation{
    NSLog(@"%s - %@",__func__,anInvocation);
    anInvocation.target = [LGStudent alloc];
    [anInvocation invoke];
}

所以，由上述可知，无论在forwardInvocation方法中是否处理invocation事务，程序都不会崩溃。

动态方法决议为什么执行两次？

上帝视角的探索

在慢速查找流程中，我们了解到resolveInstanceMethod方法的执行是通过lookUpImpOrForward --> resolveMethod_locked --> resolveInstanceMethod来到resolveInstanceMethod源码，在源码中通过发送消息触发，如下所示resolve_sel

所以可以在resolveInstanceMethod方法中IMP imp = lookUpImpOrNil(inst, sel, cls);处加一个断点，通过bt打印堆栈信息来看到底发生了什么

这一点可以通过代码调试来验证，如下所示，在class_getInstanceMethod方法处加一个断点，在执行了methodSignatureForSelector方法后，返回了签名，说明方法签名是生效的，苹果在走到invocation之前，给了开发者一次机会再去查询，所以走到class_getInstanceMethod这里，又去走了一遍方法查询say666,然后会再次走到动态方法决议

所以，上述的分析也印证了前文中resolveInstanceMethod方法执行了两次的原因

经过上面的论证，我们了解到其实在慢速小子转发流程中，在methodSignatureForSelector和 forwardInvocation方法之间还有一次动态方法决议，即苹果再次给的一个机会，如下图所示

image.png

总结

到目前为止，objc_msgSend发送消息的流程就分析完成了，在这里简单总结下

上一篇下一篇

猜你喜欢

热点阅读