0
点赞
收藏
分享

微信扫一扫

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

毅会 2021-10-04 阅读 53

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

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

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

方法未实现崩溃分析

  • 定义HTPerson类,其中sayHello实例方法和sayBye类方法均没有实现

  • main.m中分别调用这两个方法,运行程序,均会报错,提示方法未实现,如下所示

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

    • 调用类方法sayBye的报错结果

方法未实现报错源码

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

  • 从上图可以看出,最后一个参数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];
}

  • 从上图可以看出,在崩溃之前确实调用了两次resolveInstanceMethod方法

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

resolveInstanceMethod的函数调用栈

  • 第一次调用resolveInstanceMethod的堆栈信息如下图,可以发现走的是慢速查找流程,如果没有找到imp,会走一次动态决议方法

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

重写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__);
}


运行程序,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];
}

  • 运行发现,在崩溃之前确实调用了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类方法来添加方法实现,解决崩溃问题

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

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

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

  • 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

打印结果如下:


动态方法决议优点

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

  • 进入logMessageSend方法,源码如下:

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

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

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

日志打印

  • 新建一个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;
}

  • 运行程序,快捷键coomand + shift + g 打开/tmp文件夹,发现会生成msgSends-40601文件

  • 打开msgSends-40601文件,在动态决议方法之后进入小溪转发流程, 消息转发流程有forwardingTargetForSelectormethodSignatureForSelector,我们会在后面进行分析

举报

相关推荐

0 条评论