iOS-底層原理10:消息流程分析之快速查找

在上一篇文章iOS-底層原理9:objc_class 中 cache 原理分析
中,分析了cache寫入流程,在寫入流程之前,還有一個cache讀取流程,即objc_msgSendcache_getImp

在探索objc_msgSend前,我們需要先了解OCruntime機制。

runtime

什么是runtime?

runtime稱為運行時,它區別于編譯時

階段 過程 作用
運行時 代碼跑起來,被裝載到內存中 如果此時出錯,則程序會崩潰,是一個動態階段
編譯時 源代碼翻譯成機器能識別的代碼 主要是對語言進行最基本的檢查報錯,即詞法分析、語法分析等,是一個靜態的階段
runtime的使用方式

runtime的使用有以下三種方式,其三種實現方法與編譯層和底層的關系如圖所示:

  • Objective-C Code直接調用
    比如 [self sayNB]
  • Framework&Serivce
    比如NSSelectorFromStringisKindeofClassisMemberOfClass等方法。
  • RuntimeAPI
    比如class_getInstanceSize

其中的compiler就是我們了解的編譯器,即LLVMruntime system library就是底層庫

探索方法的本質

方法的本質

iOS-底層原理7:isa與類關聯的原理中,為了理解OC對象的本質我們將oc文件通過clang編譯成cpp(C++)文件,在探索方法的本質時,我們采用同樣的方法。

step1: 新建一個LBHPerson類并聲明兩個實例方法

//.h
@interface LBHPerson : NSObject

- (void)instanceMethod1;
- (void)instanceMethod2;

@end

//.m
@implementation LBHPerson

- (void)instanceMethod1
{
    NSLog(@"%s",__func__);
}

- (void)instanceMethod2
{
    NSLog(@"%s",__func__);
}

@end

step2:main函數中初始化LBHPerson并調用兩個實例方法

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        // insert code here...
        
        LBHPerson *person = [LBHPerson alloc];
        
        [person instanceMethod1];
        [person instanceMethod2];
        
        
    }
    return 0;
}

step3:main.m文件編譯成main.cpp文件,并找到main函數

int main(int argc, char * argv[]) {

    /* @autoreleasepool */ { __AtAutoreleasePool __autoreleasepool; 


        LBHPerson *person = ((LBHPerson *(*)(id, SEL))(void *)objc_msgSend)((id)objc_getClass("LBHPerson"), sel_registerName("alloc"));

        ((void (*)(id, SEL))(void *)objc_msgSend)((id)person, sel_registerName("instanceMethod1"));
        ((void (*)(id, SEL))(void *)objc_msgSend)((id)person, sel_registerName("instanceMethod2"));

    }
    return 0;
}

通過上述代碼可以看出,方法的本質就是objc_msgSend消息發送

能否驗證一下

當然可以

驗證方法的本質就是objc_msgSend消息發送

step1: 導入頭文件#import <objc/message.h>

