美文网首页
iOS底层原理12:动态方法决议

iOS底层原理12:动态方法决议

作者: 黑白森林无间道 | 来源:发表于2021-07-14 15:08 被阅读0次

    在前面的篇章,我们分析了 objc_msgSend的快速缓存查找以及 慢速查找流程(也就是递归流程),在这两种都没找到方法实现的情况下,苹果会进行容错处理

    • 动态方法决议:慢速查找流程未找到后,会执行一次动态方法决议
    • 消息转发:如果动态方法决议仍然没有找到实现,则进行消息转发

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

    方法未实现崩溃分析

    • 定义HTPerson类,其中sayHello实例方法和sayBye类方法均没有实现
    image
    • main.m中分别调用这两个方法,运行程序,均会报错,提示方法未实现,如下所示

      • 调用实例方法sayHello的报错结果
      image
      • 调用类方法sayBye的报错结果
      image

    方法未实现报错源码

    image

    根据慢速查找的源码,我们发现,其报错最后都是走到_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,并没有找到,在源码中去掉一个下划线进行全局搜索_objc_forward_handler,有如下实现,本质是调用的objc_defaultForwardHandler方法
    // 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有没有很眼熟,这就是我们在日常开发中最常见的错误:没有实现函数,运行程序,崩溃时报的错误提示

    【问题】 如何防止方法未实现的崩溃呢?

    动态方法决议

    在探究慢速查找流程lookUpImpOrForward中,如果没有查找到imp就会走动态方法决议流程resolveMethod_locked

    NEVER_INLINE
    IMP lookUpImpOrForward(id inst, SEL sel, Class cls, int behavior){
      ...
      
      // No implementation found. Try method resolver once.
      // 如果查询方法没有实现,系统会尝试一次方法解析
      if (slowpath(behavior & LOOKUP_RESOLVER)) {
          behavior ^= LOOKUP_RESOLVER;
          //动态方法决议
          return resolveMethod_locked(inst, sel, cls, behavior);
      }
     
      ...
    }
    

    resolveMethod_locked源码分析

    • 动态方法决议resolveMethod_locked,源码如下
    /***********************************************************************
    * resolveMethod_locked
    * Call +resolveClassMethod or +resolveInstanceMethod.
    *
    * Called with the runtimeLock held to avoid pressure in the caller
    * Tail calls into lookUpImpOrForward, also to avoid pressure in the callerb
    **********************************************************************/
    static NEVER_INLINE IMP
    resolveMethod_locked(id inst, SEL sel, Class cls, int behavior)
    {
        runtimeLock.assertLocked();
        ASSERT(cls->isRealized());
    
        runtimeLock.unlock();
        // 判断cls类是否是元类,如果不是元类,说明调用的是实例方法
        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
        // 快速查找和慢速查找sel对应的imp返回imp 实际上就是从缓存中取,因为前面动态方法决议处理过,缓存中就有了
        return lookUpImpOrForwardTryCache(inst, sel, cls, behavior);
    }
    

    resolveMethod_locked方法主要有以下几步:

    • 首先判断cls是否是元类
      • 如果不是元类只是普通类,那么说明调用的实例方法跳转resolveInstanceMethod流程
      • 如果是元类,那么说明调用的是类方法跳转resolveClassMethod流程
    • lookUpImpOrForwardTryCache快速查找和慢速查找sel对应的imp, 然后返回imp

    resolveInstanceMethod方法分析

    /***********************************************************************
    * resolveInstanceMethod
    * Call +resolveInstanceMethod, looking for a method to be added to class cls.
    * cls may be a metaclass or a non-meta class.
    * Does not check if the method already exists.
    **********************************************************************/
    static void resolveInstanceMethod(id inst, SEL sel, Class cls)
    {
        // inst 对象  // cls 类
        runtimeLock.assertUnlocked();
        ASSERT(cls->isRealized());
        SEL resolve_sel = @selector(resolveInstanceMethod:);
    
        // 只要cls的元类初始化 resolve_sel方法一定实现,因为NSObject默认实现了resolveInstanceMethod
        // 目的是将resolveInstanceMethod方法缓存到cls的元类中
        if (!lookUpImpOrNilTryCache(cls, resolve_sel, cls->ISA(/*authenticated*/true))) {
            // Resolver not implemented.
            return;
        }
    
        // 发送消息调用resolveInstanceMethod方法
        // 通过 objc_msgSend 发送消息 接收者是cls说明是类方法
        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
        // 为什么这里还要调用 lookUpImpOrNilTryCache 查询缓存和慢速查找呢?
        // 虽然 resolveInstanceMethod 方法调用了。但是里面不一定实现了sel的方法
        // 所以还是要去查找sel对应的imp,如果没有实现就会把imp = forward_imp 插入缓存中
        IMP imp = lookUpImpOrNilTryCache(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方法主要有以下几步:

    • 在发送resolveInstanceMethod消息前,需要查找cls类是否实现了resolveInstanceMethod方法,因为NSObject默认实现了resolveInstanceMethod,所以会继续向下执行
    • 发送resolveInstanceMethod消息
    • 再次通过lookUpImpOrNilTryCache(inst, sel, cls)快速和慢速查找流程,主要是用来判断resolveInstanceMethod中是否对方法进行了实现
      • 通过lookUpImpOrNilTryCache来确定resolveInstanceMethod方法中有没有实现sel对应的imp
      • 如果实现了,缓存中没有,进入lookUpImpOrForward查找到sel对应imp插入缓存,调用imp查找流程结束
      • 如果没有实现,缓存中没有,进入lookUpImpOrForward查找,sel没有查找到对应的imp,此时imp = forward_imp动态方法决议只调用一次,此时会走done_unlockdone流程,即selforward_imp插入缓存,进行消息转发

    resolveClassMethod方法分析

    /***********************************************************************
    * resolveClassMethod
    * Call +resolveClassMethod, looking for a method to be added to class cls.
    * cls should be a metaclass.
    * Does not check if the method already exists.
    **********************************************************************/
    static void resolveClassMethod(id inst, SEL sel, Class cls)
    {
        runtimeLock.assertUnlocked();
        ASSERT(cls->isRealized());
        ASSERT(cls->isMetaClass());
        // inst 类 //cls元类
        // 查询元类有没有实现  NSObject默认实现resolveClassMethod方法
        if (!lookUpImpOrNilTryCache(inst, @selector(resolveClassMethod:), cls)) {
            // Resolver not implemented.
            return;
        }
    
        Class nonmeta;
        {
            mutex_locker_t lock(runtimeLock);
            nonmeta = getMaybeUnrealizedNonMetaClass(cls, inst);
            // +initialize path should have realized nonmeta already
            if (!nonmeta->isRealized()) {
                _objc_fatal("nonmeta class %s (%p) unexpectedly not realized",
                            nonmeta->nameForLogging(), nonmeta);
            }
        }
        // nonmeta 从字面意思可以看出来,这不是一个元类
        // 向类中发送resolveClassMethod消息
        BOOL (*msg)(Class, SEL, SEL) = (typeof(msg))objc_msgSend;
        bool resolved = msg(nonmeta, @selector(resolveClassMethod:), 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 = lookUpImpOrNilTryCache(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));
            }
        }
    }
    
    • resolveClassMethodNSobject中已经实现,只要元类初始化就可以了,目的是缓存在元类中
    • 发送resolveClassMethod消息,因为我们可以在其中可能已经实现imp
    • imp = lookUpImpOrNilTryCache(inst, sel, cls) 缓存sel对应的imp,不管imp有没有动态添加,如果没有添加的就是forward_imp

    lookUpImpOrNilTryCache方法分析

    lookUpImpOrNilTryCache方法名字可以看出,就是尽可能的通过查询cache的方式查找imp或者nil,在resolveInstanceMethod方法和resolveClassMethod方法都调用lookUpImpOrNilTryCache

    IMP lookUpImpOrNilTryCache(id inst, SEL sel, Class cls, int behavior)
    {
        // LOOKUP_NIL = 4  没有传参数behavior = 0   0 | 4 = 4
        return _lookUpImpTryCache(inst, sel, cls, behavior | LOOKUP_NIL);
    }
    
    image
    • 从上图可以看出,最后一个参数behavior没传,即behavior = 0LOOKUP_NIL = 4,所以behavior | LOOKUP_NIL = 4
    • 继续查看_lookUpImpTryCache源码如下
    ALWAYS_INLINE
    static IMP _lookUpImpTryCache(id inst, SEL sel, Class cls, int behavior)
    {
        runtimeLock.assertUnlocked();
        //cls 是否初始化
        if (slowpath(!cls->isInitialized())) {
            // see comment in lookUpImpOrForward
            // 没有初始化就去查找 lookUpImpOrForward 查找时可以初始化
            return lookUpImpOrForward(inst, sel, cls, behavior);
        }
    
        // 在缓存中查找sel对应的imp
        IMP imp = cache_getImp(cls, sel);
        // imp有值 进入done流程
        if (imp != NULL) goto done;
    #if CONFIG_USE_PREOPT_CACHES
        //是否有共享缓存
        if (fastpath(cls->cache.isConstantOptimizedCache(/* strict */true))) {
            imp = cache_getImp(cls->cache.preoptFallbackClass(), sel);
        }
    #endif
        // 缓存中没有查询到imp 进入慢速查找流程
        // behavior = 4 ,4 & 2 = 0 不会进入动态方法决议,所以不会一直循环
        if (slowpath(imp == NULL)) {
            return lookUpImpOrForward(inst, sel, cls, behavior);
        }
    
    done:
        //(behavior & LOOKUP_NIL) = 4 & 4 = 1
        //主要是来判断 imp是否实现了方法
        if ((behavior & LOOKUP_NIL) && imp == (IMP)_objc_msgForward_impcache) {
            return nil;
        }
        return imp;
    }
    

    _lookUpImpTryCache主要有以下几步

    • 判断cls是否初始化,一般都会初始化
    • 缓存中查找cache_getImp(cls, sel)
      • 如果imp存在跳转done流程
      • 判断是否有共享缓存(系统底层库用的)
      • 如果缓存中没有查询到imp,进入慢速查找流程
    • 慢速查找流程
      • behavior = 44 & 2 = 0 不会进入动态方法决议,所以不会一直循环
      • 此时 imp = forward_imp,跳转lookUpImpOrForward中的done流程,插入缓存,返回forward_imp(即_objc_msgForward_impcache)
    • done流程
      • (behavior & LOOKUP_NIL) 且 imp = _objc_msgForward_impcache,如果缓存中的是forward_imp,就直接返回nil,否则返回的imp

    崩溃修复

    实例方法未实现修复

    • HTPerson类中添加resolveInstanceMethod方法
    + (BOOL)resolveInstanceMethod:(SEL)sel {
        NSLog(@"resolveInstanceMethod: %@-%@", self, NSStringFromSelector(sel));
        return [super resolveInstanceMethod:sel];
    }
    
    image
    • 从上图可以看出,在崩溃之前确实调用了两次resolveInstanceMethod方法

    【问题】 为什么会调用两次resolveInstanceMethod方法呢?第一次是走动态方法决议系统自动向resolveInstanceMethod发送消息,那么第二次是怎么调用的呢?

    resolveInstanceMethod的函数调用栈

    • 第一次调用resolveInstanceMethod的堆栈信息如下图,可以发现走的是慢速查找流程,如果没有找到imp,会走一次动态决议方法
    image
    • 第二次调用resolveInstanceMethod的堆栈信息如下图,发现是由底层系统库CoreFoundation调用-[NSObject(NSObject) methodSignatureForSelector:],再次开启慢速查找流程,进入动态方法决议又调用一次resolveInstanceMethod,所以总共是两次,第二次调用的详细流程在后面会作详细的阐述
    image

    重写resolveInstanceMethod方法,动态添加sayHello方法

    + (BOOL)resolveInstanceMethod:(SEL)sel {
        NSLog(@"resolveInstanceMethod: %@-%@", self, NSStringFromSelector(sel));
    
        if (sel == @selector(sayHello)) {
            //获取sayHello2方法的imp
            IMP sayHelloImp = class_getMethodImplementation(self, @selector(sayHello2));
            //获取sayHello2的实例方法
            Method method = class_getInstanceMethod(self, @selector(sayHello2));
            const char *type = method_getTypeEncoding(method);
            //通过runtime动态添加 sayHello实现
            class_addMethod(self, @selector(sayHello), sayHelloImp, type);
        }
    
        return [super resolveInstanceMethod:sel];
    }
    
    - (void)sayHello2 {
        NSLog(@"%s", __func__);
    }
    
    image
    运行程序,resolveInstanceMethod方法只调用一次,因为动态添加了sayHello方法实现,lookUpImpOrForwardTryCache可以获取imp,直接返回imp,查找流程结束
    • 奔溃得到了解决,动态决议方法给我们一次补救的机会
    • 调用流程如下:resolveMethod_locked --> resolveInstanceMethod --> 发送消息调用resolveInstanceMethod方法 --> lookUpImpOrForwardTryCache --> 调用imp

    类方法未实现修复

    • HTPerson类中的类方法sayBye未实现,添加resolveClassMethod方法
    + (BOOL)resolveClassMethod:(SEL)sel {
        NSLog(@"resolveClassMethod: %@-%@", self, NSStringFromSelector(sel));
    
        return [super resolveClassMethod:sel];
    }
    
    image
    • 运行发现,在崩溃之前确实调用了resolveClassMethod方法,而且调用了两次,调用两次的逻辑和resolveInstanceMethod方法调用两次是一样的

    重写resolveClassMethod方法,动态添加sayBye方法

    + (BOOL)resolveClassMethod:(SEL)sel {
        
        if (@selector(sayBye) == sel) {
            NSLog(@"resolveClassMethod: %@-%@", self, NSStringFromSelector(sel));
            
            IMP imp = class_getMethodImplementation(objc_getMetaClass("HTPerson"), @selector(sayBye2));
            Method method = class_getClassMethod(objc_getMetaClass("HTPerson"), @selector(sayBye2));
            const char * type = method_getTypeEncoding(method);
            
            return class_addMethod(objc_getMetaClass("HTPerson"), sel, imp, type);
        }
        return [super resolveClassMethod:sel];
    }
    
    + (void)sayBye2 {
        NSLog(@"%s", __func__);
    }
    

    运行程序,resolveClassMethod方法只调用一次,因为我们动态添加了sayBye的方法实现,所以不会崩溃

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

    resolveClassMethod 特殊之处

    • 进入resolveClassMethod方法,我们发现了消息接收者是nonmeta(是类,并不是元类),这就是我们可以通过实现resolveClassMethod类方法来添加方法实现,解决崩溃问题
    image image

    从上图,我们可以发现,执行完resolveClassMethod后,如果还没有找到imp,则会继续执行一次resolveInstanceMethod

    【问题】为什么这里还会执行一次 resolveInstanceMethod方法呢,猜测与 class的 isa走位图有关

    如果cls是元类,则 inst就是类,此时调用resolveInstanceMethod方法,相当于是向元类发送了resolveInstanceMethod消息

    image
    • objc_msgSend发送消息不区分-+方法。objc_msgSend的接收者cls是元类,元类的方法列表中存的就是 类的类方法
    • HTPerson的元类是系统默认帮我们实现的,向元类发送resolveInstanceMethod,因为元类的isa指向根元类,会在根元类进入快速流程和慢速流程来查找imp是否实现
    • 向元类发送resolveInstanceMethod消息,其实就是调用NSObjectresolveInstanceMethod类方法

    整合动态方法决议

    resolveClassMethod方法中如果没有动态添加类方法,会调用元类中的resolveInstanceMethod。根据类的isa走位图,最终都会走到 根类NSObjectresolveInstanceMethod类方法中

    • 动态方法决议最终都会走到NSObject类中,所以我们可以把逻辑写到NSObject分类resolveInstanceMethod类方法中,整合代码如下
    #import "NSObject+extension.h"
    #import "objc-runtime.h"
    
    @implementation NSObject (extension)
    
    + (BOOL)resolveInstanceMethod:(SEL)sel {
        
        if (@selector(sayHello) == sel) {
            
            NSLog(@"===根类=====resolveInstanceMethod: %@-%@", self, NSStringFromSelector(sel));
            IMP imp = class_getMethodImplementation(self , @selector(sayHello2));
            Method meth = class_getInstanceMethod(self , @selector(sayHello2));
            const char *type = method_getTypeEncoding(meth);
            class_addMethod(self ,sel, imp, type);
            
        } else if (@selector(sayBye) == sel) {
            NSLog(@"===根类=====resolveInstanceMethod: %@-%@", self, NSStringFromSelector(sel));
            IMP imp = class_getMethodImplementation(object_getClass([self class]), @selector(newTest));
            Method meth = class_getClassMethod(object_getClass([self class]) ,@selector(newTest));
            const char *type = method_getTypeEncoding(meth);
            class_addMethod(object_getClass([self class]) ,sel, imp, type);
        }
        return NO;
    }
    
    - (void)sayHello2 {
         NSLog(@"-根类-%s---", __func__);
    }
    
    + (void)newTest {
        NSLog(@"-根类-%s---", __func__);
    }
    
    @end
    

    打印结果如下:


    image

    动态方法决议优点

    • 可以统一处理方法崩溃的问题,出现方法崩溃可以上报服务器,或者跳转到首页
    • 如果项目中是不同的模块你可以根据命名不同,进行业务的区别
    • 这种方式叫切面编程AOP

    AOP和OOP的区别

    • OOP:实际上是对对象的属性和行为的封装,功能相同的抽取出来单独封装,强依赖性,高耦合
    • AOP:是处理某个步骤和阶段的,从中进行切面的提取,有重复的操作行为,AOP就可以提取出来,运用动态代理,实现程序功能的统一维护,依赖性小,耦合度小,单独把AOP提取出来的功能移除也不会对主代码造成影响。AOP更像一个三维的纵轴,平面内的各个类有共同逻辑的通过AOP串联起来,本身平面内的各个类没有任何的关联

    消息转发

    快速和慢速查找流程没有查询到,动态决议方法也没有查找到,下面就会进入消息转发流程,但是在objc4-818.2源码中没有发现相关的源码,CoreFunction提供的源码也查询不到。苹果还是提供了日志辅助功能

    日志辅助

    通过lookUpImpOrForward --> log_and_fill_cache --> logMessageSend,我们来分析如何打印日志

    • log_and_fill_cache方法中发现,只有在macOS工程中,且objcMsgLogEnabledtrue时,才会执行logMessageSend方法
    image
    • 进入logMessageSend方法,源码如下:
    image

    从上图我们可以发现日志文件保存的路径为/tmp/msgSends-xxx,开启之后,就可以到沙盒路径下获取到日志文件

    【问题】 objcMsgLogEnabled的默认值为false,所以我们需要找到赋值的地方

    • 全局搜索objcMsgLogEnabled,发现在objc-class.mm文件中的instrumentObjcMessageSends方法就是用来控制是否开启日志
    image

    日志打印

    • 新建一个macOSCommand Line Tool工程,代码如下
    extern void instrumentObjcMessageSends(BOOL flag);
    
    int main(int argc, const char * argv[]) {
        @autoreleasepool {
            
            HTPerson *p = [[HTPerson alloc] init];
            
            instrumentObjcMessageSends(YES);
            [p sayHello]; // sayHello方法未实现
            instrumentObjcMessageSends(NO);
        }
        return 0;
    }
    
    image
    • 运行程序,快捷键coomand + shift + g 打开/tmp文件夹,发现会生成msgSends-40601文件
    image
    • 打开msgSends-40601文件,在动态决议方法之后进入小溪转发流程, 消息转发流程有forwardingTargetForSelectormethodSignatureForSelector,我们会在后面进行分析
    image

    相关文章

      网友评论

          本文标题:iOS底层原理12:动态方法决议

          本文链接:https://www.haomeiwen.com/subject/ivuypltx.html