OC底层原理06:消息流程之快速查找

661 阅读6分钟

上一篇OC底层原理05-cache_t探索中分析了cache的写入流程,在写入流程之前,还有一个cache读取流程,即objc_msgSend 和 cache_getImp

本文的主要目的是理解objc_msgSend方法查找流程。

runtime简介

编译时:把源代码编译成机器能识别的代码过程。简单来说就是做一些翻译工作,代码还未装载进内存。也就是说编译时还未分配内存。这个过程主要是对语言进行最基本的检查报错,即词法分析、语法分析等,是一个静态的阶段。
运行时(Runtime):是代码运行起来被装载到内存过程,如果此时出错,则程序会崩溃,是一个动态阶段。

runtime有3种调用途径: image.png

  • 通过Objective-C Code,例如[person sayNB]
  • 通过Framework&Serivce,例如通过NSObject接口isKindOfClass
  • 通过Runtime API,例如class_getInstanceSize

Compiler就是我们了解的编译器,即LLVM,例如OC的alloc 对应底层的objc_alloc, runtime system libarary 就是底层库

方法本质

引入

测试代码:

//main.m中方法的调用
LGPerson *person = [LGPerson alloc];
[person sayNB];
[person sayHello];

通过clang clang -rewrite-objc -fobjc-arc -fobjc-runtime=ios-13.0.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator15.0.sdk main.m 生成main.app.

//👇clang编译后的底层实现
LGPerson *person = ((LGPerson *(*)(id, SEL))(void *)objc_msgSend)((id)objc_getClass("LGPerson"), sel_registerName("alloc"));
((void (*)(id, SEL))(void *)objc_msgSend)((id)person, sel_registerName("sayNB"));
((void (*)(id, SEL))(void *)objc_msgSend)((id)person, sel_registerName("sayHello"));

通过上述代码可以看出,方法的本质就是objc_msgSend消息发送. 为了验证,通过objc_msgSend方法来完成[person sayNB]的调用,查看其打印是否是一致

注:
1、直接调用objc_msgSend,需要导入头文件#import <objc/message.h>
2、需要将target --> Build Setting -->搜索msg -- 将enable strict checking of obc_msgSend callsYES 改为NO,将严厉的检查机制关掉,否则objc_msgSend的参数会报错

LGPerson *person = [LGPerson alloc];   
objc_msgSend(person,sel_registerName("sayNB"));
[person sayNB];

其打印结果如下,发现是一致的,所以 [person sayNB]等价于objc_msgSend(person,sel_registerName("sayNB")). image.png

指定调用父类的方法实现

尝试让person的调用执行父类中实现,通过objc_msgSendSuper实现. 定义两个类:LGPerson 和 LGTeacher,父类中实现了sayHello方法. image.png main中调用如下:

LGPerson *person = [LGPerson alloc];
LGTeacher *teacher = [LGTeacher alloc];
[person sayHello];

struct objc_super lgsuper;
lgsuper.receiver = person; //消息的接收者还是person
lgsuper.super_class = [LGTeacher class]; //告诉父类是谁
    
//消息的接受者还是自己 - 父类 - 请你直接找我的父亲
objc_msgSendSuper(&lgsuper, sel_registerName("sayHello"));

objc_msgSendSuper方法中有两个参数(objc_super类型结构体指针sel),objc_super结构体对象需要指定receiversuper_class两个属性,objc_msgSendSuper方法和objc_super定义和源码如下:

  • objc_msgSendSuper 方法参数 image.png
  • objc_super源码定义 image.png

打印结果如下: image.png 发现不论是[person sayHello]还是objc_msgSendSuper都执行的是父类sayHello的实现,所以这里,我们可以作一个猜测:方法调用,首先是在类中查找,如果类中没有找到,会到类的父类中查找。

带着我们的猜测,下面我们来探索objc_msgSend的源码实现。

objc_msgSend 快速查找流程分析

