iOS 底层原理 文章汇总
引子
在前面两篇文章iOS-底层原理 12：objc_msgSend流程分析之快速查找和iOS-底层原理 13：objc_msgSend流程分析之慢速查找中，分别分析了objc_msgSend的快速查找和慢速查找，在这两种都没找到方法实现的情况下，苹果给了两个建议
-
动态方法决议：慢速查找流程未找到后，会执行一次动态方法决议 -
消息转发：如果动态方法决议仍然没有找到实现，则进行消息转发
如果这两个建议都没有做任何操作，就会报我们日常开发中常见的方法未实现的崩溃报错，其步骤如下
-
定义
LGPerson类，其中say666实例方法 和sayNB类方法均没有实现
自定义LGPerson类 -
main中 分别调用
LGPerson的实例方法say666和类方法sayNB，运行程序，均会报错，提示方法未实现，如下所示-
调用实例方法say666的报错结果
实例方法报错 -
调用类方法sayNB的报错结果
类方法报错
-
方法未实现报错源码
根据慢速查找的源码，我们发现，其报错最后都是走到__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有没有很眼熟，这就是我们在日常开发中最常见的错误：没有实现函数，运行程序，崩溃时报的错误提示。
下面，我们来讲讲如何在崩溃前，如何操作，可以防止方法未实现的崩溃。
三次方法查找的挽救机会
根据苹果的两个建议，我们一共有三次挽救的机会：
【第一次机会】
动态方法决议-
消息转发流程
- 【第二次机会】
快速转发 - 【第三次机会】
慢速转发
- 【第二次机会】
【第一次机会】动态方法决议
在慢速查找流程未找到方法实现时，首先会尝试一次动态方法决议，其源码实现如下：
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慢速查找流程查找实例方法
崩溃修改
所以，针对实例方法say666未实现的报错崩溃，可以通过在类中重写``resolveInstanceMethod类方法，并将其指向其他方法的实现，即在LGPerson中重写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];
}
重新运行，其打印结果如下
从结果中可以发现，resolveInstanceMethod动态决议方法中“来了”打印了两次，这是为什么呢？通过堆栈信息可以看出
- 【第一次动态决议】第一次的“来了”是在查找
say666方法时会进入动态方法决议 - 【第二次动态决议】第二次“来了”是在慢速转发流程中调用了
CoreFoundation框架中的NSObject(NSObject) methodSignatureForSelector:后，会再次进入动态决议
注：详细的分析流程请看文末的问题探索
类方法
针对类方法，与实例方法类似，同样可以通过重写resolveClassMethod类方法来解决前文的崩溃问题，即在LGPerson类中重写该方法，并将sayNB类方法的实现指向类方法lgClassMethod
+ (BOOL)resolveClassMethod:(SEL)sel{
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 [super resolveClassMethod:sel];
}
resolveClassMethod类方法的重写需要注意一点，传入的cls不再是类，而是元类，可以通过objc_getMetaClass方法获取类的元类，原因是因为类方法在元类中是实例方法
优化
上面的这种方式是单独在每个类中重写，有没有更好的，一劳永逸的方法呢？其实通过方法慢速查找流程可以发现其查找路径有两条
- 实例方法：
类 -- 父类 -- 根类 -- nil - 类方法：
元类 -- 根元类 -- 根类 -- nil
它们的共同点是如果前面没找到，都会来到根类即NSObject中查找，所以我们是否可以将上述的两个方法统一整合在一起呢？答案是可以的，可以通过NSObject添加分类的方式来实现统一处理，而且由于类方法的查找，在其继承链，查找的也是实例方法，所以可以将实例方法 和 类方法的统一处理放在resolveInstanceMethod方法中,如下所示
+ (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方法时，传入YES2、在
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为例(注：hopper高级版本是一款收费软件，针对比较简单的反汇编需求来说，demo版本足够使用了)
-
运行程序崩溃，查看堆栈信息
查看堆栈打印信息 -
发现
___forwarding___来自CoreFoundation
___forwarding___源码定位 -
通过
image list，读取整个镜像文件,然后搜索CoreFoundation，查看其可执行文件的路径
从镜像文件中查找CoreFoundation -
通过文件路径，找到
CoreFoundation的可执行文件
查找CoreFoundation的可执行文件 -
打开
hopper，选择Try the Demo，然后将上一步的可执行文件拖入hopper进行反汇编，选择x86(64 bits)
hopper选择Demo版本
hopper反汇编 -
以下是反汇编后的界面，主要使用上面的三个功能，分别是 汇编、流程图、伪代码
hoppper主要使用的三个功能 -
通过左侧的搜索框搜索
__forwarding_prep_0___，然后选择伪代码-
以下是
__forwarding_prep_0___的汇编伪代码，跳转至___forwarding___
伪代码-___forwarding___ -
以下是
___forwarding___的伪代码实现，首先是查看是否实现forwardingTargetForSelector方法，如果没有响应，跳转至loc_6459b即快速转发没有响应，进入慢速转发流程，
伪代码-forwardingTargetForSelector -
跳转至
loc_6459b，在其下方判断是否响应methodSignatureForSelector方法，
伪代码-methodSignatureForSelector如果
没有响应，跳转至loc_6490b，则直接报错-
如果获取
methodSignatureForSelector的方法签名为nil，也是直接报错
伪代码-methodSignatureForSelector为nil时报错
-
-
如果
methodSignatureForSelector返回值不为空，则在forwardInvocation方法中对invocation进行处理
伪代码-forwardInvocation
所以，通过上面两种查找方式可以验证，消息转发的方法有3个
- 【快速转发】
forwardingTargetForSelector - 【慢速转发】
methodSignatureForSelectorforwardInvocation
所以，综上所述，消息转发整体的流程如下
消息转发的处理主要分为两部分：
- 【快速转发】当慢速查找，以及动态方法决议均没有找到实现时，进行消息转发，首先是进行
快速消息转发，即走到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];
}
执行结果如下
也可以直接不指定消息接收者，直接调用父类的该方法，如果还是没有找到，则直接报错
【第三次机会】慢速转发
针对第二次机会即快速转发中还是没有找到，则进入最后的一次挽救机会，即在LGPerson中重写methodSignatureForSelector，如下所示
- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector{
NSLog(@"%s - %@",__func__,NSStringFromSelector(aSelector));
return [NSMethodSignature signatureWithObjCTypes:"v@:"];
}
- (void)forwardInvocation:(NSInvocation *)anInvocation{
NSLog(@"%s - %@",__func__,anInvocation);
}
打印结果如下，发现forwardInvocation方法中不对invocation进行处理，也不会崩溃报错
也可以处理invocation事务，如下所示，修改invocation的target为[LGStudent alloc]，调用 [anInvocation invoke] 触发 即LGPerson类的say666实例方法的调用会调用LGStudent的say666方法
- (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打印堆栈信息来看到底发生了什么
-
在
resolveInstanceMethod方法中IMP imp = lookUpImpOrNil(inst, sel, cls);处加一个断点，运行程序，直到第一次“来了”，通过bt查看第一次动态方法决议的堆栈信息，此时的sel是say666
第一次动态方法决议堆栈信息 -
继续往下执行，直到第二次
“来了”打印，查看堆栈信息，在第二次中，我们可以看到是通过CoreFoundation的-[NSObject(NSObject) methodSignatureForSelector:]方法，然后通过class_getInstanceMethod再次进入动态方法决议，
第二次动态方法决议堆栈信息 -
通过上一步的堆栈信息，我们需要去看看CoreFoundation中到底做了什么？通过
Hopper反汇编CoreFoundation的可执行文件，查看methodSignatureForSelector方法的伪代码
methodSignatureForSelector伪代码进入方式 -
通过
methodSignatureForSelector伪代码进入___methodDescriptionForSelector的实现
methodDescriptionForSelector方法的伪代码 -
进入
___methodDescriptionForSelector的伪代码实现，结合汇编的堆栈打印，可以看到，在___methodDescriptionForSelector这个方法中调用了objc4-781的class_getInstanceMethod
___methodDescriptionForSelector方法的伪代码调用了class_getInstanceMethod -
在objc中的源码中搜索
class_getInstanceMethod，其源码实现如下所示
class_getInstanceMethod方法源码
这一点可以通过代码调试来验证，如下所示，在class_getInstanceMethod方法处加一个断点，在执行了methodSignatureForSelector方法后，返回了签名，说明方法签名是生效的，苹果在走到invocation之前，给了开发者一次机会再去查询，所以走到class_getInstanceMethod这里，又去走了一遍方法查询say666,然后会再次走到动态方法决议
所以，上述的分析也印证了前文中resolveInstanceMethod方法执行了两次的原因
无上帝视角的探索
如果在没有上帝视角的情况下，我们也可以通过代码来推导在哪里再次调用了动态方法决议
- LGPerson中重写
resolveInstanceMethod方法，并加上class_addMethod操作即赋值IMP，此时resolveInstanceMethod会走两次吗？
resolveInstanceMethod方法调试验证
【结论】：通过运行发现，如果赋值了IMP，动态方法决议只会走一次，说明不是在这里走第二次动态方法决议，
继续往下探索
-
去掉
resolveInstanceMethod方法中的赋值IMP，在LGPerson类中重写forwardingTargetForSelector方法，并指定返回值为[LGStudent alloc]，重新运行，如果resolveInstanceMethod打印了两次，说明是在forwardingTargetForSelector方法之前执行了 动态方法决议，反之，在forwardingTargetForSelector方法之后
forwardingTargetForSelector方法调试验证
【结论】：发现resolveInstanceMethod中的打印还是只打印了一次，数排名第二次动态方法决议 在forwardingTargetForSelector方法后 -
在LGPerson中重写
methodSignatureForSelector和forwardInvocation，运行
methodSignatureForSelector+forwardInvocation方法调试验证
【结论】：第二次动态方法决议在methodSignatureForSelector和forwardInvocation方法之间
第二种分析同样可以论证前文中resolveInstanceMethod执行了两次的原因
经过上面的论证，我们了解到其实在慢速小子转发流程中，在methodSignatureForSelector 和 forwardInvocation方法之间还有一次动态方法决议，即苹果再次给的一个机会，如下图所示
总结
到目前为止，objc_msgSend发送消息的流程就分析完成了，在这里简单总结下
【快速查找流程】首先，在类的缓存cache中查找指定方法的实现【慢速查找流程】如果缓存中没有找到，则在类的方法列表中查找，如果还是没找到，则去父类链的缓存和方法列表中查找【动态方法决议】如果慢速查找还是没有找到时，第一次补救机会就是尝试一次动态方法决议，即重写resolveInstanceMethod/resolveClassMethod方法【消息转发】如果动态方法决议还是没有找到，则进行消息转发，消息转发中有两次补救机会：快速转发+慢速转发如果转发之后也没有，则程序直接报错崩溃
unrecognized selector sent to instance