objc_msgSend消息流程之动态方法决议和消息转发

在前两篇文章objc_msgSend流程之快速查找和objc_msgSend流程之慢速查找分析了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

在汇编实现中查找_objc_forward_handler方法

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

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
    • 如果是元类，执行类方法的动态方法决议resolveClassMethod，如果元类中没有找到或者为空，则在元类的实例方法的动态方法决议resolveInstanceMethod中查找，是因为类方法在元类中是实例方法，所以还需要查找元类中的实例方法的动态决议
  • 如果动态方法决议中，将其实现指向了其他方法，则继续查找指定的imp，即继续慢速查找lookUpImpOrForward流程
    动态方法决议流程

实例方法的动态决议

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

主要分为以下几个步骤

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

奔溃修改

针对实例方法未实现的奔溃报错，我们可以通过在类中重写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];
}

重新运行，并打印堆栈信息


堆栈信息
  • 【第一次动态决议】查找say666方法时进入动态方法决议
  • 【第二次动态决议】在慢速转发流程中调用了CoreFoundation框架中的NSObject(NSObject) methodSignatureForSelector:后，会再次进入动态方法决议

第二次动态决议流程分析请看文末的问题探索

类方法的动态决议

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

优化
  • 实例方法：类 -- 父类 -- 根类 -- nil
  • 类方法：元类 -- 根元类 -- 根类 -- nil
    通过上面方法的查找路径可以发现，都会来到根类（NSObject）中查找
+ (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方式打印发送消息的日志
  • 痛过hopper/IDA反编译

通过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;
}

  • 通过logMessageSend源码，可以发现消息发送打印信息存储在/tmp/msgSends目录

    消息发送日志路径

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

    • 两次动态方法决议：resolveInstanceMethod 方法
    • 两次消息快速转发：forwardingTargetForSelector 方法
    • 两次消息慢速转发：methodSignatureForSelector + resolveInvocation
      消息发送日志详情

通过hopper/IDA反编译

Hopper和IDA是一个可以帮助我们静态分析可视性文件的工具，可以将可执行文件反汇编成伪代码，控制流程图等，下面以Hopper为例

  • 运行程序奔溃，查看堆栈信息


    查看堆栈打印信息

  • 发现___forwarding___ 来自CoreFoundation框架

    ___forwarding___源码定位

  • 通过image list命令，读取整个镜像文件，然后搜索CoreFoundation，可以查看其可执行文件的路径

    查找CoreFoundation

  • 通过文件路径，找到CoreFoundation的执行文件

    CoreFoundation执行文件路径

  • 打开hopper，选择Try the Demo，然后将CoreFoundation的可执行文件拖入hopper进行反编译，选择x86(64 bits)

    hopper反编译

    hoperr反编译

  • 反汇编后的界面


    hopper界面

  • 通过左侧的搜索框搜索__forwarding_prep_0___后，选择伪代码

    • 以下是__forwarding_prep_0___的汇编伪代码，跳转至___forwarding___

      伪代码___forwarding___

    • 以下是___forwarding___的伪代码实现，首先查看是否实现forwardingTargetForSelector方法，如果没有响应，跳转至loc_6459b即快速转发没有响应，进入慢速转发流程

      伪代码-forwardingTargetForSelector

    • 跳转至loc_6459b，在其下方判断是否响应methodSignatureForSelector方法

      伪代码-methodSignatureForSelector

    • 如果没有响应，跳转至loc_6490b，则直接报错

    • 如果获取methodSignatureForSelector的方法签名为nil，也是直接报错

      伪代码-methodSignatureForSelector为nil时报错

  • 如果methodSignatureForSelector返回值不为空，则在forwardInvocation方法中对invocation进行处理

    伪代码-forwardInvocation

