• Objective-C Runtime
    • Runtime 是什么？
    • SEL 与 IMP
    • 消息传递机制
    • 动态消息解析
      • 参考资料

    Objective-C Runtime

    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 再获取最终的实现。如下的这张图描述了对象的内存布局。

    Objective-C Runtime - 图1

    类中的 super_class 指针可以追溯整个继承链。向一个对象发送消息时，Runtime 会根据实例对象的 isa 指针找到其所属的类，并自底向上直至根类(NSObject)中 去寻找 SEL 所对应的方法，找到后就运行整个方法。

    metaClass是元类，也有 isa 指针、super_class 指针。其中保存了类方法列表。

    如下是 objc/runtime.h 中定义的类的结构:

    1. struct objc_class {
    2.     Class isa  OBJC_ISA_AVAILABILITY;
    4. #if !__OBJC2__
    5.     Class super_class                                        OBJC2_UNAVAILABLE;
    6.     const char *name                                         OBJC2_UNAVAILABLE;
    7.     long version                                             OBJC2_UNAVAILABLE;
    8.     long info                                                OBJC2_UNAVAILABLE;
    9.     long instance_size                                       OBJC2_UNAVAILABLE;
    10.     struct objc_ivar_list *ivars                             OBJC2_UNAVAILABLE; // 成员变量地址列表
    11.     struct objc_method_list **methodLists                    OBJC2_UNAVAILABLE; // 方法地址列表
    12.     struct objc_cache *cache                                 OBJC2_UNAVAILABLE; // 缓存最近使用的方法地址，以避免多次在方法地址列表中查询，提升效率
    13.     struct objc_protocol_list *protocols                     OBJC2_UNAVAILABLE; // 遵循的协议列表
    14. #endif
    16. } OBJC2_UNAVAILABLE;
    17. /* Use `Class` instead of `struct objc_class *` */

    SEL 与 IMP

    SEL 可以将其理解为方法的 ID. 结构如下：

    1. typedef struct objc_selector *SEL;
    3. struct objc_selector {
    4.     char *name;                       OBJC2_UNAVAILABLE;
    5.     char *types;                      OBJC2_UNAVAILABLE;
    6. };

    IMP 可以理解为函数指针，指向了最终的实现。

    SEL 与 IMP 的关系非常类似于 HashTable 中 key 与 value 的关系。OC 中不支持函数重载的原因就是因为一个类的方法列表中不能存在两个相同的 SEL 。但是多个方法却可以在不同的类中有一个相同的 SEL，不同类的实例对象执行相同的 SEL 时，会在各自的方法列表中去根据 SEL 去寻找自己对应的IMP。这使得OC可以支持函数重写。

    消息传递机制

    • objc_msgSend函数的消息处理过程
    • 不涵盖消息cache机制
    • 需要对Objective-C runtime有一定的了解

    如下用于描述 objc_msgSend 函数的调用流程：

    • 1.检测 SEL 是否应该被忽略
    • 2.检测发送的 target 是否为 nil ，如果是则忽略该消息
    • 3.
      • 当调用实例方法时，通过 isa 指针找到实例对应的 class 并且在其中的缓存方法列表以及方法列表中进行查询，如果找不到则根据 super_class 指针在父类中查询，直至根类(NSObject 或 NSProxy).
      • 当调用类方法时，通过 isa 指针找到实例对应的 metaclass 并且在其中的缓存方法列表以及方法列表中进行查询，如果找不到则根据 super_class 指针在父类中查询，直至根类(NSObject 或 NSProxy). (根据此前的开篇中的图，Root Meta Class 还是有根类的。)
    • 如果还没找到则进入消息动态解析过程。

    由于苹果对OC 2.0 Runtime的具体实现细节未完全开源，本节所引用源代码大部分来自OC 1.0，如有错误，敬请更正

    当一个对象 sender 调用代码[receiver 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, ...)

    self与_cmd是两个编译器会自动添加的隐藏参数，self是一个指向接收对象的指针，_cmd为方法选择器。这个函数的实现为汇编版本，苹果开源的项目中共有6种对不同平台的汇编实现，本节选取其在x86_64实现的文件objc-msg-x86_64.s

    1. #objc-msg-x86_64.s#
    2.     ENTRY    _objc_msgSend
    3.     // ...
    4.     GetIsaFast NORMAL        // r11 = self->isa
    5.     CacheLookup NORMAL        // calls IMP on success
    6.     // ...
    7. // cache miss: go search the method lists
    8. LCacheMiss:
    9.     // isa still in r11
    10.     MethodTableLookup %a1, %a2    // r11 = IMP
    11.     cmp    %r11, %r11        // set eq (nonstret) for forwarding
    12.     jmp    *%r11            // goto *imp
    13.     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函数实现如下，

    1. .macro MethodTableLookup
    2.     MESSENGER_END_SLOW
    3.     SaveRegisters
    4.     // _class_lookupMethodAndLoadCache3(receiver, selector, class)
    5.     movq    $0, %a1
    6.     movq    $1, %a2
    7.     movq    %r11, %a3
    8.     call    __class_lookupMethodAndLoadCache3
    9.     // IMP is now in %rax
    10.     movq    %rax, %r11
    11.     RestoreRegisters
    12. .endmacro

    可以看到其实际上将receiver（即self)， selector(即_cmd)，class(即self->isa)传递给了_class_lookupMethodAndLoadCache3这个函数，查看该函数的实现后，欢迎重新回到C语言的世界。

    1. #objc-class-old.mm#
    2. IMP _class_lookupMethodAndLoadCache3(id obj, SEL sel, Class cls)
    3. {        
    4.     return lookUpImpOrForward(cls, sel, obj, 
    5.                               YES/*initialize*/, NO/*cache*/, YES/*resolver*/);
    6. }

    这个函数进一步调用了lookUpImpOrForward，并把cache标签置为NO，意味着忽略第一次不加锁的cache查找。这个函数的返回值要么是对应方法的IMP指针，要么是一个__objc_msgForward_impcache汇编方法的入口，后者对应着消息转发机制，即如果在该对象及其继承链上方的的对象都找不到选择器_cmd的响应方法的话，就调用消息转发函数尝试将该消息转发给其他对象。下面是lookUpImpOrForward的实现，由于代码过长，注释将写在代码之中。

    1. #objc-class-old.mm#
    2. IMP lookUpImpOrForward(Class cls, SEL sel, id inst, 
    3.                        bool initialize, bool cache, bool resolver)
    4. {
    5.     Class curClass;                   // 当前类对象
    6.     IMP methodPC = nil;               // 用于保存最终查找到的函数指针并返回
    7.     Method meth;                      // 定义了方法的一个结构体，可通过meth->imp获取函数指针
    8.     bool triedResolver = NO;          // 方法解析的标志变量
    10.     methodListLock.assertUnlocked();
    11.     // 不加锁地查找cache，由于之前cache落空，所以肯定找不到，就忽略
    12.     // Optimistic cache lookup                
    13.     if (cache) {
    14.         methodPC = _cache_getImp(cls, sel);
    15.         if (methodPC) return methodPC;    
    16.     }
    17.     // Check for freed class
    18.     if (cls == _class_getFreedObjectClass())
    19.         return (IMP) _freedHandler;
    20.     // 确保该类已被初始化，如果没有就调用类方法+initialize，这里也说明了为什么OC的类会在
    21.     // 第一次接收消息后调用+initialize进行初始化，相反的，如果想要代码在类注册runtime的
    22.     // 时候就运行，可以将代码写在+load方法里
    23.     // Check for +initialize
    24.     if (initialize  &&  !cls->isInitialized()) {
    25.         _class_initialize (_class_getNonMetaClass(cls, inst));
    26.         // If sel == initialize, _class_initialize will send +initialize and 
    27.         // then the messenger will send +initialize again after this 
    28.         // procedure finishes. Of course, if this is not being called 
    29.         // from the messenger then it won't happen. 2778172
    30.     }
    31.     // The lock is held to make method-lookup + cache-fill atomic 
    32.     // with respect to method addition. Otherwise, a category could 
    33.     // be added but ignored indefinitely because the cache was re-filled 
    34.     // with the old value after the cache flush on behalf of the category.
    35.     // 上述英文已述：对消息查找和填充cache加锁，由于填充cache是写操作，所以需要对其
    36.     // 加锁以免加入了category之后的cache被旧的cache冲掉，导致category失效。
    38.     // 实际上，如果cache没有命中，但在方法列表中找到了对应的IMP，函数也是会进行cache
    39.     // 写入操作。
    40.  retry:
    41.     methodListLock.lock();
    42.     // 在开启GC选项后忽略retain, release等方法(猜测GC 是 Garbage Collection)
    43.     // 这也体现了OC的灵活性，runtime完全有权力忽略一些方法
    44.     if (ignoreSelector(sel)) {
    45.         methodPC = _cache_addIgnoredEntry(cls, sel);
    46.         goto done;
    47.     }
    48.     // 在加锁的状态下再查找一次cache，如果命中就直接返回IMP指针
    49.     // 个人认为再次在加锁状态下查找是因为在与上次查找的间隙中可能
    50.     // 有其他类填充了这个cache
    51.     methodPC = _cache_getImp(cls, sel);
    52.     if (methodPC) goto done;
    54.     // 如果还是没有命中的话就查找该类的方法列表
    55.     meth = _class_getMethodNoSuper_nolock(cls, sel);
    56.     if (meth) {
    57.         // 命中，填充cache，返回IMP指针
    58.         log_and_fill_cache(cls, cls, meth, sel);
    59.         methodPC = method_getImplementation(meth);
    60.         goto done;
    61.     }
    63.     // 没有命中，沿着class的继承链向上查找，最后找到的是NSObject(NSProxy除外)
    64.     // 而NSObject的superclass为nil
    65.     curClass = cls;
    66.     while ((curClass = curClass->superclass)) {
    67.         // 尝试从超类的cache中加载
    68.         meth = _cache_getMethod(curClass, sel, _objc_msgForward_impcache);
    69.         if (meth) {
    70.             // 如果不是forward
    71.             if (meth != (Method)1) {
    72.                 // 在超类中找到IMP，在当前类中进行cache
    73.                 log_and_fill_cache(cls, curClass, meth, sel);
    74.                 methodPC = method_getImplementation(meth);
    75.                 goto done;
    76.             }
    77.             else {
    78.             // 找到forward，跳出循环
    79.                 // Found a forward:: entry in a superclass.
    80.                 // Stop searching, but don't cache yet; call method 
    81.                 // resolver for this class first.
    82.                 break;
    83.             }
    84.         }
    85.         // 超类cache没有命中，从超类的方法列表寻找
    86.         meth = _class_getMethodNoSuper_nolock(curClass, sel);
    87.         if (meth) {
    88.             log_and_fill_cache(cls, curClass, meth, sel);
    89.             methodPC = method_getImplementation(meth);
    90.             goto done;
    91.         }
    92.     }
    93.     // 使用方法解析并再尝试一次
    94.     if (resolver  &&  !triedResolver) {
    95.         methodListLock.unlock();
    96.         _class_resolveMethod(cls, sel, inst);
    97.         triedResolver = YES;
    98.         goto retry;
    99.     }
    100.     // 没有找到IMP指针，方法解析也没有用，使用消息转发，并将其填充入cache
    101.     _cache_addForwardEntry(cls, sel);
    102.     methodPC = _objc_msgForward_impcache;
    103.  done:
    104.     methodListLock.unlock();
    105.     // paranoia: look for ignored selectors with non-ignored implementations
    106.     assert(!(ignoreSelector(sel)  &&  methodPC != (IMP)&_objc_ignored_method));
    107.     return methodPC;
    108. }

    我们可以看到每一个类都维护了一个cache，在一个对象调用runtime的objc_msgSend函数后，runtime在接收者所属的类的cache中查找与_cmd所对应的IMP，如果没有命中就寻找当前类的方法列表，再找不到就跳入while循环寻找超类的cache和方法列表，如果这些方法都失效，就调用_class_resolveMethod查找正在插入这个类的方法，之后再重新尝试整一个流程，如果最后还是没能找到一个对应的IMP，则调用消息转发机制。

    动态消息解析

    Objective-C Runtime - 图2

    如下用于描述动态消息解析的流程:

    • 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