iOS 中的 block 是如何持有對象的

時間  2019-11-16
標籤 ios block 如何 持有 對象 欄目 iOS 简体版
原文   原文鏈接

關注倉庫，及時得到更新：iOS-Source-Code-Analyzegit

Follow: Draveness · Githubgithub

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，咱們可使用下面的代碼來獲取這個類：spa

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

原文連接: http://draveness.me/block-ret...

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程