iOS底层-objc_msgSend流程分析

方法的本质

//main.m中方法的调用

//clang编译后的底层实现

我们发现oc的方法是通过objc_msgSend消息发送的，为了验证objc_msgSend方法来完成[person sayNB]的调用，查看其打印是否是一致

准备

1、直接调用objc_msgSend，需要导入头文件#import <objc/message.h>

2、需要将target --> Build Setting -->搜索msg-- 将enable strict checking of obc_msgSend calls由YES改为NO，将严厉的检查机制关掉，否则objc_msgSend的参数会报错

调用

LGPerson*person=[LGPerson alloc];

objc_msgSend(person,sel_registerName("sayNB"));

[person sayNB];

我们发现打印结果是一致的，所以 [person sayNB]等价于objc_msgSend(person,sel_registerName("sayNB"))

流程分析

我们在objc源码中搜索_objc_msgSend,我们研究的是真机这一块，所以需要在arm64.s后缀的文件中查找objc_msgSend源码实现，发现是汇编实现，其汇编整体执行的流程图如下：

方法快速查找流程

objc_msgSend 汇编源码

部分源码

图1 图2

图1判断了消息的接收者(receiver)是否为空,如果支持tagged pointer，跳转至LNilOrTagged，如果小对象为空，则直接返回空，即LReturnZero，如果小对象不为空，则处理小对象的isa。

图2如果即不是小对象，receiver也不为空，从receiver中取出isa存入p13寄存器，通过 GetClassFromIsa_p16中，arm64架构下通过 isa & ISA_MASK 获取shiftcls位域的类信息，即class。

缓存查找

我们通过源码发现执行了GetClassFromIsa_p16方法之后，会执行CacheLookup，也就是缓存查找，源码如下:

图1 图3

通过上图我们发现，这个流程和我们之前探索cache_t是一摸一样。

1.通过cache首地址平移16字节（因为在objc_class中，首地址距离cache正好16字节，即isa占8字节，superClass占8字节），获取cahce，cache中高16位存mask，低48位存buckets，即p11 = cache

2从cache中分别取出buckets和mask，并由mask根据哈希算法计算出哈希下标，通过cache和掩码（即0x0000ffffffffffff）的&运算，将高16位mask抹零，得到buckets指针地址，即p10 = buckets，将cache右移48位，得到mask，即p11 = mask

3.将objc_msgSend的参数p1（即第二个参数_cmd）& mask,通过哈希算法，得到需要查找存储sel-imp的bucket下标index，即p12 = index = _cmd & mask，根据所得的哈希下标index和buckets首地址，取出哈希下标对应的bucket。

4.比较获取的bucket中sel与objc_msgSend的第二个参数的_cmd(即p1)是否相等

如果相等，则直接跳转至CacheHit，即缓存命中，返回imp

如果不相等，有以下两种情况

如果一直都找不到，直接跳转至CheckMiss，因为$0是normal，会跳转至__objc_msgSend_uncached，即进入慢速查找流程

如果根据index获取的bucket等于buckets的第一个元素，则人为的将当前bucket设置为buckets的最后一个元素（通过buckets首地址+mask右移44位（等同于左移4位）直接定位到bucker的最后一个元素），然后继续进行递归循环（第一个递归循环嵌套第二个递归循环）