面试的时候,面试官经常会问?如果调用的方法找不到时,在奔溃之前系统会给我们三次机会去挽救,避免APP
直接崩溃。这三次机会分别是什么?他们的顺序和流程是怎样的?今天我们就来分析一下这三次机会。
一、背景
上一篇文章中,我们分析了objc_msgSend
的慢速查找流程,知道了在lookUpImpOrForward
中,如果没有找到imp
时,会执行一次动态方法决议,即:
//没有找到方法实现,尝试一次方法解析
if (slowpath(behavior & LOOKUP_RESOLVER)) {
//动态方法决议的控制条件,表示流程只走一次
behavior ^= LOOKUP_RESOLVER;
return resolveMethod_locked(inst, sel, cls, behavior);
}
在Objc
中查看resolveMethod_locked
的源码:
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);
}
主要流程如下:
- 1、判断是否是元类:
如果是类,执行实例方法的动态方法决议resolveInstanceMethod
如果是元类,执行类方法的动态方法决议resolveClassMethod
,如果在元类中没有找到或者为空,则在元类的实例方法的动态方法决议resolveInstanceMethod
中查找,主要是因为类方法在元类中是实例方法,所以还需要查找元类中实例方法的动态方法决议 - 2、如果动态方法决议中,将其实现指向了其他方法,则继续查找指定的
imp
,即继续慢速查找lookUpImpOrForward
流程
二、resolveInstanceMethod
和resolveClassMethod
1、resolveInstanceMethod
针对实例方法调用,在快速-慢速查找均没有找到实例方法的实现时,我们有一次挽救的机会,即尝试一次动态方法决议,由于是实例方法,所以会走到resolveInstanceMethod
方法,我们先看下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
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));
}
}
}
主要流程如下:
- 1、在发送
resolveInstanceMethod
消息前,需要查找cls
类中是否有该方法的实现,即通过lookUpImpOrNil
方法又会进入lookUpImpOrForward
慢速查找流程查找resolveInstanceMethod
方法
如果没有,则直接返回;如果有,则发送resolveInstanceMethod
消息 - 2、再次慢速查找实例方法的实现,即通过
lookUpImpOrNil
方法又会进入lookUpImpOrForward
慢速查找流程查找实例方法
2、resolveClassMethod
类方法,与实例方法类似,同样可以通过重写resolveClassMethod
类方法来解决前文的崩溃问题。resolveClassMethod
的源码如下:
static void _class_resolveClassMethod(id inst, SEL sel, Class cls)
{
ASSERT(cls->isMetaClass());
SEL resolve_sel = @selector(resolveClassMethod:);
if (!lookUpImpOrNil(inst, resolve_sel, cls)) {
// Resolver not implemented.
return;
}
BOOL (*msg)(Class, SEL, SEL) = (typeof(msg))objc_msgSend;
bool resolved = msg(_class_getNonMetaClass(cls, inst), resolve_sel, 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 = 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 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));
}
}
}
通过源码我们可以发现,和resolveInstanceMethod
相比较,从判断类变成了判断元类,也即是查找的继承链不同,其他的都没有什么差别。
接下来我们通过一个案例,来验证下resolveInstanceMethod
和resolveClassMethod
在实际开发中如果运用和有没有其它的问题。
首先新建工程,新建一个LPPerson
类,分别定义一个实例方法和类方法,并在main
中调用,具体代码如下:
@interface LPPerson : NSObject
- (void)sayHello;
+ (void)sayHi;
@end
@implementation LPPerson
@end
int main(int argc, const char * argv[]) {
@autoreleasepool {
// insert code here...
LPPerson *person = [LPPerson alloc];
[person sayHello];
//[LPPerson sayHi];
}
return 0;
}
运行工程,查看结果:
直接崩溃,并报出unrecognized selector sent to instance
的错误。
接下来我们就尝试使用动态方法决议来阻止它报错和崩溃,因为sayHello
是实例方法,所以我们在LPPerson.m
文件中实现resolveInstanceMethod
,并重新指向另一个方法replaceInstance
。
@implementation LPPerson
- (void)replaceInstance{
NSLog(@"%s",__func__);
}
+ (BOOL)resolveInstanceMethod:(SEL)sel{
if (sel == @selector(sayHello)) {
NSLog(@"%@ 来了",NSStringFromSelector(sel));
IMP imp = class_getMethodImplementation(self, @selector(replaceInstance));
Method sayMMethod = class_getInstanceMethod(self, @selector(replaceInstance));
const char *type = method_getTypeEncoding(sayMMethod);
return class_addMethod(self, sel, imp, type);
}
return [super resolveInstanceMethod:sel];
}
@end
再次运行:
不崩溃了,并且走到了我们让它去的地方replaceInstance
中。
接下来我们打开sayHi
的注释,再次运行发现还是会崩溃。
类似的,因为sayHi
是类方法,所以我们需要重写resolveClassMethod
来解决崩溃的问题:
+ (void)replaceClass{
NSLog(@"%s",__func__);
}
+ (BOOL)resolveClassMethod:(SEL)sel{
if (sel == @selector(sayHi)) {
NSLog(@"%@ 来了",NSStringFromSelector(sel));
IMP imp = class_getMethodImplementation(objc_getMetaClass("LPPerson"), @selector(replaceClass));
Method sayMMethod = class_getInstanceMethod(objc_getMetaClass("LPPerson"), @selector(replaceClass));
const char *type = method_getTypeEncoding(sayMMethod);
return class_addMethod(objc_getMetaClass("LPPerson"), sel, imp, type);
}
return [super resolveInstanceMethod:sel];
}
注意:
resolveClassMethod
是针对类方法的动态决议,传入的cls
不再是类,而是元类,可以通过objc_getMetaClass
方法获取类的元类。其原理是因为类方法在元类中也是实例方法。
再次运行,发现也不崩溃了。
实际开发中,我们不可能说每个类都去实现resolveInstanceMethod
和resolveClassMethod方式
,来避免,有没有办法可以优化呢?这个时候你想到了什么?类别对吗?OC
中NSObject
是所有类的根类,我们直接创建一个NSObject
的分类来实现方法动态决议不就可以了吗?我们来验证下:
+ (BOOL)resolveInstanceMethod:(SEL)sel{
NSLog(@"%@ 来了",NSStringFromSelector(sel));
if (sel == @selector(sayHello)) {
NSLog(@"%@ 来了",NSStringFromSelector(sel));
IMP imp = class_getMethodImplementation(self, @selector(replaceInstance));
Method sayMMethod = class_getInstanceMethod(self, @selector(replaceInstance));
const char *type = method_getTypeEncoding(sayMMethod);
return class_addMethod(self, sel, imp, type);
}
else if (sel == @selector(sayHi)) {
IMP imp = class_getMethodImplementation(objc_getMetaClass("LPPerson"), @selector(replaceClass));
Method sayMMethod = class_getInstanceMethod(objc_getMetaClass("LPPerson"), @selector(replaceClass));
const char *type = method_getTypeEncoding(sayMMethod);
return class_addMethod(objc_getMetaClass("LPPerson"), sel, imp, type);
}
return NO;
}
运行:
没毛病,可以解决。
这里注意,我们只是实现了
resolveInstanceMethod
,在resolveInstanceMethod
处理类方法也是可以的,这就可以验证我们阐述为什么调用了类方法动态方法决议,还要调用对象方法动态方法决议,其根本原因还是类方法在元类中的实例方法。
但是这样就真的好吗?如果你有1000个方法要处理,不是要写1000个判断?而且系统的方法可能也会被修改。当然针对这一点,也是可以优化的,即我们可以针对自定义类中方法统一方法名的前缀,根据前缀来判断是否是自定义方法,然后统一处理自定义方法,例如可以在崩溃前pop
到首页,主要是用于app线上防崩溃的处理,提升用户的体验。
但是这样还是不够好,接下来我们就来讲一下更好的方式:消息转发
三、消息转发
在慢速查找的流程中,我们了解到,如果快速
+慢速
没有找到方法实现,动态方法决议也不行,就使用消息转发,但是,我们找遍了源码也没有发现消息转发的相关源码,可以通过instrumentObjcMessageSends
方式来了解,方法调用崩溃前都走了哪些方法:
1、instrumentObjcMessageSends
我们在lookUpImpOrForward
源码中发现:
....
for (unsigned attempts = unreasonableClassCount();;) {
// curClass method list.
Method meth = getMethodNoSuper_nolock(curClass, sel);
if (meth) {
imp = meth->imp;
goto done;
}
...
done:
log_and_fill_cache(cls, imp, sel, inst, curClass);
runtimeLock.unlock();
...
如果有找到imp
,就会goto
到done
,done
中会执行log_and_fill_cache
方法是答应并存放到cache
中,查看log_and_fill_cache
源码:
static void
log_and_fill_cache(Class cls, IMP imp, SEL sel, id receiver, Class implementer)
{
#if SUPPORT_MESSAGE_LOGGING
if (slowpath(objcMsgLogEnabled && implementer)) {
bool cacheIt = logMessageSend(implementer->isMetaClass(),
cls->nameForLogging(),
implementer->nameForLogging(),
sel);
if (!cacheIt) return;
}
#endif
cache_fill(cls, sel, imp, receiver);
}
这里发现objcMsgLogEnabled
必须有yes
才可以打印,我们再点击进入logMessageSend
中,
bool logMessageSend(bool isClassMethod,
const char *objectsClass,
const char *implementingClass,
SEL selector)
{
char buf[ 1024 ];
// Create/open the log file
if (objcMsgLogFD == (-1))
{
snprintf (buf, sizeof(buf), "/tmp/msgSends-%d", (int) getpid ());
objcMsgLogFD = secure_open (buf, O_WRONLY | O_CREAT, geteuid());
if (objcMsgLogFD < 0) {
// no log file - disable logging
objcMsgLogEnabled = false;
objcMsgLogFD = -1;
return true;
}
}
// Make the log entry
snprintf(buf, sizeof(buf), "%c %s %s %s\n",
isClassMethod ? '+' : '-',
objectsClass,
implementingClass,
sel_getName(selector));
objcMsgLogLock.lock();
write (objcMsgLogFD, buf, strlen(buf));
objcMsgLogLock.unlock();
// Tell caller to not cache the method
return false;
}
搜索objcMsgLogEnabled
,发现是在instrumentObjcMessageSends
对objcMsgLogEnabled
的状态进行控制。我们只要在instrumentObjcMessageSends
将objcMsgLogEnabled
置为yes
即可。打印的日志文件存放在/tmp/msgSends/
中。因为instrumentObjcMessageSends
是在源码中,我们要在外部调用,就需要使用extern
关键字。
新建mac
工程,创建LPPerson
,在main
中修改代码:
extern void instrumentObjcMessageSends(BOOL flag);
int main(int argc, const char * argv[]) {
@autoreleasepool {
// insert code here...
LPPerson *person = [LPPerson alloc];
instrumentObjcMessageSends(YES);
[person sayHello];
instrumentObjcMessageSends(NO);
}
return 0;
}
需要注意的是不能在源码工程中使用
instrumentObjcMessageSends
,在源码中使用不会将方法调用流程写进文件中
然后先运行,然后进入/tmp/msgSends/
文件中,可以发现,多了一个msgSends
开头的文件:
我们双击打开:
这里我们发现,在执行了
resolveInstanceMethod
还执行了forwardingTargetForSelector
和methodSignatureForSelector
,也就是我们常说的消息转发,消息转发也分为快速转发和慢速转发,接下来我们就具体分析下:
2、快速转发流程:forwardingTargetForSelector
苹果官方对其的定义是该方法为一个实例方法、且需要返回一个处理方法的对象。
通过上面日志文件,我们知道forwardingTargetForSelector
的消息接受者是LPPerson
,所以我们可以在LPPerson
实现forwardingTargetForSelector
方法:
- (id)forwardingTargetForSelector:(SEL)aSelector{
NSLog(@"%s - %@",__func__,NSStringFromSelector(aSelector));
return [super forwardingTargetForSelector:aSelector];
}
再次运行,我们发现是在崩溃之前走了这里的并打印了sayHello
。
2020-10-11 15:41:27.250032+0800 002-instrumentObjcMessageSends[36923:1077690] -[LPPerson forwardingTargetForSelector:] - sayHello
所以我们可以按照官方的定义,指定一个新的接收者去处理。新建LPStudent
并实现sayHello
方法
@implementation LPStudent
- (void)sayHello{
NSLog(@"%s",__func__);
}
然后在forwardingTargetForSelector
中修改新的处理者为LPStudent
,
- (id)forwardingTargetForSelector:(SEL)aSelector{
NSLog(@"%s - %@",__func__,NSStringFromSelector(aSelector));
return [LPStudent alloc];
}
再次运行:
2020-10-11 15:45:35.698400+0800 002-instrumentObjcMessageSends[36978:1080659] -[LPPerson forwardingTargetForSelector:] - sayHello
2020-10-11 15:45:35.699273+0800 002-instrumentObjcMessageSends[36978:1080659] -[LPStudent sayHello]
2020-10-11 15:45:35.699617+0800 002-instrumentObjcMessageSends[36978:1080659] Hello, World!
可以看到,完美处理,让LPStudent成功接盘。同理,在实际开发中,我们也可以在这个地方处理崩溃问题,只需要新建一个消息接受者,然后利用RunTime动态的添加imp即可完成。
3、慢速转发:methodSignatureForSelector
苹果官方的定义是:该方法为一个实例方法、且必须调用forwardInvocation:
方法并返回NSInvocation
对象。所以通常都是methodSignatureForSelector
+ forwardInvocation
一起使用的。同样的,我们在LPPerson
中实现methodSignatureForSelector
和forwardInvocation
并且注释掉forwardingTargetForSelector
方法。
- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector {
NSLog(@"%s -- %@",__func__,NSStringFromSelector(aSelector));
return [NSMethodSignature signatureWithObjCTypes:"v@:"];
}
// 不处理方法的实现
- (void)forwardInvocation:(NSInvocation *)anInvocation {
NSLog(@"%s -- %@",__func__, anInvocation);
NSLog(@"%@ -- %s",anInvocation.target, anInvocation.selector);
}
运行工程,可以看到也没有崩溃。
2020-10-11 15:50:38.223973+0800 002-instrumentObjcMessageSends[37007:1082598] -[LPPerson methodSignatureForSelector:] -- sayHello
2020-10-11 15:50:38.224995+0800 002-instrumentObjcMessageSends[37007:1082598] -[LPPerson forwardInvocation:] -- <NSInvocation: 0x10044fbe0>
2020-10-11 15:50:38.225294+0800 002-instrumentObjcMessageSends[37007:1082598] <LPPerson: 0x100513e20> -- sayHello
2020-10-11 15:50:38.225630+0800 002-instrumentObjcMessageSends[37007:1082598] Hello, World!
接下来,我们在forwardInvocation
中来处理实现问题:
- (void)forwardInvocation:(NSInvocation *)anInvocation {
NSLog(@"%s -- %@",__func__, anInvocation);
NSLog(@"%@ -- %s",anInvocation.target, anInvocation.selector);
anInvocation.target = [LPStudent alloc];//LPStudent中实现了sayHello方法
[anInvocation invoke];
}
在运行发现已经成功调用LPStudent
中方法实现了。
2020-10-11 15:55:27.645633+0800 002-instrumentObjcMessageSends[37139:1085566] -[LPPerson methodSignatureForSelector:] -- sayHello
2020-10-11 15:55:27.647003+0800 002-instrumentObjcMessageSends[37139:1085566] -[LPPerson forwardInvocation:] -- <NSInvocation: 0x100505840>
2020-10-11 15:55:27.647476+0800 002-instrumentObjcMessageSends[37139:1085566] <LPPerson: 0x101808a30> -- sayHello
2020-10-11 15:55:27.647878+0800 002-instrumentObjcMessageSends[37139:1085566] -[LPStudent sayHello]
2020-10-11 15:55:27.648289+0800 002-instrumentObjcMessageSends[37139:1085566] Hello, World!
由此可见实现了methodSignatureForSelector:
和forwardInvocation:
这两个实例方法后也能解决方法无实现的问题,而且这个两个方法必须同时实现。
快速转发和慢速转发的区别:
- 快速转发:
forwardingTargetForSelector
可以修改方法的处理的target - 慢速转发:
methodSignatureForSelector
不仅可以修改方法的处理的target
,可以修改selector
Q:resolveInstanceMethod
为什么为执行两次?
来到我们resolveInstanceMethod
的源码中,我们在IMP imp = lookUpImpOrNil(inst, sel, cls);
行代码添加上断点
在执行完sayHello的打印后,我们再观察现在的堆栈信息:
发现这次是因为慢速查找没有找到对应的imp,所以进行了动态方法决议。然后我们再继续执行直到第二次打印,再打印当前堆栈信息:
可以看到这次,是在慢速消息转发之后再次进行的动态方法决议。
消息转发流程图:
总结:
objc_msgSend
发送消息的流程就分析完成了,在这里简单总结下
-【快速查找流程】首先,在类的缓存cache中查找指定方法的实现
-【慢速查找流程】如果缓存中没有找到,则在类的方法列表中查找,如果还是没找到,则去父类链的缓存和方法列表中查找
-【动态方法决议】如果慢速查找还是没有找到时,第一次补救机会就是尝试一次动态方法决议,即重写resolveInstanceMethod
/resolveClassMethod
方法
-【消息转发】如果动态方法决议还是没有找到,则进行消息转发,消息转发中有两次补救机会:快速转发+慢速转发
- 如果转发之后也没有,则程序直接报错崩溃
unrecognized selector sent to instance
所以篇前所说的三次机会即:
- 动态方法决议:
resolveInstanceMethod
/resolveClassMethod
- 快速消息转发:
forwardingTargetForSelector
- 慢速消息转发:
methodSignatureForSelector + forwardInvocation
觉得不错记得点赞哦!听说看完点赞的人逢考必过,逢奖必中。ღ( ´・ᴗ・` )比心