Runtime 是什么?
Runtime 是 Objective-C 区别 C 语言等静态语言的一个非常重要的特性。对于 C 语言,函数的调用会在编译期就已经决定好,在编译完成后直接顺序运行。但是 OC 是一门动态语言,函数调用变成了消息转发,在编译阶段是不知道要调用哪个函数。所以 Runtime 无非就是去解决如何在运行时期找到调用方法这样的问题。 对于实例变量:
instance -> class -> method -> SEL -> IMP -> 函数方法
实例对象中存放 isa 指针以及实例变量,有 isa 指针可以找到实例对象所属的类对象,类中存放着方法列表,在这个方法列表中 SEL 最为 key,IMP 作为 value。在编译时期,根据方法名字会生成一个唯一的 Int 标识,这个标识就是 SEL,IMP就是函数指针指向最终函数的实现。整个 Runtime 的核心就是 objc_msgSend 函数,通过给类发送 SEL 传递消息,找到 IMP 获取最终的实现。
下图描述了对象的内存布局
类中的 super_class 指针可以追溯整个继承链。向一个对象发送消息时,Runtime 会根据实例对象的 isa 指针找到其所属的类,并自底向上至根类(NSObject)中寻找 SEL 所对应的方法,找到后就运行整个方法。
metaClass 是元类,也有 isa 指针,super_class 指针。其中保存了累方法列表。
#import <objc/runtime.h>
SEL 与 IMP
SEL 可以将其理解为方法的 ID,结构如下:
typedef struct objc_selector *SEL;
struct objc_selector {
char *name; OBJC2_UNAVAILABLE;
char *types; OBJC2_UNAVAILABLE;
};
IMP 可以理解为函数指针,指定了最终的实现。 SEL 与 IMP 的关系非常类似于 HashTable 中 key 与 value 的关系,OC 中不支持函数重载的原因就是因为一个类的方法列表中不能存在两个相同的 SEL。但是多个方法可以在不同的类中有一个相同的 SEL,不同的类的实例对象执行相同的 SEL 时,会在各自的方法列表中去根据 SEL 去寻找自己对应的 IMP。这使得 OC 可以支持函数重写。
消息传递机制
- objc_msgSend函数的消息处理过程
- 不涵盖消息cache机制
- 需要对Objective-C runtime有一定的了解
objc_msgSend 函数的调用流程:
- 检测 SEL 是否应该被忽略;
- 检测发送的 target 是否为 nil,如果是则忽略该消息;
- 当调用类方法时,通过 isa 指针找到实例对应的 metaclass 并且在其中的缓存方法列表以及方法列表中进行查询,如果找不到则根据 super_class 指针在父类中查询,直至根类(NSObject)
- 如果还没有找到就进入消息动态解析过程。
当一个对象 sender 调用代码 [receuver message];
的时候,实际上市调用了 runtime 的objc_msgSend
函数。 所以 OC 的方法调用不是 C 语言那样,能按照地址直接取,而是经过了一系列过程。这样使得 runtime 可以在接收消息后进行特殊处理。这样就是 OC 具有一些特性,比如:给 nil 发消息不崩溃,给类添加方法和消息转发。也正是因为每一次调用方法的时候实际上是调用了一些 runtime 的消息处理函数,OC 的方法调用相比 C 来说会相对较慢。但 OC 也通过引入 cache 机制来很大程度上的克服了这个缺点。下面我们就从一个对象 sender 调用代码[receiver message];
这个情景开始,了解消息传递的过程。
首先这行代码会被改写成objc_msgSend(self,_cmd);
, 这是一个 runtime 的函数, 其原型为:
id objc_msgSend(id self,SEL op, ...)
slef 与 _cmd 是两个编辑器会自动添加的隐藏参数, self 是一个指向接收指针的对象, _cmd为方法选择器。这个函数的实现为汇编版本, 苹果开源项目中共有6种对不同平台的汇编实现, 本节选取其在 x86_64实现的文件 objc-msg-x86_64.s
#objc-msg-x86_64.s#
ENTRY _objc_msgSend
// ...
GetIsaFast NORMAL // r11 = self->isa
CacheLookup NORMAL // calls IMP on success
// ...
// cache miss: go search the method lists
LCacheMiss:
// isa still in r11
MethodTableLookup %a1, %a2 // r11 = IMP
cmp %r11, %r11 // set eq (nonstret) for forwarding
jmp *%r11 // goto *imp
END_ENTRY _objc_msgSend
可以看到其调用了GetIsaFast
,由于self是id类型,而id的原型为struct objc_object *id;
,所以需要通过id的isa指针获取其所属的类对象,之后调用CacheLookup
在获取到的类中根据传入的_cmd查找对应方法实现的IMP指针。这两个函数的实现均在同一个文件下,因为暂时我还不了解cache的机制,所以这部分先不深入讨论。CacheLookup函数在命中后会直接调用相应的IMP方法,这就完成了方法的调用。如果cache落空,则跳转至LCacheMiss标签,调用MethodTableLookup方法,这个方法将IMP的值存在r11寄存器里,之后jmp *%r11
从IMP开始执行,完成方法调用。MethodTableLookup函数实现如下,
.macro MethodTableLookup
MESSENGER_END_SLOW
SaveRegisters
// _class_lookupMethodAndLoadCache3(receiver, selector, class)
movq $0, %a1
movq $1, %a2
movq %r11, %a3
call __class_lookupMethodAndLoadCache3
// IMP is now in %rax
movq %rax, %r11
RestoreRegisters
.endmacro
可以看到其实际上将receiver(即self), selector(即_cmd),class(即self->isa)传递给了_class_lookupMethodAndLoadCache3这个函数,查看该函数的实现后,欢迎重新回到C语言的世界。
#objc-class-old.mm#
IMP _class_lookupMethodAndLoadCache3(id obj, SEL sel, Class cls)
{
return lookUpImpOrForward(cls, sel, obj,
YES/*initialize*/, NO/*cache*/, YES/*resolver*/);
}
这个函数进一步调用了lookUpImpOrForward
,并把cache标签置为NO,意味着忽略第一次不加锁的cache查找。这个函数的返回值要么是对应方法的IMP指针,要么是一个__objc_msgForward_impcache汇编方法的入口,后者对应着消息转发机制,即如果在该对象及其继承链上方的的对象都找不到选择器_cmd的响应方法的话,就调用消息转发函数尝试将该消息转发给其他对象。下面是lookUpImpOrForward的实现,由于代码过长,注释将写在代码之中。
#objc-class-old.mm#
IMP lookUpImpOrForward(Class cls, SEL sel, id inst,
bool initialize, bool cache, bool resolver)
{
Class curClass; // 当前类对象
IMP methodPC = nil; // 用于保存最终查找到的函数指针并返回
Method meth; // 定义了方法的一个结构体,可通过meth->imp获取函数指针
bool triedResolver = NO; // 方法解析的标志变量
methodListLock.assertUnlocked();
// 不加锁地查找cache,由于之前cache落空,所以肯定找不到,就忽略
// Optimistic cache lookup
if (cache) {
methodPC = _cache_getImp(cls, sel);
if (methodPC) return methodPC;
}
// Check for freed class
if (cls == _class_getFreedObjectClass())
return (IMP) _freedHandler;
// 确保该类已被初始化,如果没有就调用类方法+initialize,这里也说明了为什么OC的类会在
// 第一次接收消息后调用+initialize进行初始化,相反的,如果想要代码在类注册runtime的
// 时候就运行,可以将代码写在+load方法里
// Check for +initialize
if (initialize && !cls->isInitialized()) {
_class_initialize (_class_getNonMetaClass(cls, inst));
// If sel == initialize, _class_initialize will send +initialize and
// then the messenger will send +initialize again after this
// procedure finishes. Of course, if this is not being called
// from the messenger then it won't happen. 2778172
}
// The lock is held to make method-lookup + cache-fill atomic
// with respect to method addition. Otherwise, a category could
// be added but ignored indefinitely because the cache was re-filled
// with the old value after the cache flush on behalf of the category.
// 上述英文已述:对消息查找和填充cache加锁,由于填充cache是写操作,所以需要对其
// 加锁以免加入了category之后的cache被旧的cache冲掉,导致category失效。
// 实际上,如果cache没有命中,但在方法列表中找到了对应的IMP,函数也是会进行cache
// 写入操作。
retry:
methodListLock.lock();
// 在开启GC选项后忽略retain, release等方法(猜测GC 是 Garbage Collection)
// 这也体现了OC的灵活性,runtime完全有权力忽略一些方法
if (ignoreSelector(sel)) {
methodPC = _cache_addIgnoredEntry(cls, sel);
goto done;
}
// 在加锁的状态下再查找一次cache,如果命中就直接返回IMP指针
// 个人认为再次在加锁状态下查找是因为在与上次查找的间隙中可能
// 有其他类填充了这个cache
methodPC = _cache_getImp(cls, sel);
if (methodPC) goto done;
// 如果还是没有命中的话就查找该类的方法列表
meth = _class_getMethodNoSuper_nolock(cls, sel);
if (meth) {
// 命中,填充cache,返回IMP指针
log_and_fill_cache(cls, cls, meth, sel);
methodPC = method_getImplementation(meth);
goto done;
}
// 没有命中,沿着class的继承链向上查找,最后找到的是NSObject(NSProxy除外)
// 而NSObject的superclass为nil
curClass = cls;
while ((curClass = curClass->superclass)) {
// 尝试从超类的cache中加载
meth = _cache_getMethod(curClass, sel, _objc_msgForward_impcache);
if (meth) {
// 如果不是forward
if (meth != (Method)1) {
// 在超类中找到IMP,在当前类中进行cache
log_and_fill_cache(cls, curClass, meth, sel);
methodPC = method_getImplementation(meth);
goto done;
}
else {
// 找到forward,跳出循环
// Found a forward:: entry in a superclass.
// Stop searching, but don't cache yet; call method
// resolver for this class first.
break;
}
}
// 超类cache没有命中,从超类的方法列表寻找
meth = _class_getMethodNoSuper_nolock(curClass, sel);
if (meth) {
log_and_fill_cache(cls, curClass, meth, sel);
methodPC = method_getImplementation(meth);
goto done;
}
}
// 使用方法解析并再尝试一次
if (resolver && !triedResolver) {
methodListLock.unlock();
_class_resolveMethod(cls, sel, inst);
triedResolver = YES;
goto retry;
}
// 没有找到IMP指针,方法解析也没有用,使用消息转发,并将其填充入cache
_cache_addForwardEntry(cls, sel);
methodPC = _objc_msgForward_impcache;
done:
methodListLock.unlock();
// paranoia: look for ignored selectors with non-ignored implementations
assert(!(ignoreSelector(sel) && methodPC != (IMP)&_objc_ignored_method));
return methodPC;
}
我们可以看到每一个类都维护了一个cache,在一个对象调用runtime的objc_msgSend函数后,runtime在接收者所属的类的cache中查找与_cmd所对应的IMP,如果没有命中就寻找当前类的方法列表,再找不到就跳入while循环寻找超类的cache和方法列表,如果这些方法都失效,就调用_class_resolveMethod
查找正在插入这个类的方法,之后再重新尝试整一个流程,如果最后还是没能找到一个对应的IMP,则调用消息转发机制。
动态消息解析
如下用于描述动态消息解析的流程:
- 1.通过 resolveInstanceMethod 得知方法是否为动态添加,YES则通过 class_addMethod 动态添加方法,处理消息,否则进入下一步。dynamic 属性就与这个过程有关,当一个属性声明为 dynamic 时 就是告诉编译器:开发者一定会添加 setter/getter 的实现,而编译时不用自动生成。
- 2.这步会进入 forwardingTargetForSelector 用于指定哪个对象来响应消息。如果返回nil 则进入第三步。这种方式把消息原封不动地转发给目标对象,有着比较高的效率。如果不能自己的类里面找到替代方法,可以重载这个方法,然后把消息转给其他的对象。
- 3.这步调用 methodSignatureForSelector 进行方法签名,这可以将函数的参数类型和返回值封装。如果返回 nil 说明消息无法处理并报错
unrecognized selector sent to instance
,如果返回 methodSignature,则进入 forwardInvocation ,在这里可以修改实现方法,修改响应对象等,如果方法调用成功,则结束。如果依然不能正确响应消息,则报错unrecognized selector sent to instance
.
可以利用 2、3 中的步骤实现对接受消息对象的转移,可以实现“多重继承”的效果。
参考资料
- http://yulingtianxia.com/blog/2014/11/05/objective-c-runtime/
- http://www.cocoawithlove.com/2010/01/what-is-meta-class-in-objective-c.html
- https://github.com/opensource-apple/objc4