objc_msgSend有消息接受者 消息接受者寻找方法路径: 拿到对象 - 对象里有isa - 方法存在类或元类中 - 类中的cache_t是否存在缓存 - 如果没有缓存则在bits的methodList中找。

在objc4-781源码中,搜索objc_msgSend,由于我们日常开发的都是架构是arm64,所以需要在arm64.s后缀的文件中查找objc_msgSend源码实现,发现是汇编实现,其汇编整体执行的流程图如下:

image.png

objc_msgSend汇编源码

objc_msgSend 是用汇编实现的 查看_objc_msgSend汇编入口,以真机的arm64分析:

//---- 消息发送 -- 汇编入口--objc_msgSend主要是拿到接收者的isa信息
ENTRY _objc_msgSend 
//---- 无窗口
    UNWIND _objc_msgSend, NoFrame 
//---- p0 和空对比,即判断接收者是否存在,其中p0是objc_msgSend的第一个参数-消息接收者receiver
    cmp p0, #0          // nil check and tagged pointer check 
//---- 支持taggedpointer(小对象类型)的流程
#if SUPPORT_TAGGED_POINTERS
    b.le    LNilOrTagged        //le小于 --  (MSB tagged pointer looks negative) 
#else
//---- p0 等于 0 时,直接返回 空
    b.eq    LReturnZero 
#endif 
//---- p0即receiver 肯定存在的流程
//---- 根据对象拿出isa ,即从x0寄存器指向的地址 取出 isa,存入 p13寄存器
    ldr p13, [x0]       // p13 = isa 
//---- 在64位架构下通过 p16 = isa(p13) & ISA_MASK,拿出shiftcls信息,得到class信息
    GetClassFromIsa_p16 p13     // p16 = class 
LGetIsaDone:
    // calls imp or objc_msgSend_uncached 
//---- 如果有isa,走到CacheLookup 即缓存查找流程,也就是所谓的sel-imp快速查找流程
    CacheLookup NORMAL, _objc_msgSend

