objc_msgSend消息流程之动态方法决议和消息转发
在前两篇文章objc_msgSend流程之快速查找和objc_msgSend流程之慢速查找分析了objc_msgSend
的快速查找
和慢速查找
,当前面这两种方式都没找到对应的方法实现
时,我们可以通过操作下面两个方法来避免方法未实现
的奔溃报错
-
动态方法决议
:在慢速查找流程未找到后,会执行一次 -
消息转发
:如果动态方法决议没有找到实现,则进行消息转发- 快速转发
- 慢速转发
实例方法报错
实例方法报错类方法报错
类方法报错方法未实现报错源码
汇编__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
方法
// 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
方法就是我们日常开发中常见错误没有实现函数,运行程序,崩溃时报的错误提示
防止方法未实现崩溃的三次机会
- 【第一次机会】
动态方法决议
-
消息转发流程
- 【第二次机会】
快速转发
- 【第三次机会】
慢速转发
- 【第二次机会】
【第一次机会】动态方法决议
在慢速查找
流程未找到
方法实现时,首先尝试一次动态方法决议
,源码实现如下
static NEVER_INLINE IMP
resolveMethod_locked(id inst, SEL sel, Class cls, int behavior)
{
runtimeLock.assertLocked();
ASSERT(cls->isRealized());
runtimeLock.unlock();
//对象 -- 类
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 (!lookUpImpOrNil(inst, sel, cls)) { //如果没有找到或者为空,在元类的对象方法解析方法中查找
resolveInstanceMethod(inst, sel, cls);
}
}
// chances are that calling the resolver have populated the cache
// so attempt using it
//如果方法解析中将其实现指向其他方法,则继续走方法查找流程
return lookUpImpOrForward(inst, sel, cls, behavior | LOOKUP_CACHE);
}
- 判断是否是元类
- 如果是
类
,执行实例方法
的动态决议resolveInstanceMethod
- 如果是
元类
,执行类方法
的动态方法决议resolveClassMethod
,如果元类中没有找到
或者为空
,则在元类
的实例方法
的动态方法决议resolveInstanceMethod
中查找,是因为类方法在元类中是实例方法
,所以还需要查找元类中的实例方法的动态决议
- 如果是
- 如果
动态方法决议
中,将其实现指向了其他方法
,则继续查找指定的imp
,即继续慢速查找lookUpImpOrForward
流程
动态方法决议流程
实例方法的动态决议
实例方法
的调用,在快速查找和慢速查找均未找到实例方法
的实现时,我们还有一次挽救的机会,即尝试动态方法决议
,由于是实例方法
,所以会走到resolveInstanceMethod
方法,源码如下:
static void resolveInstanceMethod(id inst, SEL sel, Class cls)
{
runtimeLock.assertUnlocked();
ASSERT(cls->isRealized());
SEL resolve_sel = @selector(resolveInstanceMethod:);
// look的是 resolveInstanceMethod --相当于是发送消息前的容错处理
if (!lookUpImpOrNil(cls, resolve_sel, cls->ISA())) {
// Resolver not implemented.
return;
}
BOOL (*msg)(Class, SEL, SEL) = (typeof(msg))objc_msgSend;
bool resolved = msg(cls, resolve_sel, sel); //发送resolve_sel消息
// Cache the result (good or bad) so the resolver doesn't fire next time.
// +resolveInstanceMethod adds to self a.k.a. cls
//查找say666
IMP imp = lookUpImpOrNil(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 消息
前,需要查找cls类
中是否有改方法的实现
,即通过lookUpImpOrNil
方法又会进入lookUpImpOrForward
慢速查找流程查找resolveInstanceMethod
方法- 如果没有,直接返回
- 如果有,则发送
resolveInstanceMethod
消息
- 再次慢速查找实例方法的实现,即通过
lookUpImpOrNil
方法又会进入lookUpImpOrForward
慢速查找流程查找对应的实例方法
奔溃修改
针对实例方法未实现
的奔溃报错,我们可以通过在类
中重写resolveInstanceMethod 类方法
,并将其指向其他方法的实现,即将实例方法say666
的实现指向sayMaster
+ (BOOL)resolveInstanceMethod:(SEL)sel{
if (sel == @selector(say666)) {
NSLog(@"%@ 来了", NSStringFromSelector(sel));
//获取sayMaster方法的imp
IMP imp = class_getMethodImplementation(self, @selector(sayMaster));
//获取sayMaster的实例方法
Method sayMethod = class_getInstanceMethod(self, @selector(sayMaster));
//获取sayMaster的丰富签名
const char *type = method_getTypeEncoding(sayMethod);
//将sel的实现指向sayMaster
return class_addMethod(self, sel, imp, type);
}
return [super resolveInstanceMethod:sel];
}
重新运行,并打印堆栈信息
堆栈信息
- 【第一次动态决议】查找
say666
方法时进入动态方法决议
- 【第二次动态决议】在慢速转发流程中调用了
CoreFoundation
框架中的NSObject(NSObject) methodSignatureForSelector:
后,会再次进入动态方法决议
第二次动态决议流程分析请看文末的问题探索
类方法的动态决议
针对类方法
的重写resolveClassMethod
,需要注意传入的cls
不再是类
,而是元类
,因为类方法在元类中是实例方法
,可以通过objc_getMetaClass
方法获取元类
优化
- 实例方法:
类 -- 父类 -- 根类 -- nil
- 类方法:
元类 -- 根元类 -- 根类 -- nil
通过上面方法的查找路径可以发现,都会来到根类(NSObject)
中查找
+ (BOOL)resolveInstanceMethod:(SEL)sel{
if (sel == @selector(say666)) {
NSLog(@"%@ 来了", NSStringFromSelector(sel));
IMP imp = class_getMethodImplementation(self, @selector(sayMaster));
Method sayMethod = class_getInstanceMethod(self, @selector(sayMaster));
const char *type = method_getTypeEncoding(sayMethod);
return class_addMethod(self, sel, imp, type);
}else if (sel == @selector(sayNB)) {
NSLog(@"%@ 来了", NSStringFromSelector(sel));
IMP imp = class_getMethodImplementation(objc_getMetaClass("LGPerson"), @selector(lgClassMethod));
Method lgClassMethod = class_getInstanceMethod(objc_getMetaClass("LGPerson"), @selector(lgClassMethod));
const char *type = method_getTypeEncoding(lgClassMethod);
return class_addMethod(objc_getMetaClass("LGPerson"), sel, imp, type);
}
return NO;
}
上面这种写法会导致系统方法也会被更改
,针对这一点,我们可以通过自定义类中方法的统一方法名前缀
,根据前缀来判断是否是自定义方法,然后统一处理自定义方法
,例如可以在崩溃前pop到首页,主要是用于app线上防崩溃的处理
,提升用户的体验
消息转发流程
在源码中找不到消息转发的源码,但是我们可以通过下面方式来了解,方法调用奔溃前都走了那些方法
- 通过
instrumentObjcMessageSends
方式打印发送消息的日志 - 痛过
hopper/IDA反编译
通过instrumentObjcMessageSends
- 通过
lookUpImpOrForward --> log_and_fill_cache --> logMessageSend
,在logMessageSend
源码中找到instrumentObjcMessageSends
的源码实现,然后再main函数
中调用instrumentObjcMessageSends
打印方法调用的日志信息,
- 1、打开objcMsgLogEnabled
开关,即调用instrumentObjcMessageSends
方法时,传入YES
- 2、在main
中通过extern
声明instrumentObjcMessageSends
方法
extern void instrumentObjcMessageSends(BOOL flag);
int main(int argc, const char * argv[]) {
@autoreleasepool {
LGPerson *person = [LGPerson alloc];
instrumentObjcMessageSends(YES);
[person sayHello];
instrumentObjcMessageSends(NO);
NSLog(@"Hello, World!");
}
return 0;
}
-
通过
消息发送日志路径logMessageSend
源码,可以发现消息发送打印信息存储在/tmp/msgSends
目录
-
运行代码,并前往
/tmp/msgSends
目录,发现有msgSends
开头的日志文件,可以发现在奔溃前,执行了以下方法- 两次
动态方法决议
:resolveInstanceMethod
方法 - 两次
消息快速转发
:forwardingTargetForSelector
方法 - 两次
消息慢速转发
:methodSignatureForSelector
+resolveInvocation
消息发送日志详情
- 两次
通过hopper/IDA反编译
Hopper和IDA是一个可以帮助我们静态分析可视性文件的工具,可以将可执行文件反汇编成伪代码,控制流程图等,下面以Hopper为例
-
运行程序奔溃,查看堆栈信息
查看堆栈打印信息 -
发现
___forwarding___源码定位___forwarding___
来自CoreFoundation
框架
-
通过
查找CoreFoundationimage list
命令,读取整个镜像文件,然后搜索CoreFoundation
,可以查看其可执行文件的路径
-
通过文件路径,找到
CoreFoundation执行文件路径CoreFoundation
的执行文件
-
打开
hopper反编译hopper
,选择Try the Demo
,然后将CoreFoundation
的可执行文件拖入hopper进行反编译,选择x86(64 bits)
hoperr反编译 -
反汇编后的界面
hopper界面 -
通过左侧的搜索框搜索
__forwarding_prep_0___
后,选择伪代码
-
以下是
伪代码___forwarding_____forwarding_prep_0___
的汇编伪代码,跳转至___forwarding___
-
以下是
伪代码-forwardingTargetForSelector___forwarding___
的伪代码实现,首先查看是否实现forwardingTargetForSelector
方法,如果没有响应,跳转至loc_6459b
即快速转发没有响应,进入慢速转发
流程
-
跳转至
伪代码-methodSignatureForSelectorloc_6459b
,在其下方判断是否响应methodSignatureForSelector
方法
-
如果
没有响应
,跳转至loc_6490b
,则直接报错 -
如果获取
伪代码-methodSignatureForSelector为nil时报错methodSignatureForSelector
的方法签名
为nil,也是直接报错
-
-
如果
伪代码-forwardInvocationmethodSignatureForSelector
返回值不为空,则在forwardInvocation
方法中对invocation
进行处理
通过上面两种查找方式可以验证,消息转发的方法有3个
-
【快速转发】
forwardingTargetForSelector
-
【慢速转发】
消息转发流程图
-methodSignatureForSelector
-forwardInvocation
所以消息转发的整体流程图如下
-
【快速转发】当慢速查找以及动态方法决议都没找到,首先进行
快速消息转发
,forwardingTargetForSelector
方法
- 如果返回消息接收者
,在消息接收者中还是没有找到,则进入另一个方法的查找流程
- 如果返回nil
,则进入慢速消息转发
-【慢速转发】 执行到methodSignatureForSelector
- 如果返回的方法签名
为nil
,则直接崩溃报错
- 如果返回的方法签名不为nil
,走到forwardInvocation
方法中,对invocation
事务进行处理,不处理也不会报错
【第二次机会】快速转发
在LGPerson中重写forwardingTargetForSelector
方法,将LGPerson的实例方法的接收者指定为LGStudent
的对象(LGStudent类中有say666的具体实现),如下所示
- (id)forwardingTargetForSelector:(SEL)aSelector{
NSLog(@"%s - %@",__func__,NSStringFromSelector(aSelector));
// runtime + aSelector + addMethod + imp
//将消息的接收者指定为LGStudent,在LGStudent中查找say666的实现
return [LGStudent alloc];
}
也可以直接不指定消息接收者,直接调用父类的该方法
,如果还是没有找到,则直接报错
- (id)forwardingTargetForSelector:(SEL)aSelector{
NSLog(@"%s - %@",__func__,NSStringFromSelector(aSelector));
// runtime + aSelector + addMethod + imp
return [super forwardingTargetForSelector:aSelector];
}
【第三次机会】慢速转发
如果消息快速转发
还是没有找到,则还有最后一次机会,即在LGPerson
中重写methodSignatureForSelector
- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector{
NSLog(@"%s - %@",__func__,NSStringFromSelector(aSelector));
return [NSMethodSignature signatureWithObjCTypes:"v@:"];
}
- (void)forwardInvocation:(NSInvocation *)anInvocation{
NSLog(@"%s - %@",__func__,anInvocation);
}
也可以处理invocation事务
- (void)forwardInvocation:(NSInvocation *)anInvocation{
NSLog(@"%s - %@",__func__,anInvocation);
anInvocation.target = [LGStudent alloc];
[anInvocation invoke];
}
我们在forwardInvocation
方法中处理和不处理invocation事务
,都不会报错
“动态方法决议为什么执行两次?” 探索
在慢速查找流程中,我们了解到resolveInstanceMethod
方法的执行是通过lookUpImpOrForward --> resolveMethod_locked --> resolveInstanceMethod
来到resolveInstanceMethod
源码,在源码中通过发送resolve_sel
消息触发
-
可以在
第一次动态方法决议堆栈信息resolveInstanceMethod
方法中IMP imp = lookUpImpOrNil(inst, sel, cls)
;处加一个断点,通过bt打印堆栈信息来看到底发生了什么
-
继续往下执行,直到第二次“来了”打印,查看堆栈信息,在第二次中,我们可以看到是通过
第二次动态方法决议堆栈信息CoreFoundation
的-[NSObject(NSObject) methodSignatureForSelector:]
方法,然后通过`class_getInstanceMethod再次进入动态方法决议
-
通过
methodSignatureForSelector伪代码进入方式Hopper
反汇编CoreFoundation
的可执行文件,查看methodSignatureForSelector
方法的伪代码
-
通过
methodDescriptionForSelector方法的伪代码methodSignatureForSelector
伪代码进入___methodDescriptionForSelector
的实现
-
进入
___methodDescriptionForSelector方法的伪代码调用了class_getInstanceMethod___methodDescriptionForSelector
的伪代码实现,结合汇编的堆栈打印,可以看到在___methodDescriptionForSelector
这个方法中调用了objc4-781
的class_getInstanceMethod
-
在objc中的源码中搜索
class_getInstanceMethod方法源码class_getInstanceMethod
,其源码实现如下所示
如下所示,在class_getInstanceMethod
方法处加一个断点,在执行了methodSignatureForSelector
方法后,返回了签名,说明方法签名是生效的,苹果在走到invocation
之前,给了开发者一次机会再去查询,所以走到class_getInstanceMethod
这里,又去走了一遍方法查询say666,然后会再次走到动态方法决议
所以,上述的分析也印证了前文中resolveInstanceMethod
方法执行了两次的原因
通过代码来推导
-
LGPerson中重写
resolveInstanceMethod方法调试验证resolveInstanceMethod
方法,并加上class_addMethod
操作即赋值IMP
,此时resolveInstanceMethod
会走两次吗
【结论】:通过运行发现,如果赋值了IMP,动态方法决议只会走一次
,说明不是在这里走第二次动态方法决议, -
去掉
forwardingTargetForSelector方法调试验证resolveInstanceMethod
方法中的赋值IMP
,在LGPerson类中重写forwardingTargetForSelector
方法,并指定返回值为[LGStudent alloc],重新运行,如果resolveInstanceMethod
打印了两次,说明是在forwardingTargetForSelector
方法之前执行了动态方法决议
,反之,在forwardingTargetForSelector
方法之后
【结论】:发现resolveInstanceMethod
中的打印还是只打印了一次,数排名第二次动态方法决议 在forwardingTargetForSelector
方法后
- 在LGPerson中重写
methodSignatureForSelector
和forwardInvocation
,运行
methodSignatureForSelector+forwardInvocation方法调试验证
【结论】:第二次动态方法决议
在methodSignatureForSelector
和forwardInvocation
方法之间
经过上面的论证,我们了解到其实在慢速转发流程中,在methodSignatureForSelector
和 forwardInvocation
方法之间还有一次动态方法决议
总结
objc_msgSend发送消息的流程
-
【快速查找流程】首先,在类的
缓存cache
中查找指定方法的实现 -
【慢速查找流程】如果缓存中没有找到,则在
类的方法列表
中查找,如果还是没找到,则去父类链的缓存和方法列表
中查找 -
【动态方法决议】如果慢速查找还是没有找到时,
第一次
补救机会就是尝试一次动态方法决议
,即重写resolveInstanceMethod/resolveClassMethod
方法 -
【消息转发】如果动态方法决议还是没有找到,则进行消息转发,消息转发中有
两次
补救机会:快速转发+慢速转发
-
如果转发之后也没有,则程序直接报错崩溃
unrecognized selector sent to instance