iOS 中的 block 是如何持有物件的

Draveness發表於2019-02-25
iOSBloC物件

關注倉庫，及時獲得更新：iOS-Source-Code-Analyze

Follow: Draveness · Github

Block 是 Objective-C 中筆者最喜歡的特性，它為 Objective-C 這門語言提供了強大的函數語言程式設計能力，而最近蘋果推出的很多新的 API 都已經開始原生的支援 block 語法，可見它在 Objective-C 中變得越來越重要。

這篇文章並不會詳細介紹 block 在記憶體中到底是以什麼形式存在的，主要會介紹 block 是如何持有並且釋放物件的。文章中的程式碼都出自 Facebook 開源的用於檢測迴圈引用的框架 FBRetainCycleDetector，這是分析該框架文章中的最後一篇，也是筆者覺得最有意思的一部分。

如果你希望瞭解 FBRetainCycleDetector 的原理可以閱讀如何在 iOS 中解決迴圈引用的問題以及後續文章。

為什麼會談到 block

可能很多讀者會有這樣的疑問，本文既然是對 FBRetainCycleDetector 解析的文章，為什麼會提到 block？原因其實很簡單，因為在 iOS 開發中大多數的迴圈引用都是因為 block 使用不當導致的，由於 block 會 retain 它持有的物件，這樣就很容易造成迴圈引用，最終導致記憶體洩露。

在 FBRetainCycleDetector 中存在這樣一個類 FBObjectiveCBlock，這個類的 - allRetainedObjects 方法就會返回所有 block 持有的強引用，這也是文章需要關注的重點。

- (NSSet *)allRetainedObjects {
    NSMutableArray *results = [[[super allRetainedObjects] allObjects] mutableCopy];

    __attribute__((objc_precise_lifetime)) id anObject = self.object;

    void *blockObjectReference = (__bridge void *)anObject;
    NSArray *allRetainedReferences = FBGetBlockStrongReferences(blockObjectReference);

    for (id object in allRetainedReferences) {
        FBObjectiveCGraphElement *element = FBWrapObjectGraphElement(self, object, self.configuration);
        if (element) {
            [results addObject:element];
        }
    }

    return [NSSet setWithArray:results];
}複製程式碼

這部分程式碼中的大部分都不重要，只是在開頭呼叫父類方法，在最後將獲取的物件包裝成一個系列 FBObjectiveCGraphElement，最後返回一個陣列，也就是當前物件 block 持有的全部強引用了。

Block 是什麼？

對 block 稍微有了解的人都知道，block 其實是一個結構體，其結構大概是這樣的：

struct BlockLiteral {
    void *isa;
    int flags;
    int reserved;
    void (*invoke)(void *, ...);
    struct BlockDescriptor *descriptor;
};

struct BlockDescriptor {
    unsigned long int reserved;
    unsigned long int size;
    void (*copy_helper)(void *dst, void *src);
    void (*dispose_helper)(void *src);
    const char *signature;
};複製程式碼

在 BlockLiteral 結構體中有一個 isa 指標，而對 isa瞭解的人也都知道，這裡的 isa 其實指向了一個類，每一個 block 指向的類可能是 __NSGlobalBlock__、__NSMallocBlock__ 或者 __NSStackBlock__，但是這些 block，它們繼承自一個共同的父類，也就是 NSBlock，我們可以使用下面的程式碼來獲取這個類：

static Class _BlockClass() {
    static dispatch_once_t onceToken;
    static Class blockClass;
    dispatch_once(&onceToken, ^{
        void (^testBlock)() = [^{} copy];
        blockClass = [testBlock class];
        while(class_getSuperclass(blockClass) && class_getSuperclass(blockClass) != [NSObject class]) {
            blockClass = class_getSuperclass(blockClass);
        }
        [testBlock release];
    });
    return blockClass;
}複製程式碼

Objective-C 中的三種 block __NSMallocBlock__、__NSStackBlock__ 和 __NSGlobalBlock__ 會在下面的情況下出現：

