在前面的篇章，我们分析了 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_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);
}
image
- 从上图可以看出，最后一个参数
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];
}
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消息，其实就是调用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
打印结果如下：
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工程中，且objcMsgLogEnabled为true时，才会执行logMessageSend方法
image
- 进入
logMessageSend方法，源码如下：
image
从上图我们可以发现日志文件保存的路径为/tmp/msgSends-xxx，开启之后，就可以到沙盒路径下获取到日志文件。
【问题】 objcMsgLogEnabled的默认值为false，所以我们需要找到赋值的地方
- 全局搜索
objcMsgLogEnabled，发现在objc-class.mm文件中的instrumentObjcMessageSends方法就是用来控制是否开启日志
image
日志打印
- 新建一个
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;
}
image
- 运行程序，快捷键
coomand + shift + g打开/tmp文件夹，发现会生成msgSends-40601文件
image
- 打开
msgSends-40601文件，在动态决议方法之后进入小溪转发流程， 消息转发流程有forwardingTargetForSelector和methodSignatureForSelector，我们会在后面进行分析
image
