第十一节课 消息转发
instrumentObjcMessageSends辅助分析方法的介绍
作用:打印出指定区域内调用的所有的方法、并往指定路径下生成文件
使用方式:
// 外部引用定义
extern void instrumentObjcMessageSends(BOOL flag);
//使用区域,将想要查找的方法用instrumentObjcMessageSends圈起来
//开始监听传递参数为YES,结束监听传递参数为NO
LGPerson *person = [LGPerson alloc];
instrumentObjcMessageSends(YES);
[person sayNB];
instrumentObjcMessageSends(NO);
查看输出结果:
此方法将指定函数开始与结束之间调用的函数全部以文件的形式输出,存储路径为:/tmp/msgSends,找到msgSends-xxxx的文件,此文件内就是全部调用的函数了。
消息转发流程
快速转发
通过上面的msgSends文件我们可以看到了熟悉的resolveInstanceMethod,这个方法是动态方法决议,看到下一个方法forwardingTargetForSelector就变成了探究最新的线索。
通过官方文档可以得知forwardingTargetForSelector为快速转发流程的一个执行者,如果使用此方法对某一个函数进行重定向,那么将非常的有效。forwardingTargetForSelector会返回一个对象,成为未识别的消息的第一继承者,即方法的重定向。如果你想要更多的操作自由,请用forwardInvocation进行操作。
代码验证
// 快速转发
- (id)forwardingTargetForSelector:(SEL)aSelector{
NSLog(@"%s - %@",__func__,NSStringFromSelector(aSelector));
return [super methodSignatureForSelector:aSelector];
}
//PS:如果是类方法用+,对象方法用-
首先,我们使用了系统的methodSignatureForSelector,以及aSelector参数,发现还是崩溃了,但是崩溃前打印了-[LGPerson forwardingTargetForSelector:] - sayHello
,这证明了这个方向是可以的。
并且官方文档说了可以进行方法的重定向,我们就将return
返回的参数换成实现了方法的LGStudent
的对象return [LGStudent alloc];
再次运行发现不崩溃了,并正常打印输出了
这个时候其实有一个疑惑,为什么明明实现了方法,不在LGPerson实现,而是通过快速转发到LGStudent重定向来实现
我们先回顾下整个流程
// sel -> imp
// objc_msgSend -> cache
// 慢速查找 -> methodlist
// 动态方法决议(补救的机会)
// 找一个背锅侠,也就是我们的LGStudent
如果LGStudent
也没有我们想要的方法,那我们只能继续往下看,发现走到
methodSignatureForSelector
慢慢的进行转发了
接下来我们就自己实践一下吧
- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector{
NSLog(@"%s - %@",__func__,NSStringFromSelector(aSelector));
return [super methodSignatureForSelector:aSelector];
}
运行后发现还是报错的,因为之前写的背锅侠的原因,将LGStudent
当成背锅侠,背锅侠又走一遍自身的流程之后没有背锅侠了,而我们新写的methodSignatureForSelector
方法是属于LGPerson
的,所以我们要把之前写的背锅侠去掉,当做什么事情都没有发生。
虽然还是崩溃的,但是我们发现打印日志已经显示走到了我们的方法当中
这个时候就需要去看看官方文档中怎么描述这个方法了
可以看到,文档中写道这个方法必须搭配NSInvocation对象
,且一定要对签名做处理。
所以我们先加上NSInvocation
的方法,再修改一下methodSignatureForSelector
的签名
- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector{
NSLog(@"%s - %@",__func__,NSStringFromSelector(aSelector));
if (aSelector == @selector(sayHello)) {
return [NSMethodSignature signatureWithObjCTypes:"v@:@"];
}
return [super methodSignatureForSelector:aSelector];
}
- (void)forwardInvocation:(NSInvocation *)anInvocation{
}
再次运行,没有崩溃,而且下一句的输出Hello, World!
也打印了出来
但是我们的sayHello呢???
这个就要从苹果的方法系统层面来讲了,我们所有的方法,在系统来讲就是消息、事务。这个事务是可做可不做的,但是会一直保存在anInvocation
中。如果我们需要的话,可以从anInvocation当中去获取,如果我们不需要的话就当做什么事情都没发生。
下面我们来验证下
- (void)forwardInvocation:(NSInvocation *)anInvocation{
NSLog(@"%@ - %@",anInvocation.target,NSStringFromSelector(anInvocation.selector));
}
了解了上述的方法,我们是不是就可以应用到实际当中了呢?当然,只要我们处理得当,就不会再有unrecognized selector sent to instance
报错了哟~但是、但是,想要走到这一步,我们也看到了,要经历的过程比我们想象的多很多,这就造成了资源的浪费。所以,还要从根本上解决问题,而这个方法只是做一个防护,或者特殊处理,起到一个锦上添花的作用。
hoper反汇编
我们通过上面的两个方法解决了找不到方法崩溃的问题,但是大家有没有好奇到底是怎么样得到这两个方法的呢?通过bt打印具体崩溃原因,可以看到一个熟悉的名称:CoreFoundation
,但是由于苹果并未完全开源这个库,我们怎么去分析呢?这就需要使用一个外部工具Hopper,同时找到一个CoreFoundation的可执行文件~ 下面的链接都给大家准备好了。
下载链接: 链接: https://pan.baidu.com/s/1HEMDK8yif-b8F48dacJutw 提取码: khsn
将可执行文件拖入Hopper我们就可以看到反汇编后的代码,但是并不是所有的地方都可以看到哦。
我们根据上图的报错信息,全局搜索___forwarding_prep_0___
进入___forwarding_prep_0___
后我们发下面又走到了____forwarding___
,继续进入,我们看了一个熟悉的方法
看到这里的判断,大家就都明白了吧,这里内部判断了一下,当前class是否能响应forwardingTargetForSelector:
,不能响应就 goto loc_64a67
,能响应就往下走。
到这里,我们的目的就已经达到了,获取到了forwardingTargetForSelector
这个关键方法。继续往下看
至此,我们就全部看到了慢速转发流程的底层执行的逻辑。