ARC 非 ARC
捕獲外部變數 __NSMallocBlock__
__NSStackBlock__		 __NSStackBlock__
未捕獲外部變數 __NSGlobalBlock__ __NSGlobalBlock__
  • 在 ARC 中，捕獲外部了變數的 block 的類會是 __NSMallocBlock__ 或者 __NSStackBlock__，如果 block 被賦值給了某個變數在這個過程中會執行 _Block_copy 將原有的 __NSStackBlock__ 變成 __NSMallocBlock__；但是如果 block 沒有被賦值給某個變數，那它的型別就是 __NSStackBlock__；沒有捕獲外部變數的 block 的類會是 __NSGlobalBlock__ 即不在堆上，也不在棧上，它類似 C 語言函式一樣會在程式碼段中。
  • 在非 ARC 中，捕獲了外部變數的 block 的類會是 __NSStackBlock__，放置在棧上，沒有捕獲外部變數的 block 時與 ARC 環境下情況相同。

如果我們不斷列印一個 block 的 superclass 的話最後就會在繼承鏈中找到 NSBlock 的身影：

block-superclass

然後可以通過這種辦法來判斷當前物件是不是 block：

BOOL FBObjectIsBlock(void *object) {
    Class blockClass = _BlockClass();

    Class candidate = object_getClass((__bridge id)object);
    return [candidate isSubclassOfClass:blockClass];
}複製程式碼

Block 如何持有物件

在這一小節，我們將討論 block 是如何持有物件的，我們會通過對 FBRetainCycleDetector 的原始碼進行分析最後儘量詳盡地回答這一問題。

重新回到文章開頭提到的 - allRetainedObjects 方法：

- (NSSet *)allRetainedObjects {
    NSMutableArray *results = [[[super allRetainedObjects] allObjects] mutableCopy];

    __attribute__((objc_precise_lifetime)) id anObject = self.object;

    void *blockObjectReference = (__bridge void *)anObject;
    NSArray *allRetainedReferences = FBGetBlockStrongReferences(blockObjectReference);

    for (id object in allRetainedReferences) {
        FBObjectiveCGraphElement *element = FBWrapObjectGraphElement(self, object, self.configuration);
        if (element) {
            [results addObject:element];
        }
    }

    return [NSSet setWithArray:results];
}複製程式碼

通過函式的符號我們也能夠猜測出，上述方法中通過 FBGetBlockStrongReferences 獲取 block 持有的所有強引用：

NSArray *FBGetBlockStrongReferences(void *block) {
    if (!FBObjectIsBlock(block)) {
        return nil;
    }

    NSMutableArray *results = [NSMutableArray new];

    void **blockReference = block;
    NSIndexSet *strongLayout = _GetBlockStrongLayout(block);
    [strongLayout enumerateIndexesUsingBlock:^(NSUInteger idx, BOOL *stop) {
        void **reference = &blockReference[idx];

        if (reference && (*reference)) {
            id object = (id)(*reference);

            if (object) {
                [results addObject:object];
            }
        }
    }];

    return [results autorelease];
}複製程式碼

而 FBGetBlockStrongReferences 是對另一個私有函式 _GetBlockStrongLayout 的封裝，也是實現最有意思的部分。

幾個必要的概念

在具體介紹 _GetBlockStrongLayout 函式的原始碼之前，我希望先對其原理有一個簡單的介紹，便於各位讀者的理解；在這裡有三個概念需要介紹，首先是 block 持有的物件都存在的位置。

如何持有物件

在文章的上面曾經出現過 block 的結構體，不知道各位讀者是否還有印象：

struct BlockLiteral {
    void *isa;
    int flags;
    int reserved;
    void (*invoke)(void *, ...);
    struct BlockDescriptor *descriptor;
    // imported variables
};複製程式碼

在每個 block 結構體的下面就會存放當前 block 持有的所有物件，無論強弱。我們可以做一個小實驗來驗證這個觀點，我們在程式中宣告這樣一個 block：

NSObject *firstObject = [NSObject new];
__attribute__((objc_precise_lifetime)) NSObject *object = [NSObject new];
__weak NSObject *secondObject = object;
NSObject *thirdObject = [NSObject new];

__unused void (^block)() = ^{
    __unused NSObject *first = firstObject;
    __unused NSObject *second = secondObject;
    __unused NSObject *third = thirdObject;
};複製程式碼

然後在程式碼中打一個斷點：

block-capture-var-layout