step2: 需要將target --> Build Setting -->搜索msg -- 將enable strict checking of obc_msgSend callsYES改為NO,將嚴厲的檢查機制關掉,否則objc_msgSend的參數會報錯`

step3: 代碼編寫

LBHPerson *person = [LBHPerson alloc];       
[person instanceMethod1];
objc_msgSend(person, sel_registerName(@"instanceMethod1"));

step4: 運行查看打印結果

打印結果一直,說明[person instanceMethod1]等價于objc_msgSend(person, sel_registerName(@"instanceMethod1"))

調用父類方法

step1: 新建一個LBHTeacher類繼承于LBHPerson

@interface LBHTeacher : LBHPerson

@end

step2:main函數中調用

LBHPerson *person = [LBHPerson alloc];
[person instanceMethod1];

LBHTeacher *teacher = [LBHTeacher alloc];
        
struct objc_super lbhsuper;
lbhsuper.receiver = teacher;   
lbhsuper.super_class = [LBHTeacher class];   //告訴父類是誰
        
//消息的接受者還是自己 - 父類 - 請你直接找我的父親
objc_msgSendSuper(&lbhsuper, sel_registerName("instanceMethod1"));

step3: 運行查看打印結果

測試發現lbhsuper.super_class = [LBHTeacher class];lbhsuper.super_class = [LBHPerson class];結果是一樣的

應該是在給定的super_class中沒有找到對應的方法,會沿著繼承鏈向上尋找

總結
  • 方法的本質消息發送
  • OC調用方法等價于runtime中objc_msgSendobjc_msgSendSuper消息發送。

思考:objc_msgSend是怎樣找到對應的方法呢?即 sel 如何找到對應 imp

探索objc_msgSend

在objc4源碼中我們會發現objc_msgSend是使用匯編實現的,匯編主要的特性是:

* 速度快:匯編更容易被機器識別。
* 方法參數的動態性:匯編調用函數時傳遞的參數是不確定的,那么發送消息時,直接調用一個函數就可以發送所有的消息。

消息查找機制
  • 快速查找:cache中查找
  • 慢速查找:
    • methodList中查找
    • 消息轉發
objc_msgSend 匯編源碼

objc4-781源碼中,搜索objc_msgSend,由于我們日常開發的都是架構是arm64,所以需要在arm64.s后綴的文件中查找objc_msgSend源碼實現。

//---- 消息發送 -- 匯編入口--objc_msgSend主要是拿到接收者的isa信息
ENTRY _objc_msgSend 
//---- 無窗口
    UNWIND _objc_msgSend, NoFrame 
    
//---- p0 和空對比,即判斷接收者是否存在,其中p0是objc_msgSend的第一個參數-消息接收者receiver
    cmp p0, #0          // nil check and tagged pointer check 
//---- le小于 --支持taggedpointer(小對象類型)的流程
#if SUPPORT_TAGGED_POINTERS
    b.le    LNilOrTagged        //  (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

part1: 判斷objc_msgSend方法的第一個參數receiver是否為空

  • 【if】如果支持tagged pointer,跳轉至LNilOrTagged

    • 如果小對象為空,則直接返回空,即LReturnZero
    • 如果小對象不為空,則處理小對象的isa

part2:【else】receiver為空,則直接返回空,即LReturnZero`

part3: 如果即不是小對象receiver也不為空

  • receiver中取出isa存入p13寄存器
  • 通過 GetClassFromIsa_p16中,arm64架構下通過 isa & ISA_MASK 獲取shiftcls位域的類信息,即class,GetClassFromIsa_p16的匯編實現如下,然后走到part2
.macro GetClassFromIsa_p16 /* src */
//---- 此處用于watchOS
#if SUPPORT_INDEXED_ISA 
    // Indexed isa
//---- 將isa的值存入p16寄存器
    mov p16, $0         // optimistically set dst = src 
    tbz p16, #ISA_INDEX_IS_NPI_BIT, 1f  // done if not non-pointer isa -- 判斷是否是 nonapointer isa
    // isa in p16 is indexed
//---- 將_objc_indexed_classes所在的頁的基址 讀入x10寄存器
    adrp    x10, _objc_indexed_classes@PAGE 
//---- x10 = x10 + _objc_indexed_classes(page中的偏移量) --x10基址 根據 偏移量 進行 內存偏移
    add x10, x10, _objc_indexed_classes@PAGEOFF
