源码剖析 Objc 消息派发流程

Objc 的方法调用是运行时决定的，系统会根据 selector 动态地查找 IMP，那么这一过程究竟是怎样实现的？selector 是如何与 IMP 对应起来的？面对应用内部成千上万次的函数调用，它会不会造成性能瓶颈？基于这些疑问，本文将会从源码的角度来探究 Objc 的消息派发流程。

一切都源于 objc_msgSend

在 Objc 中我们这样去调用函数：

[obj func1]

但是编译器会将其翻译成如下代码：

objc_msgSend(obj, @selector(func1));

objc_msgSend 是处理方法调用的核心，Objc 中的函数调用都交由 objc_msgSend 执行，它会启动整个消息派发流程，寻找与 selector 相对应的函数实现，所以我们源码探究的切入点就是 objc_msgSend。从这里可以下载到 objc 的源码，本文用的是 objc4-680 版本。

objc_msgSend 是汇编语言写的，为什么是这样呢？一方面是性能上的考虑，动态查找 IMP 是一项耗时的过程，况且应用运行时会无数次的调用函数，因此需要 objc_msgSend 在执行速度上达到最优；另一方面是编程语言上的问题，因为程序员会设计出各式各样的函数，它们的参数也是数量不一、类型多变的，使用 C 语言很难写出函数原型来处理所有的情景，所以需要使用汇编来解决。

另一个需要注意的地方是函数的返回值，使用汇编可以解决可变参数的问题，但是函数返回值还是要区别对待。如果函数的返回值是 struct 或是 float，那么会有 objc_msgSend_stret 以及 objc_msgSend_fpret 版本与其对应，详情可见 message.h 文件。

以下是 ARM64 架构上的 objc_msgSend 代码（对应 objc-msg-arm64.s 文件）：

    ENTRY _objc_msgSend
    MESSENGER_START

    cmp x0, #0          // nil check and tagged pointer check
    b.le    LNilOrTagged        //  (MSB tagged pointer looks negative)
    ldr x13, [x0]       // x13 = isa
    and x9, x13, #ISA_MASK  // x9 = class   
LGetIsaDone:
    CacheLookup NORMAL      // calls imp or objc_msgSend_uncached