上面程式碼中 block 由於被變數引用，執行了 _Block_copy，所以其型別為 __NSMallocBlock__，沒有被變數引用的 block 都是 __NSStackBlock__。

  1. 首先列印 block 變數的大小，因為 block 變數其實只是一個指向結構體的指標，所以大小為 8，而結構體的大小為 32；
  2. 以 block 的地址為基址，偏移 32，得到一個指標
  3. 使用 $3[0] $3[1] $3[2] 依次列印地址為 0x1001023b0 0x1001023b8 0x1001023c0 的內容，可以發現它們就是 block 捕獲的全部引用，前兩個是強引用，最後的是弱引用

這可以得出一個結論：block 將其捕獲的引用存放在結構體的下面，但是為什麼這裡的順序並不是按照引用的順序呢？接下來增加幾個變數，再做另一次實驗：

block-capture-strong-weak-orde

在程式碼中多加入了幾個物件之後，block 對持有的物件的佈局的順序依然是強引用在前、弱引用在後，我們不妨做一個假設：block 會將強引用的物件排放在弱引用物件的前面。但是這個假設能夠幫助我們在只有 block 但是沒有上下文資訊的情況下區分哪些是強引用麼？我覺得並不能，因為我們沒有辦法知道它們之間的分界線到底在哪裡。

dispose_helper

第二個需要介紹的是 dispose_helper，這是 BlockDescriptor 結構體中的一個指標：

struct BlockDescriptor {
    unsigned long int reserved;                // NULL
    unsigned long int size;
    // optional helper functions
    void (*copy_helper)(void *dst, void *src); // IFF (1<<25)
    void (*dispose_helper)(void *src);         // IFF (1<<25)
    const char *signature;                     // IFF (1<<30)
};複製程式碼

上面的結構體中有兩個函式指標，copy_helper 用於 block 的拷貝，dispose_helper 用於 block 的 dispose 也就是 block 在析構的時候會呼叫這個函式指標，銷燬自己持有的物件，而這個原理也是區別強弱引用的關鍵，因為在 dispose_helper 會對強引用傳送 release 訊息，對弱引用不會做任何的處理。

FBBlockStrongRelationDetector

最後就是用於從 dispose_helper 接收訊息的類 FBBlockStrongRelationDetector 了；它的例項在接受 release 訊息時，並不會真正的釋放，只會將標記 _strong 為 YES：

- (oneway void)release {
    _strong = YES;
}

- (oneway void)trueRelease {
    [super release];
}複製程式碼

只有真正執行 trueRelease 的時候才會向物件傳送 release 訊息。

因為這個檔案覆寫了 release 方法，所以要在非 ARC 下編譯：

#if __has_feature(objc_arc)
#error This file must be compiled with MRR. Use -fno-objc-arc flag.
#endif複製程式碼

如果 block 持有了另一個 block 物件，FBBlockStrongRelationDetector 也可以將自身 fake 成為一個假的 block 防止在接收到關於 block 釋放的訊息時發生 crash：

struct _block_byref_block;
@interface FBBlockStrongRelationDetector : NSObject {
    // __block fakery
    void *forwarding;
    int flags;   //refcount;
    int size;
    void (*byref_keep)(struct _block_byref_block *dst, struct _block_byref_block *src);
    void (*byref_dispose)(struct _block_byref_block *);
    void *captured[16];
}複製程式碼

該類的例項在初始化時，會設定 forwarding、byref_keep 和 byref_dispose，後兩個方法的實現都是空的，只是為了防止 crash：

+ (id)alloc {
    FBBlockStrongRelationDetector *obj = [super alloc];

    // Setting up block fakery
    obj->forwarding = obj;
    obj->byref_keep = byref_keep_nop;
    obj->byref_dispose = byref_dispose_nop;

    return obj;
}

static void byref_keep_nop(struct _block_byref_block *dst, struct _block_byref_block *src) {}
static void byref_dispose_nop(struct _block_byref_block *param) {}複製程式碼

獲取 block 強引用的物件

到現在為止，獲取 block 強引用物件所需要的知識都介紹完了，接下來可以對私有方法 _GetBlockStrongLayout 進行分析了：