//---- 從p16的第ISA_INDEX_SHIFT位開始,提取 ISA_INDEX_BITS 位 到 p16寄存器,剩余的高位用0補充
    ubfx    p16, p16, #ISA_INDEX_SHIFT, #ISA_INDEX_BITS  // extract index 
    ldr p16, [x10, p16, UXTP #PTRSHIFT] // load class from array
1:

//--用于64位系統
#elif __LP64__ 
    // 64-bit packed isa
//---- p16 = class = isa & ISA_MASK(位運算 & 即獲取isa中的shiftcls信息)
    and p16, $0, #ISA_MASK 

#else
    // 32-bit raw isa ---- 用于32位系統
    mov p16, $0

#endif

.endmacro
CacheLookup 緩存查找匯編源碼
//!!!!!!!!!重點!!!!!!!!!!!!
.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
//---- p11 = mask|buckets -- 從x16(即isa)中平移16字節,取出cache 存入p11寄存器 -- isa距離cache 正好16字節:isa(8字節)-superClass(8字節)-cache(mask高16位 + buckets低48位)
    ldr p11, [x16, #CACHE]              
//---- 64位真機
#if CACHE_MASK_STORAGE == CACHE_MASK_STORAGE_HIGH_16 
//--- p11(cache) & 0x0000ffffffffffff ,mask高16位抹零,得到buckets 存入p10寄存器-- 即去掉mask,留下buckets
    and p10, p11, #0x0000ffffffffffff   // p10 = buckets 
    
//--- p11(cache)右移48位,得到mask(即p11 存儲mask),mask & p1(msgSend的第二個參數 cmd-sel) ,得到sel-imp的下標index(即搜索下標) 存入p12(cache insert寫入時的哈希下標計算是 通過 sel & mask,讀取時也需要通過這種方式)
    and p12, p1, p11, LSR #48       // x12 = _cmd & mask 

//--- 非64位真機
#elif CACHE_MASK_STORAGE == CACHE_MASK_STORAGE_LOW_4 
    and p10, p11, #~0xf         // p10 = buckets
    and p11, p11, #0xf          // p11 = maskShift
    mov p12, #0xffff
    lsr p11, p12, p11               // p11 = mask = 0xffff >> p11
    and p12, p1, p11                // x12 = _cmd & mask
#else
#error Unsupported cache mask storage for ARM64.
#endif

//--- p12是下標 p10是buckets數組首地址,下標 * 1<<4(即16) 得到實際內存的偏移量,通過buckets的首地址偏移,獲取bucket存入p12寄存器
// PTRSHIFT 是一個宏定義,固定值為3  
//--- LSL #(1+PTRSHIFT)-- 表示左移4位,實際含義就是得到一個bucket占用的內存大小 -- 相當于mask = occupied -1-- _cmd & mask -- 取余數
    add p12, p10, p12, LSL #(1+PTRSHIFT)   
                     // p12 = buckets + ((_cmd & mask) << (1+PTRSHIFT)) -- PTRSHIFT是3
                     
//--- 從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

part1: 通過isa首地址平移16字節(因為在objc_class中,第一個元素isa8字節,第二個元素superClass8字節),獲取cache,cache中高16位存mask低48位存buckets,即p11 = cache

//---- p1 = SEL, p16 = isa --- #define CACHE (2 * __SIZEOF_POINTER__),其中 __SIZEOF_POINTER__表示pointer的大小 ,即 2*8 = 16
//---- p11 = mask|buckets -- 從x16(即isa)中平移16字節,取出cache 存入p11寄存器 -- isa距離cache 正好16字節:isa(8字節)-superClass(8字節)-cache(mask高16位 + buckets低48位)
    ldr p11, [x16, #CACHE]  

part2:cache中分別取出bucketsmask,并由mask根據哈希算法計算出哈希下標(只看64位真機)

//64位真機
#if CACHE_MASK_STORAGE == CACHE_MASK_STORAGE_HIGH_16 

2.1: 通過cache掩碼(即0x0000ffffffffffff)& 運算,將高16位mask抹零,得到buckets指針地址,即p10 = buckets

//--- p11(cache) & 0x0000ffffffffffff ,mask高16位抹零,得到buckets 存入p10寄存器-- 即去掉mask,留下buckets
    and p10, p11, #0x0000ffffffffffff   // p10 = buckets 

2.2:cache右移48位,得到mask,即p11 = mask, 將objc_msgSend參數p1(即第二個參數_cmd)& msak,通過哈希算法,得到需要查找存儲sel-impbucket下標index,即p12 = index = _cmd & mask

//--- p11(cache)右移48位,得到mask(即p11 存儲mask),mask & p1(msgSend的第二個參數 cmd-sel) ,得到sel-imp的下標index(即搜索下標) 存入p12(cache insert寫入時的哈希下標計算是 通過 sel & mask,讀取時也需要通過這種方式)
    and p12, p1, p11, LSR #48       // x12 = _cmd & mask 

為什么通過這種方式呢?

因為在存儲sel-imp時,也是通過同樣哈希算法計算哈希下標進行存儲,所以讀取也需要通過同樣的方式讀取,如下所示

part3: 根據所得的哈希下標indexbuckets首地址,取出哈希下標對應的bucket

//--- p12是下標 p10是buckets數組首地址,下標 <<4(即16) 得到實際內存的偏移量,每個 `bucket(sel 8字節 + imp 8字節)` 的大小為 16 字節,通過buckets的首地址偏移,獲取bucket存入p12寄存器
//--- LSL #(1+PTRSHIFT)-- 左移4位,實際含義就是得到一個bucket占用的內存大小 -- 相當于mask = occupied -1-- _cmd & mask -- 取余數
    add p12, p10, p12, LSL #(1+PTRSHIFT)   
// p12 = buckets + ((_cmd & mask) << (1+PTRSHIFT)) -- PTRSHIFT是3
                     
  • 其中PTRSHIFT等于3左移4位(即2^4 = 16字節)的目的是計算出一個bucket實際占用的大小結構體bucket_t中sel占8字節,imp占8字節
  • 根據計算的哈希下標index 乘以 單個bucket占用的內存大小,得到buckets首地址在實際內存中的偏移量
  • 通過首地址 + 實際偏移量,獲取哈希下標index對應的bucket

part4: 根據獲取的bucket,取出其中的imp存入p17,即p17 = imp,取出sel存入p9,即p9 = sel

//--- 從x12(即p12)中取出 bucket 分別將imp和sel 存入 p17(存儲imp) 和 p9(存儲sel)
    ldp p17, p9, [x12]      // {imp, sel} = *bucket 

part5: 第一次遞歸循環

//--- 比較 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 

5.1: 比較獲取的bucketselobjc_msgSend的第二個參數的_cmd(即p1)是否相等

5.1.1: 如果相等,則直接跳轉至CacheHit,即緩存命中,返回imp

//--- 如果相等 即cacheHit 緩存命中,直接返回imp
    CacheHit $0         // call or return imp 

5.1.2: 如果不相等,有以下兩種情況

//--- 如果不相等,即沒有找到,請跳轉至 2f
    b.ne    2f          //     scan more 


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 
  • 如果一直都找不到,直接跳轉至CheckMiss,因為$0normal,會跳轉至__objc_msgSend_uncached,即進入慢速查找流程
 // 如果為NORMAL ,則跳轉至 __objc_msgSend_uncached
    cbz p9, __objc_msgSend_uncached

// __objc_msgSend_uncached源碼
STATIC_ENTRY __objc_msgSend_uncached
UNWIND __objc_msgSend_uncached, FrameWithNoSaves

// THIS IS NOT A CALLABLE C FUNCTION
// Out-of-band p16 is the class to search
  
// 這里面最核心的邏輯就是 `MethodTableLookup`,查找方法列表。
MethodTableLookup
TailCallFunctionPointer x17

END_ENTRY __objc_msgSend_uncached

  • 如果根據index獲取的bucket 等于 buckets的第一個元素,則人為的將當前bucket設置為buckets的最后一個元素(通過buckets首地址+mask右移44位(等同于左移4位)直接定位到bucker的最后一個元素),然后繼續進行遞歸循環(第一個遞歸循環嵌套第二個遞歸循環),即part6
//--- 判斷p12(下標對應的bucket) 是否 等于 p10(buckets數組第一個元素)-- 表示前面已經沒有了,但是還是沒有找到
    cmp p12, p10        // wrap if bucket == buckets 
    b.eq    3f //如果等于,跳轉至第3步


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) 

part6: 第二次遞歸循環:重復part5的操作,與part5中唯一區別是,如果當前的bucket還是等于 buckets的第一個元素,則直接跳轉至JumpMiss,此時的$0normal,也是直接跳轉至__objc_msgSend_uncached,即進入慢速查找流程

//--- 從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 

快速查找過程值的變化過程

objc_msgSend 流程圖

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 227,488評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,034評論 3 414
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 175,327評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,554評論 1 307
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,337評論 6 404
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 54,883評論 1 321
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 42,975評論 3 439
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,114評論 0 286
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,625評論 1 332
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,555評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,737評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,244評論 5 355
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 43,973評論 3 345
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,362評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,615評論 1 280
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,343評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,699評論 2 370

推薦閱讀更多精彩內容