概要
runtime是Objective-C的动态机制。runtime执行的是编译后的代码,这时它可以动态加载对象、添加方法、修改属性、传递消息等,具体过程是:Objective-C中,对象调用方法时,如[self.tableView reloadData];
,经历了两个阶段:编译阶段,运行阶段
- 编译阶段
编译器会把[self.tableView reloadData];
这行代码翻译成objc_msgSend(self.tableView, @selector(reloadData))
, 把消息发送给self.tableView
- 运行阶段
接收者self.tableView
会响应这个消息,期间可能会直接执行、转发消息,也可能会找不到方法导致程序崩溃
objc_msgSend
函数会依据接收者与选择子的类型来调用适当的方法。该方法需要在接收者所属的类中搜寻其“方法列表”,如果能找到与选择子名称相符的方法,就跳至其实现代码。若是找不到,那就沿着继承体系继续向上查找,等找到合适的方法之后再跳转。如果最终还是找不到相符的方法,那就执行“消息转发”(message forwarding)机制,程序员可经由此过程告诉对象应该如何处理未知消息。
消息转发机制概要
消息转发分为两大阶段:
- 动态方法解析(dynamic method resolution):
- 完整的消息转发机制(full forwarding mechanism):
动态方法解析
对象在收到无法解读的消息后,首先将调用其所属类的下列类方法:
+ (BOOL)resolveInstanceMethod:(SEL)selector
该方法表示这个类是否能新增一个实例方法用以处理此选择子。在继续往下执行转发机制之前,本类有机会新增一个处理此选择子的方法。若尚未实现的方法是类方法,则runtime会调用另一个方法:resolveClassMethod:
使用这种方法的前提是:相关的实现代码已经写好,只等着运行的时候动态插在类里面就可以了。此方案常用来实现@dynamic属性。
- 使用
resolveInstanceMethod:
来实现@dynamic属性:id autoDictionaryGetter(id self, SEL _cmd); void autoDictionarySetter(id self, SEL _cmd, id value); + (BOOL)resolveInstanceMethod:(SEL)sel { NSString *selectorString = NSStringFromSelector(sel);//首先将selector转换为字符串,然后检查其是否表示设置方法 if (/* selector is from a @dynamic property*/) { if ([selectorString hasPrefix:@"set"]) { class_addMethod(self, sel, (IMP)autoDictionaryGetter, "v@:@"); } else { class_addMethod(self, sel, (IMP)autoDictionaryGetter, "@@:"); } return YES; } return [super resolveInstanceMethod:sel]; }
- 备援接收者
当前接收者还有第二次机会处理未知的选择子,在这一步中,运行期系统会问它:能不能把这条消息转给其他接收者来处理。对应的处理方法如下:
- (id)forwardingTargetForSelector:(SEL)selector
方法参数代表未知的选择子,若当前接收者能找到备援对象,则将其返回,若找不到,就返回nil。在一个对象内部,可能还有一系列其他对象,该对象可经由此方法将能够处理某选择子的相关内部对象返回,这样的话,在外界看来,好像是该对象亲自处理了这些消息似的。
完整的消息转发
如果转发算法已经来到这一步的话,唯一能做的就是启用完整的消息转发机制。
首先创建NSInvocation
对象,把尚未处理的那条消息相关的全部细节都封装于其中。此对象包含选择子、目标(target)以及参数。在触发NSInvocation对象时,“消息派发系统”亲自出马,把消息指派给目标对象。此步骤会调用下列方法来转发消息:
- (void)forwardInvocation:(NSInvocation *)incocation
这个方法可以实现得很简单:只需要改变调用目标,使消息在新目标上得以调用即可。然而这样实现出来的方法与“备援接收者”方案所实现的方法等效,所以很少有人采用这么简单的实现方式。比较有用的实现方式:在触发消息之前,先以某种方式改变消息内容,比如追加另外一个参数,或是改换选择子等。
消息转发全流程
图1为消息转发机制处理消息的各个步骤:
接收者在每一步中均有机会处理消息。步骤越往后,处理消息的代价就越大。最好能在第一步就处理完,这样的话,运行期系统就可以将此方法缓存起来了。如果这个类的实例稍后还收到同名选择子,那么根本无须启动消息转发流程。若想在第三步里把消息转给备援的接收者,那还不如把转发操作提前到第二步。因为第三步只是修改了调用目标,这项改动放在第二步执行会更简单,不然的话,还得创建并处理完整的NSInvocation。