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

毅会

 关注

阅读 62

2021-10-04

在前面的篇章，我们分析了 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_unlock和done流程，即sel和forward_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));
        }
    }
}
  • resolveClassMethod在NSobject中已经实现，只要元类初始化就可以了，目的是缓存在元类中
  • 发送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 = 0，LOOKUP_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 = 4 ，4 & 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消息，其实就是调用NSObject的resolveInstanceMethod类方法

整合动态方法决议

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

  • 动态方法决议最终都会走到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工程中，且objcMsgLogEnabled为true时，才会执行logMessageSend方法

  • 进入logMessageSend方法，源码如下：

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

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

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

日志打印

  • 新建一个macOS的Command 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文件，在动态决议方法之后进入小溪转发流程， 消息转发流程有forwardingTargetForSelector和methodSignatureForSelector，我们会在后面进行分析

相关推荐

Objective-C 动态方法决议

向上的萝卜白菜 79 0 0

iOS底层原理23：KVO底层原理

前程有光 52 0 0

iOS底层原理22：KVC底层原理

Separes 96 0 0

iOS 底层原理（一）：静态库与动态库

小龟老师 76 0 0

消息发送之 动态方法决议&消息转发

互联网码农 46 0 0

iOS底层原理：NSDictionary原理

以沫的窝 90 0 0

ios底层原理 :内存对齐原理

西特张 109 0 0

iOS底层原理21：Method-Swizzling方法交换

他说Python 76 0 0

iOS KVC底层原理分析

松鼠树屋 90 0 0

动态代理（aop底层原理）

ZGtheGreat 55 0 0

精彩评论（0）

0 0 举报