LNilOrTagged:
    b.eq    LReturnZero     // nil check

    // tagged
    adrp    x10, _objc_debug_taggedpointer_classes@PAGE
    add x10, x10, _objc_debug_taggedpointer_classes@PAGEOFF
    ubfx    x11, x0, #60, #4
    ldr x9, [x10, x11, LSL #3]
    b   LGetIsaDone

LReturnZero:
    // x0 is already zero
    mov x1, #0
    movi    d0, #0
    movi    d1, #0
    movi    d2, #0
    movi    d3, #0
    MESSENGER_END_NIL
    ret

    END_ENTRY _objc_msgSend

objc_msgSend 首先会去检测对象指针是否为 nil 或是 tagged pointer，如果是 nil，则返回的 IMP 也是 nil；如果是 tagged pointer，则对其进行特殊处理得到 isa 指针。接下来便是根据 isa 拿到 class 指针，然后进入最关键的一步：CacheLookup。

方法缓存

为了提升 IMP 的查询速度，系统为其设计了缓存。objc_msgSend 进行消息派发的第一步便是去缓存中查找 IMP，具体的查询流程在 CacheLookup 中。在阅读 CacheLookup 代码前，我们需要弄清楚 Objc 的方法缓存究竟是什么。

/// An opaque type that represents an Objective-C class.
typedef struct objc_class *Class;

struct objc_class : objc_object {
    // Class ISA;
    Class superclass;
    cache_t cache;             // formerly cache pointer and vtable
    class_data_bits_t bits;
    ......
}

方法缓存存在于类对象中，而且每个类都有一份。类的结构推荐大家看这篇文章：从 NSObject 的初始化了解 isa，本文就不再赘述。在上面代码中，我们可以看到方法缓存的类型是 cache_t，它的定义如下：

struct cache_t {
    struct bucket_t *_buckets; 
    mask_t _mask;
    mask_t _occupied;
...
}

struct bucket_t {
    cache_key_t _key;
    IMP _imp;
...
}

其中的 mask_t 以及 cache_key_t 定义如下：

#if __LP64__
typedef uint32_t mask_t;  // x86_64 & arm64 asm are less efficient with 16-bits
#else
typedef uint16_t mask_t;
#endif

typedef unsigned long    uintptr_t;
typedef uintptr_t        cache_key_t;

在 Objc 中，方法缓存被设计成一张 hash 表，对应于 cache_t 结构体中的 _buckets 属性。cache_t 中的 _mask 属性代表 _buckets 数组的最大索引（size = _mask + 1），_occupied 代表当前已存放的缓存数量，当 _occupied / _buckets.size > 3 / 4 时，系统会对 _buckets 数组扩容。以下是 Objc 存放缓存的算法，我们来看下缓存是怎样被填充的：

cache_t *getCache(Class cls) 
{
    assert(cls);
    return &cls->cache;
}

cache_key_t getKey(SEL sel) 
{
    assert(sel);
    return (cache_key_t)sel;
}

static void cache_fill_nolock(Class cls, SEL sel, IMP imp, id receiver)
{
    // 1. 合法性检查
    ......

    cache_t *cache = getCache(cls);
    cache_key_t key = getKey(sel);

    // 2. 判断是否需要扩容
    ......
    
    // 3. 插入缓存
    // Scan for the first unused slot and insert there.
    // There is guaranteed to be an empty slot because the 
    // minimum size is 4 and we resized at 3/4 full.
    bucket_t *bucket = cache->find(key, receiver);
    if (bucket->key() == 0) cache->incrementOccupied();
    bucket->set(key, imp);
}

系统首先会进行一些合法性检查以及判断是否需要对缓存进行扩容，接下来便是调用 cache->find(key, receiver) 函数寻找存放缓存的位置，最后调用 bucket->set(key, imp) 设置缓存。这样看来核心代码就在 cache->find 中了，我们来看它的实现：

static inline mask_t cache_hash(cache_key_t key, mask_t mask) 
{
    return (mask_t)(key & mask);
}

static inline mask_t cache_next(mask_t i, mask_t mask) {
    return i ? i-1 : mask;
}

bucket_t * cache_t::find(cache_key_t k, id receiver)
{
    assert(k != 0);

    bucket_t *b = buckets();
    mask_t m = mask();
    mask_t begin = cache_hash(k, m);
    mask_t i = begin;
    do {
        if (b[i].key() == 0  ||  b[i].key() == k) {
            return &b[i];
        }
    } while ((i = cache_next(i, m)) != begin);

    // hack
    Class cls = (Class)((uintptr_t)this - offsetof(objc_class, cache));
    cache_t::bad_cache(receiver, (SEL)k, cls);
}

系统通过 cache_hash 函数对 selector 进行简单的运算，得到 hash 表的索引，然后去 _buckets 中取出缓存，如果为空或是发现之前已经记录过，那么就返回缓存，否则就依次遍历 hash 表来寻找合适的位置。以上便是 Objc 用于存放缓存的核心算法，只要把相关的数据结构弄清楚了就很容易看懂，那么接下来就来看 CacheLookup 到底做了些什么事情：

.macro CacheLookup
    // x1 = SEL, x9 = isa
    ldp x10, x11, [x9, #CACHE]  // x10 = buckets, x11 = occupied|mask
    and w12, w1, w11        // x12 = _cmd & mask
    add x12, x10, x12, LSL #4   // x12 = buckets + ((_cmd & mask)<<4)

    ldp x16, x17, [x12]     // {x16, x17} = *bucket
1:  cmp x16, x1         // if (bucket->sel != _cmd)
    b.ne    2f          //     scan more
    CacheHit $0         // call or return imp
    
2:  // not hit: x12 = not-hit bucket
    CheckMiss $0            // miss if bucket->cls == 0
    cmp x12, x10        // wrap if bucket == buckets
    b.eq    3f
    ldp x16, x17, [x12, #-16]!  // {x16, x17} = *--bucket
    b   1b          // loop

3:  // wrap: x12 = first bucket, w11 = mask
    add x12, x12, w11, UXTW #4  // x12 = buckets+(mask<<4)

    // Clone scanning loop to miss instead of hang when cache is corrupt.
    // The slow path may detect any corruption and halt later.

    ldp x16, x17, [x12]     // {x16, x17} = *bucket
1:  cmp x16, x1         // if (bucket->sel != _cmd)
    b.ne    2f          //     scan more
    CacheHit $0         // call or return imp
    
2:  // not hit: x12 = not-hit bucket
    CheckMiss $0            // miss if bucket->cls == 0
    cmp x12, x10        // wrap if bucket == buckets
    b.eq    3f
    ldp x16, x17, [x12, #-16]!  // {x16, x17} = *--bucket
    b   1b          // loop

3:  // double wrap
    JumpMiss $0
    
.endmacro

虽然 CacheLookup 都是用汇编写的，但是有了上面的基础再配合代码注释，理解起来并不困难。大体上来说，还是先通过 selector 计算得到 hash 表的索引，然后去 buckets 中寻找缓存，若是有冲突就
顺位向下寻找，如果最后找到了，就执行相应的 IMP，否则就交由 JumpMiss 处理：

.macro JumpMiss
.if $0 == NORMAL
    b   __objc_msgSend_uncached_impcache
.else
    b   LGetImpMiss
.endif

由于最初我们是这样调用 CacheLookup 的：CacheLookup NORMAL ，所以当缓存没有命中时，系统会跳转到 __objc_msgSend_uncached_impcache 进行下一步的处理。

STATIC_ENTRY __objc_msgSend_uncached_impcache

   // 保存寄存器中的值
    ......

    // receiver and selector already in x0 and x1
    mov x2, x9
    bl  __class_lookupMethodAndLoadCache3

    // imp in x0
    mov x17, x0
    
    // 恢复寄存器
    ......
    
    br  x17

    END_ENTRY __objc_msgSend_uncached_impcache

可以看到 __objc_msgSend_uncached_impcache 最终调用 __class_lookupMethodAndLoadCache3 函数来处理缓存失效的情况，同时它也是我们接下来要讲的消息派发的第二阶段：消息发送。

消息发送

消息发送是在缓存失效后启动的，主要的作用就是在类自身以及继承体系中寻找 IMP，与此外还给了程序员动态添加 IMP 的机会。前面我们提到系统在缓存失效后会调用 __class_lookupMethodAndLoadCache3 函数，但是 __class_lookupMethodAndLoadCache3 仅仅调用了 lookUpImpOrForward 函数（参见 objc-runtime-new.mm 文件）：

/***********************************************************************
* _class_lookupMethodAndLoadCache.
* Method lookup for dispatchers ONLY. OTHER CODE SHOULD USE lookUpImp().
* This lookup avoids optimistic cache scan because the dispatcher 
* already tried that.
**********************************************************************/
IMP _class_lookupMethodAndLoadCache3(id obj, SEL sel, Class cls)
{
    return lookUpImpOrForward(cls, sel, obj, 
                              YES/*initialize*/, NO/*cache*/, YES/*resolver*/);
}

看来 lookUpImpOrForward 函数是消息发送的核心，我们来看它到底做了些什么：

1. 在缓存中寻找 IMP。由于之前对缓存的查询以失败告终，所以 _class_lookupMethodAndLoadCache3 调用 lookUpImpOrForward 函数时传入的 cache 参数为 NO，因此这里并不会触发缓存的查询操作。

  Class curClass;
  IMP imp = nil;
  Method meth;
  bool triedResolver = NO;

  runtimeLock.assertUnlocked();
  
 // Optimistic cache lookup
  if (cache) {
      imp = cache_getImp(cls, sel);
      if (imp) return imp;
  }

2. 进行一些准备工作，realizeClass 用来申请 class_rw_t 的可读写空间，_class_initialize 是对类进行初始化。

    if (!cls->isRealized()) {
        rwlock_writer_t lock(runtimeLock);
        realizeClass(cls);
    }
   
    if (initialize  &&  !cls->isInitialized()) {
        _class_initialize (_class_getNonMetaClass(cls, inst));
    }
   

3. 准备工作结束后，开始消息发送的流程。

  // 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.
retry:
  runtimeLock.read();
  
  // Ignore GC selectors
  if (ignoreSelector(sel)) {
      imp = _objc_ignored_method;
      cache_fill(cls, sel, imp, inst);
      goto done;
  }

  // Try this class's cache.

  imp = cache_getImp(cls, sel);
  if (imp) goto done;

系统先是调用 runtimeLock.read() 加锁，然后判断 sel 是否与垃圾回收相关，是的话就返回 _objc_ignored_method，否则就去缓存中查找，如果缓存未命中，就进入下一步。

4. 调用 getMethodNoSuper_nolock 在类自身的方法列表中查找，如果找到，则调用 log_and_fill_cache 填充缓存并结束查询流程，否则进入下一步。

// Try this class's method lists.

  meth = getMethodNoSuper_nolock(cls, sel);
  if (meth) {
      log_and_fill_cache(cls, meth->imp, sel, inst, cls);
      imp = meth->imp;
      goto done;
  }

log_and_fill_cache 最终会调用到 cache_fill_nolock 函数，也就是我们之前讲的存放缓存的那一套流程。

5. 按照继承体系依次在父类的缓存以及方法列表中寻找 IMP。

// Try superclass caches and method lists.

  curClass = cls;
  while ((curClass = curClass->superclass)) {
      // Superclass cache.
      imp = cache_getImp(curClass, sel);
      if (imp) {
          if (imp != (IMP)_objc_msgForward_impcache) {
              // Found the method in a superclass. Cache it in this class.
              log_and_fill_cache(cls, imp, sel, inst, curClass);
              goto done;
          }
          else {
              // Found a forward:: entry in a superclass.
              // Stop searching, but don't cache yet; call method 
              // resolver for this class first.
              break;
          }
      }

      // Superclass method list.
      meth = getMethodNoSuper_nolock(curClass, sel);
      if (meth) {
          log_and_fill_cache(cls, meth->imp, sel, inst, curClass);
          imp = meth->imp;
          goto done;
      }
  }

如果在父类中找到了 IMP，系统会将其填充到子类的方法缓存中（不会填充到父类的缓存），然后结束流程。如果在父类中没有找到 IMP 或者找到的 IMP 是 _objc_msgForward_impcache，那么系统会结束对父类的查询，然后进入下一步。

6. 动态方法解析。

// No implementation found. Try method resolver once.

  if (resolver  &&  !triedResolver) {
      runtimeLock.unlockRead();
      _class_resolveMethod(cls, sel, inst);
      // Don't cache the result; we don't hold the lock so it may have 
      // changed already. Re-do the search from scratch instead.
      triedResolver = YES;
      goto retry;
  }

系统使用 runtimeLock.unlockRead() 解锁，然后调用 _class_resolveMethod 函数给程序员一个动态添加 IMP 的机会：

void _class_resolveMethod(Class cls, SEL sel, id inst)
{
  if (! cls->isMetaClass()) {
      // try [cls resolveInstanceMethod:sel]
      _class_resolveInstanceMethod(cls, sel, inst);
  } 
  else {
      // try [nonMetaClass resolveClassMethod:sel]
      // and [cls resolveInstanceMethod:sel]
      _class_resolveClassMethod(cls, sel, inst);
      if (!lookUpImpOrNil(cls, sel, inst, 
                          NO/*initialize*/, YES/*cache*/, NO/*resolver*/)) 
      {
          _class_resolveInstanceMethod(cls, sel, inst);
      }
  }
}

_class_resolveMethod 首先会判断 cls 是否是元类，如果不是元类，就去调用 _class_resolveInstanceMethod 来动态解析实例方法，否则就调用 _class_resolveClassMethod 动态解析类方法，如果 _class_resolveClassMethod 没有起到作用，就调用 _class_resolveInstanceMethod 再次解析。

这里以 _class_resolveInstanceMethod 为例：

static void _class_resolveInstanceMethod(Class cls, SEL sel, id inst)
{
  if (! lookUpImpOrNil(cls->ISA(), SEL_resolveInstanceMethod, cls, 
                       NO/*initialize*/, YES/*cache*/, NO/*resolver*/)) 
  {
      // Resolver not implemented.
      return;
  }

  BOOL (*msg)(Class, SEL, SEL) = (typeof(msg))objc_msgSend;
  bool resolved = msg(cls, SEL_resolveInstanceMethod, 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(cls, sel, inst, 
                           NO/*initialize*/, YES/*cache*/, NO/*resolver*/);

  // 打印日志
  ......
}

实例方法的动态解析需要程序员实现 + (BOOL)resolveInstanceMethod:(SEL)sel; 方法，在其中为类添加 IMP， _class_resolveInstanceMethod 函数运行时会去调用这个方法，然后利用 lookUpImpOrNil 函数缓存结果。如果需要动态添加类方法，你需要实现 + (BOOL)resolveClassMethod:(SEL)sel;。

动态解析结束后，goto retry; 会重复之前的查找流程，这会是消息发送流程的最后一次尝试。

7. retry 结束后，如果 IMP 还是没有找到，那么系统就返回 _objc_msgForward_impcache，进入消息转发阶段。

  // No implementation found, and method resolver didn't help. 
  // Use forwarding.

  imp = (IMP)_objc_msgForward_impcache;
  cache_fill(cls, sel, imp, inst);

done:
  runtimeLock.unlockRead();
  
  // paranoia: look for ignored selectors with non-ignored implementations
  assert(!(ignoreSelector(sel)  &&  imp != (IMP)&_objc_ignored_method));

  // paranoia: never let uncached leak out
  assert(imp != _objc_msgSend_uncached_impcache);

  return imp;

消息转发

消息转发是 Objc 消息派发的第三步，也是最后一步，不过 _objc_msgForward_impcache 只是内部使用的函数指针，它需要被转为 _objc_msgForward 才可以被外部调用。

/********************************************************************
*
* id _objc_msgForward(id self, SEL _cmd,...);
*
* _objc_msgForward is the externally-callable
*   function returned by things like method_getImplementation().
* _objc_msgForward_impcache is the function pointer actually stored in
*   method caches.
*
********************************************************************/

STATIC_ENTRY __objc_msgForward_impcache

    MESSENGER_START
    nop
    MESSENGER_END_SLOW

    // No stret specialization.
    b   __objc_msgForward

END_ENTRY __objc_msgForward_impcache

而 _objc_msgForward 也不是终点，它仅仅调用 __objc_forward_handler：

ENTRY __objc_msgForward

    adrp    x17, __objc_forward_handler@PAGE
    ldr x17, [x17, __objc_forward_handler@PAGEOFF]
    br  x17
    
END_ENTRY __objc_msgForward

那么 __objc_forward_handler 究竟是什么，我们可以在 objc-runtime.mm 文件中找到它的默认实现：

// Default forward handler halts the process.
__attribute__((noreturn)) void 
objc_defaultForwardHandler(id self, SEL sel)
{
    _objc_fatal("%c[%s %s]: unrecognized selector sent to instance %p "
                "(no message forward handler is installed)", 
                class_isMetaClass(object_getClass(self)) ? '+' : '-', 
                object_getClassName(self), sel_getName(sel), self);
}
void *_objc_forward_handler = (void*)objc_defaultForwardHandler;

void objc_setForwardHandler(void *fwd, void *fwd_stret)
{
    _objc_forward_handler = fwd;
#if SUPPORT_STRET
    _objc_forward_stret_handler = fwd_stret;
#endif
}

用来设置 __objc_forward_handler 的函数是 objc_setForwardHandler，但是在苹果开源的代码中并没有看到它在哪里被调用，那么就在实际项目中打个断点看一下：

它是在 __CFInitialize 函数中被调用，调用时传入 __forwarding_prep_0___ 以及 __forwarding_prep_1___ 参数：
结合 objc_setForwardHandler 的代码，可以看出 __forwarding_prep_0___ 对应 _objc_forward_handler，而 __forwarding_prep_1___ 对应 _objc_forward_stret_handler。然而在源码中依旧没有看到 __forwarding_prep_0___，那么就反汇编看一下 __forwarding_prep_0___ 都做了些什么：

__forwarding_prep_0___ 内部调用 ___forwarding___ 函数，如果 ___forwarding___ 的结果不为空，则将结果返回，否则调用 objc_msgSend，下一步应该就是抛出 doesNotRecognizeSelector 错误了。使用 dis -n ___forwarding___ 命令可以查看 ___forwarding___ 的内部逻辑，这里就不截图了（图片大概有两个外接显示器那么高🤣），下面简单总结一下 ___forwarding___ 内部的流程：

1. 如果用户实现了 forwardingTargetForSelector 函数，就用它拿到用于消息转发的新的 target，如果 target 不为空并且不是当前对象，那么就调用 objc_msgSend(target, sel, ...) 函数，否则进入下一步。

2. 判断当前对象是否为僵尸对象，是的话就会抛出异常：

3. 如果用户实现了 methodSignatureForSelector 函数并且生成的签名不为空，系统就会根据它创建 NSInvocation 对象，并将其作为参数传递给 forwardInvocation 函数，否则进入下一步。

4. 判断 selector 是否在 runtime 注册过，没有的话会出现这样的提错误信息：

否则就是大家喜闻乐见的的 doesNotRecognizeSelector 错误，如果连 doesNotRecognizeSelector 也没有实现，错误信息会是这样：

以上就是消息转发的流程。

总结

上面的内容涵盖了 Objc 消息派发的三部曲：1. 缓存查找；2. 消息发送；3. 消息转发，由于内容十分庞杂，所以这里总结下消息派发的流程来帮助大家理解：

enmmmmmmm，终于写完了，断断续续花了好多时间，中途还差点弃坑，不过最终还是完成了，真是可喜可贺，晚上给自己加个鸡腿🤣