在前面的篇章,我们分析了 objc_msgSend的快速缓存查找
以及 慢速查找流程
(也就是递归流程),在这两种都没找到方法实现的情况下,苹果会进行容错处理
-
动态方法决议
:慢速查找流程未找到后,会执行一次动态方法决议 -
消息转发
:如果动态方法决议仍然没有找到实现,则进行消息转发
如果这两个建议都没有做任何操作,就会报我们日常开发中常见的方法未实现
的崩溃报错
,其步骤如下
方法未实现崩溃分析
- 定义
HTPerson
类,其中sayHello
实例方法和sayBye
类方法均没有实现
-
在
main.m
中分别调用这两个方法,运行程序,均会报错
,提示方法未实现
,如下所示- 调用实例方法
sayHello
的报错结果
- 调用类方法
sayBye
的报错结果
- 调用实例方法
方法未实现报错源码
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,会走一次动态决议方法
- 第二次调用
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__);
}
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
类方法来添加方法实现,解决崩溃问题
从上图,我们可以发现,执行完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
打印结果如下:
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
方法
- 进入
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;
}
image
- 运行程序,快捷键
coomand + shift + g
打开/tmp
文件夹,发现会生成msgSends-40601
文件
- 打开
msgSends-40601
文件,在动态决议方法
之后进入小溪转发流程
, 消息转发流程有forwardingTargetForSelector
和methodSignatureForSelector
,我们会在后面进行分析
网友评论