通过上面两种查找方式可以验证，消息转发的方法有3个

  • 【快速转发】forwardingTargetForSelector

  • 【慢速转发】
    - methodSignatureForSelector
    - forwardInvocation
    所以消息转发的整体流程图如下

    消息转发流程图

  • 【快速转发】当慢速查找以及动态方法决议都没找到，首先进行快速消息转发，forwardingTargetForSelector方法
    - 如果返回消息接收者，在消息接收者中还是没有找到，则进入另一个方法的查找流程
    - 如果返回nil，则进入慢速消息转发
    -【慢速转发】 执行到methodSignatureForSelector
    - 如果返回的方法签名为nil，则直接崩溃报错
    - 如果返回的方法签名不为nil，走到forwardInvocation方法中，对invocation事务进行处理，不处理也不会报错

【第二次机会】快速转发

在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];
}

也可以直接不指定消息接收者，直接调用父类的该方法，如果还是没有找到，则直接报错

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

    // runtime + aSelector + addMethod + imp
    return [super forwardingTargetForSelector:aSelector];
}

【第三次机会】慢速转发

如果消息快速转发还是没有找到，则还有最后一次机会，即在LGPerson中重写methodSignatureForSelector

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

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

也可以处理invocation事务

- (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方法触发原理

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

    第一次动态方法决议堆栈信息

  • 继续往下执行，直到第二次“来了”打印，查看堆栈信息，在第二次中，我们可以看到是通过CoreFoundation的-[NSObject(NSObject) methodSignatureForSelector:]方法，然后通过`class_getInstanceMethod再次进入动态方法决议

    第二次动态方法决议堆栈信息

  • 通过Hopper反汇编CoreFoundation的可执行文件，查看methodSignatureForSelector方法的伪代码

    methodSignatureForSelector伪代码进入方式

  • 通过methodSignatureForSelector伪代码进入___methodDescriptionForSelector的实现

    methodDescriptionForSelector方法的伪代码

  • 进入___methodDescriptionForSelector的伪代码实现，结合汇编的堆栈打印，可以看到在___methodDescriptionForSelector这个方法中调用了objc4-781的class_getInstanceMethod

    ___methodDescriptionForSelector方法的伪代码调用了class_getInstanceMethod

  • 在objc中的源码中搜索class_getInstanceMethod，其源码实现如下所示

    class_getInstanceMethod方法源码

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

class_getInstanceMethod方法调试验证

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

通过代码来推导

  • LGPerson中重写resolveInstanceMethod方法，并加上class_addMethod操作即赋值IMP，此时resolveInstanceMethod会走两次吗

    resolveInstanceMethod方法调试验证

    【结论】：通过运行发现，如果赋值了IMP，动态方法决议只会走一次，说明不是在这里走第二次动态方法决议，

  • 去掉resolveInstanceMethod方法中的赋值IMP，在LGPerson类中重写forwardingTargetForSelector方法，并指定返回值为[LGStudent alloc]，重新运行，如果resolveInstanceMethod打印了两次，说明是在forwardingTargetForSelector方法之前执行了 动态方法决议，反之，在forwardingTargetForSelector方法之后

    forwardingTargetForSelector方法调试验证

【结论】：发现resolveInstanceMethod中的打印还是只打印了一次，数排名第二次动态方法决议 在forwardingTargetForSelector方法后

  • 在LGPerson中重写methodSignatureForSelector 和 forwardInvocation，运行
    methodSignatureForSelector+forwardInvocation方法调试验证

    【结论】：第二次动态方法决议在 methodSignatureForSelector 和 forwardInvocation方法之间

经过上面的论证，我们了解到其实在慢速转发流程中，在methodSignatureForSelector 和 forwardInvocation方法之间还有一次动态方法决议

消息转发流程-2

总结

objc_msgSend发送消息的流程

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

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

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

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

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

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 199,175评论 5赞 466
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 83,674评论 2赞 376
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 146,151评论 0赞 328
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 53,597评论 1赞 269
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 62,505评论 5赞 359
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 47,969评论 1赞 275
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 37,455评论 3赞 390
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 36,118评论 0赞 254
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 40,227评论 1赞 294
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,213评论 2赞 317
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,214评论 1赞 328
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 32,928评论 3赞 316
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 38,512评论 3赞 302
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,616评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,848评论 1赞 255
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 42,228评论 2赞 344
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 41,772评论 2赞 339

推荐阅读更多精彩内容