#if SUPPORT_TAGGED_POINTERS
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 x16, [x10, x11, LSL #3]
    adrp    x10, _OBJC_CLASS_$___NSUnrecognizedTaggedPointer@PAGE
    add x10, x10, _OBJC_CLASS_$___NSUnrecognizedTaggedPointer@PAGEOFF
    cmp x10, x16
    b.ne    LGetIsaDone

    // ext tagged
    adrp    x10, _objc_debug_taggedpointer_ext_classes@PAGE
    add x10, x10, _objc_debug_taggedpointer_ext_classes@PAGEOFF
    ubfx    x11, x0, #52, #8
    ldr x16, [x10, x11, LSL #3]
    b   LGetIsaDone
// SUPPORT_TAGGED_POINTERS
#endif

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

    END_ENTRY _objc_msgSend

判断objc_msgSend方法的第一个参数receiver是否为空。

  • 如果支持tagged pointer,跳转至LNilOrTagged

    • 如果小对象为空,则直接返回空,即LReturnZero
    • 如果小对象不为空,则处理小对象的isa,走到【CacheLookup NORMAL缓存查找】
  • 如果既不是小对象,receiver也不为空,有以下两步

    • receiver中取出isa存入p13寄存器,
    • 通过 GetClassFromIsa_p16中,arm64架构下通过 isa & ISA_MASK 获取shiftcls位域的类信息,即classGetClassFromIsa_p16的汇编实现如下,然后走到【CacheLookup NORMAL缓存查找】
.macro GetClassFromIsa_p16 /* src */
...
//--用于64位系统
#elif __LP64__ 
    // 64-bit packed isa
//---- p16 = class = isa & ISA_MASK(位运算 & 即获取isa中的shiftcls信息)
    and p16, $0, #ISA_MASK 
.endmacro

p0是存放消息接受者receiver p1是SEL(_cmd)。

获取isa完毕,进入快速查找流程CacheLookup NORMAL 从缓存cache获取imp

//!!!!!!!!!重点!!!!!!!!!!!!
.macro CacheLookup 
    //
    // Restart protocol:
    //
    //   As soon as we're past the LLookupStart$1 label we may have loaded
    //   an invalid cache pointer or mask.
    //
    //   When task_restartable_ranges_synchronize() is called,
    //   (or when a signal hits us) before we're past LLookupEnd$1,
    //   then our PC will be reset to LLookupRecover$1 which forcefully
    //   jumps to the cache-miss codepath which have the following
    //   requirements:
    //
    //   GETIMP:
    //     The cache-miss is just returning NULL (setting x0 to 0)
    //
    //   NORMAL and LOOKUP:
    //   - x0 contains the receiver
    //   - x1 contains the selector
    //   - x16 contains the isa
    //   - other registers are set as per calling conventions
    //
LLookupStart$1:

//---- p1 = SEL, p16 = isa 
//--- #define CACHE (2 * __SIZEOF_POINTER__),其中 __SIZEOF_POINTER__表示pointer的大小 ,即 2*8 = 16
//---- 从x16(即isa)中平移16字节,取出cache 存入p11寄存器 -- isa距离cache 正好16字节:isa(8字节)-superClass(8字节)
//arm64中 mask和buckets为了节省内存,是放在一个变量_maskAndBuckets里。高16位是mask,低48位是buckets。p11就是_maskAndBuckets
    ldr p11, [x16, #CACHE]  //p11 = mask|buckets           

//---- 64位真机
#if CACHE_MASK_STORAGE == CACHE_MASK_STORAGE_HIGH_16 
//--- p11(_maskAndBuckets) & 0x0000ffffffffffff ,mask高16位抹零,低48位得到buckets 存入p10寄存器-- 即去掉mask,留下buckets
    and p10, p11, #0x0000ffffffffffff   // p10 = buckets 

//--- p11 LSR #48是把p11(_maskAndBuckets)逻辑右移48位,取出mask.然后和p1(SEL)与运算,得到sel-imp的下标index(即搜索下标),结果放在p12。p12就是搜索的hash下标(cache insert写入时的哈希下标计算是 通过 sel & mask,读取时也需要通过这种方式) 
//cache insert写入时的哈希下标计算 
//static inline mask_t cache_hash(SEL sel, mask_t mask) 
//{
//    uintptr_t value = (uintptr_t)sel;
//    return (mask_t)(value & mask);
//}
    and p12, p1, p11, LSR #48 //哈希下标x12 = _cmd & mask

//PTRSHIFT=3
通过buckets hash下标p12左移(1+PTRSHIFT)16位, 找到具体bucket,然后赋值给p12. 注:16位是bucket占的大小(sel和imp,都为uintptr_t类型即unsigned long)
//bucket_t源码:struct bucket_t {
//private:
    // IMP-first is better for arm64e ptrauth and no worse for arm64.
    // SEL-first is better for armv7* and i386 and x86_64.
//#if __arm64__
//    explicit_atomic<uintptr_t> _imp;
//    explicit_atomic<SEL> _sel;
// ...
and p12, p10, p12, LSL #(1+PTRSHIFT) //p12=buckets+((_cmd&mask)<<(1+PTRSHIFT)) mask=_occupied-1 ---_cmd & mask -- 取余数
                    
//--- 从x12(即p12)中取出 bucket 分别将imp和sel 存入 p17(存储imp) 和 p9(存储sel)
    ldp p17, p9, [x12]      // {imp, sel} = *bucket 
    
//--- 比较 sel 与 p1(传入的参数cmd)
1:  cmp p9, p1          // if (bucket->sel != _cmd) 
//--- 如果不相等,即没有找到,请跳转至 2f
    b.ne    2f          //     scan more 
//--- 如果相等 即cacheHit 缓存命中,直接返回imp
    CacheHit $0         // call or return imp 
    
2:  // not hit: p12 = not-hit bucket
//--- 如果一直都找不到, 因为是normal ,跳转至__objc_msgSend_uncached
    CheckMiss $0            // miss if bucket->sel == 0 
//--- 判断p12(下标对应的bucket) 是否 等于 p10(buckets数组第一个元素,),如果等于,则跳转至第3步
    cmp p12, p10        // wrap if bucket == buckets 
//--- 定位到最后一个元素(即第一个bucket)
    b.eq    3f 
//--- 从x12(即p12 buckets首地址)- 实际需要平移的内存大小BUCKET_SIZE,得到得到第二个bucket元素,imp-sel分别存入p17-p9,即向前查找
    ldp p17, p9, [x12, #-BUCKET_SIZE]!  // {imp, sel} = *--bucket 
//--- 跳转至第1步,继续对比 sel 与 cmd
    b   1b          // loop 

3:  // wrap: p12 = first bucket, w11 = mask
#if CACHE_MASK_STORAGE == CACHE_MASK_STORAGE_HIGH_16
//--- 人为设置到最后一个元素
//--- p11(mask)右移44位 相当于mask左移4位,直接定位到buckets的最后一个元素,缓存查找顺序是向前查找
    add p12, p12, p11, LSR #(48 - (1+PTRSHIFT)) 
                    // p12 = buckets + (mask << 1+PTRSHIFT) 
#elif CACHE_MASK_STORAGE == CACHE_MASK_STORAGE_LOW_4
    add p12, p12, p11, LSL #(1+PTRSHIFT)
                    // p12 = buckets + (mask << 1+PTRSHIFT)
#else
#error Unsupported cache mask storage for ARM64.
#endif

    // Clone scanning loop to miss instead of hang when cache is corrupt.
    // The slow path may detect any corruption and halt later.
//--- 再查找一遍缓存()
//--- 拿到x12(即p12)bucket中的 imp-sel 分别存入 p17-p9
    ldp p17, p9, [x12]      // {imp, sel} = *bucket 
    
//--- 比较 sel 与 p1(传入的参数cmd)
1:  cmp p9, p1          // if (bucket->sel != _cmd) 
//--- 如果不相等,即走到第二步
    b.ne    2f          //     scan more 
//--- 如果相等 即命中,直接返回imp
    CacheHit $0         // call or return imp  
    
2:  // not hit: p12 = not-hit bucket
//--- 如果一直找不到,则CheckMiss
    CheckMiss $0            // miss if bucket->sel == 0 
//--- 判断p12(下标对应的bucket) 是否 等于 p10(buckets数组第一个元素)-- 表示前面已经没有了,但是还是没有找到
    cmp p12, p10        // wrap if bucket == buckets 
    b.eq    3f //如果等于,跳转至第3步
//--- 从x12(即p12 buckets首地址)- 实际需要平移的内存大小BUCKET_SIZE,得到得到第二个bucket元素,imp-sel分别存入p17-p9,即向前查找
    ldp p17, p9, [x12, #-BUCKET_SIZE]!  // {imp, sel} = *--bucket 
//--- 跳转至第1步,继续对比 sel 与 cmd
    b   1b          // loop 

LLookupEnd$1:
LLookupRecover$1:
3:  // double wrap
//--- 跳转至JumpMiss 因为是normal ,跳转至__objc_msgSend_uncached

    JumpMiss $0 
.endmacro

//以下是最后跳转的汇编函数
.macro CacheHit
.if $0 == NORMAL
    TailCallCachedImp x17, x12, x1, x16 // authenticate and call imp
.elseif $0 == GETIMP
    mov p0, p17
    cbz p0, 9f          // don't ptrauth a nil imp
    AuthAndResignAsIMP x0, x12, x1, x16 // authenticate imp and re-sign as IMP
9:  ret             // return IMP
.elseif $0 == LOOKUP
    // No nil check for ptrauth: the caller would crash anyway when they
    // jump to a nil IMP. We don't care if that jump also fails ptrauth.
    AuthAndResignAsIMP x17, x12, x1, x16    // authenticate imp and re-sign as IMP
    ret             // return imp via x17
.else
.abort oops
.endif
.endmacro

.macro CheckMiss
    // miss if bucket->sel == 0
.if $0 == GETIMP 
//--- 如果为GETIMP ,则跳转至 LGetImpMiss
    cbz p9, LGetImpMiss
.elseif $0 == NORMAL 
//--- 如果为NORMAL ,则跳转至 __objc_msgSend_uncached
    cbz p9, __objc_msgSend_uncached
.elseif $0 == LOOKUP 
//--- 如果为LOOKUP ,则跳转至 __objc_msgLookup_uncached
    cbz p9, __objc_msgLookup_uncached
.else
.abort oops
.endif
.endmacro

.macro JumpMiss
.if $0 == GETIMP
    b   LGetImpMiss
.elseif $0 == NORMAL
    b   __objc_msgSend_uncached
.elseif $0 == LOOKUP
    b   __objc_msgLookup_uncached
.else
.abort oops
.endif
.endmacro

主要分下面几步:

【第一步】. 通过cache首地址平移16字节(因为在objc_class中,首地址距离cache正好16字节,即isa首地址8字节,superClass8字节),获取cahce,cache中高16位存mask低48位存buckets,即p11 = cache
【第二步】. 从cache中分别取出buckets和mask,并由mask根据哈希算法计算出哈希下标
  • 通过cache掩码(即0x0000ffffffffffff)& 运算,将高16位mask抹零,得到buckets指针地址,即p10 = buckets

image.png

  • cache右移48位,得到mask,即p11 = mask

  • objc_msgSend的参数p1(即第二个参数_cmd)& msak,通过哈希算法,得到需要查找存储sel-imp的bucket下标index,即p12 = index = _cmd & mask,为什么通过这种方式呢?因为在存储sel-imp时,也是通过同样哈希算法计算哈希下标进行存储,所以读取也需要通过同样的方式读取,如下所示: image.png

【第三步】. 根据所得的哈希下标index 和 buckets首地址,取出哈希下标对应的bucket
  • 其中PTRSHIFT等于3,左移4位(即2^4 = 16字节)的目的是计算出一个bucket实际占用的大小,结构体bucket_tsel8字节,imp8字节

  • 根据计算的哈希下标index 乘以 单个bucket占用的内存大小,得到buckets首地址在实际内存中的偏移量

  • 通过首地址 + 实际偏移量,获取哈希下标index对应的bucket

【第四步】. 根据获取的bucket,取出其中的imp存入p17,即p17 = imp,取出sel存入p9,即p9 = sel
【第五步】. 第一次递归循环
  • 比较获取的bucketselobjc_msgSend的第二个参数的_cmd(即p1)是否相等

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

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

    • 如果一直都找不到,直接跳转至CheckMiss,因为$0normal,会跳转至__objc_msgSend_uncached,即进入慢速查找流程
    • 如果根据index获取的bucket 等于 buckets的第一个元素,则人为的将当前bucket设置为buckets的最后一个元素(通过buckets首地址+mask右移44位(等同于左移4位)直接定位到bucker的最后一个元素),然后继续进行递归循环(第一个递归循环嵌套第二个递归循环),即【第六步】
    • 如果当前bucket不等于buckets的第一个元素,则继续向前查找,进入第一次递归循环
【第六步】. 第二次递归循环:重复【第五步】的操作,与【第五步】中唯一区别是,如果当前的bucket还是等于 buckets的第一个元素,则直接跳转至JumpMiss,此时的$0normal,也是直接跳转至__objc_msgSend_uncached,即进入慢速查找流程

以下是整个快速查找过程值的变化过程:

image.png

文章列表

博客文章列表

参考