static NSIndexSet *_GetBlockStrongLayout(void *block) {
    struct BlockLiteral *blockLiteral = block;

    if ((blockLiteral->flags & BLOCK_HAS_CTOR)
        || !(blockLiteral->flags & BLOCK_HAS_COPY_DISPOSE)) {
        return nil;
    }

    ...
}複製程式碼
  • 如果 block 有 Cpp 的構造器/析構器，說明它持有的物件很有可能沒有按照指標大小對齊，我們很難檢測到所有的物件
  • 如果 block 沒有 dispose 函式，說明它無法 retain 物件，也就是說我們也沒有辦法測試其強引用了哪些物件
static NSIndexSet *_GetBlockStrongLayout(void *block) {
    ...
    void (*dispose_helper)(void *src) = blockLiteral->descriptor->dispose_helper;
    const size_t ptrSize = sizeof(void *);    
    const size_t elements = (blockLiteral->descriptor->size + ptrSize - 1) / ptrSize;

    void *obj[elements];
    void *detectors[elements];

    for (size_t i = 0; i < elements; ++i) {
        FBBlockStrongRelationDetector *detector = [FBBlockStrongRelationDetector new];
        obj[i] = detectors[i] = detector;
    }

    @autoreleasepool {
        dispose_helper(obj);
    }
    ...
}複製程式碼
  1. 從 BlockDescriptor 取出 dispose_helper 以及 size（block 持有的所有物件的大小）
  2. 通過 (blockLiteral->descriptor->size + ptrSize - 1) / ptrSize 向上取整，獲取 block 持有的指標的數量
  3. 初始化兩個包含 elements 個 FBBlockStrongRelationDetector 例項的陣列，其中第一個陣列用於傳入 dispose_helper，第二個陣列用於檢測 _strong 是否被標記為 YES
  4. 在自動釋放池中執行 dispose_helper(obj)，釋放 block 持有的物件
static NSIndexSet *_GetBlockStrongLayout(void *block) {
    ...
    NSMutableIndexSet *layout = [NSMutableIndexSet indexSet];

    for (size_t i = 0; i < elements; ++i) {
        FBBlockStrongRelationDetector *detector = (FBBlockStrongRelationDetector *)(detectors[i]);
        if (detector.isStrong) {
            [layout addIndex:i];
        }

        [detector trueRelease];
    }

    return layout;
}複製程式碼

因為 dispose_helper 只會呼叫 release 方法，但是這並不會導致我們的 FBBlockStrongRelationDetector 例項被釋放掉，反而會標記 _string 屬性，在這裡我們只需要判斷這個屬性的真假，將對應索引加入陣列，最後再呼叫 trueRelease 真正的釋放物件。

我們可以執行下面的程式碼，分析其工作過程：

NSObject *firstObject = [NSObject new];
__attribute__((objc_precise_lifetime)) NSObject *object = [NSObject new];
__weak NSObject *secondObject = object;
NSObject *thirdObject = [NSObject new];

__unused void (^block)() = ^{
    __unused NSObject *first = firstObject;
    __unused NSObject *second = secondObject;
    __unused NSObject *third = thirdObject;
};

FBRetainCycleDetector *detector = [FBRetainCycleDetector new];
[detector addCandidate:block];
[detector findRetainCycles];複製程式碼

在 dispose_helper 呼叫之前：

before-dispose-helpe

obj 陣列中的每一個位置都儲存了 FBBlockStrongRelationDetector 的例項，但是在 dispose_helper 呼叫之後：

after-dispose-helpe

索引為 4 和 5 處的例項已經被清空了，這裡對應的 FBBlockStrongRelationDetector 例項的 strong 已經被標記為 YES、加入到陣列中並返回；最後也就獲取了所有強引用的索引，同時得到了 block 強引用的物件。

總結

其實最開始筆者對這個 dispose_helper 實現的機制並不是特別的肯定，只是有一個猜測，但是在詢問了 FBBlockStrongRelationDetector 的作者之後，才確定 dispose_helper 確實會負責向所有捕獲的變數傳送 release 訊息，如果有興趣可以看這個 issue。這部分的程式碼其實最開始源於 mikeash 大神的 Circle，不過對於他是如何發現這一點的，筆者並不清楚，如果各位有相關的資料或者合理的解釋，可以隨時聯絡我。

關注倉庫，及時獲得更新：iOS-Source-Code-Analyze

Follow: Draveness · Github

原文連結: draveness.me/block-retai…

相關文章