關(guān)注倉(cāng)庫(kù)脱吱，及時(shí)獲得更新：iOS-Source-Code-Analyze
Follow: Draveness · Github
Block 是 Objective-C 中筆者最喜歡的特性箱蝠，它為 Objective-C 這門(mén)語(yǔ)言提供了強(qiáng)大的函數(shù)式編程能力宦搬，而最近蘋(píng)果推出的很多新的 API 都已經(jīng)開(kāi)始原生的支持 block 語(yǔ)法间校，可見(jiàn)它在 Objective-C 中變得越來(lái)越重要撇簿。
這篇文章并不會(huì)詳細(xì)介紹 block 在內(nèi)存中到底是以什么形式存在的差购，主要會(huì)介紹 block 是如何持有并且釋放對(duì)象的欲逃。文章中的代碼都出自 Facebook 開(kāi)源的用于檢測(cè)循環(huán)引用的框架 FBRetainCycleDetector稳析，這是分析該框架文章中的最后一篇彰居，也是筆者覺(jué)得最有意思的一部分。
如果你希望了解 FBRetainCycleDetector 的原理可以閱讀如何在 iOS 中解決循環(huán)引用的問(wèn)題以及后續(xù)文章畦徘。
為什么會(huì)談到 block
可能很多讀者會(huì)有這樣的疑問(wèn)井辆，本文既然是對(duì) FBRetainCycleDetector 解析的文章杯缺，為什么會(huì)提到 block萍肆？原因其實(shí)很簡(jiǎn)單塘揣，因?yàn)樵?iOS 開(kāi)發(fā)中大多數(shù)的循環(huán)引用都是因?yàn)?block 使用不當(dāng)導(dǎo)致的，由于 block 會(huì) retain 它持有的對(duì)象馏艾，這樣就很容易造成循環(huán)引用琅摩，最終導(dǎo)致內(nèi)存泄露房资。
在 FBRetainCycleDetector 中存在這樣一個(gè)類(lèi) FBObjectiveCBlock轰异，這個(gè)類(lèi)的 - allRetainedObjects 方法就會(huì)返回所有 block 持有的強(qiáng)引用暑始，這也是文章需要關(guān)注的重點(diǎn)廊镜。
- (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];
}
這部分代碼中的大部分都不重要嗤朴，只是在開(kāi)頭調(diào)用父類(lèi)方法，在最后將獲取的對(duì)象包裝成一個(gè)系列 FBObjectiveCGraphElement股缸，最后返回一個(gè)數(shù)組敦姻，也就是當(dāng)前對(duì)象 block 持有的全部強(qiáng)引用了替劈。
Block 是什么陨献？
對(duì) block 稍微有了解的人都知道眨业，block 其實(shí)是一個(gè)結(jié)構(gòu)體，其結(jié)構(gòu)大概是這樣的：
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 結(jié)構(gòu)體中有一個(gè) isa 指針，而對(duì) isa了解的人也都知道聘殖，這里的 isa 其實(shí)指向了一個(gè)類(lèi)奸腺，每一個(gè) block 指向的類(lèi)可能是 __NSGlobalBlock__突照、__NSMallocBlock__ 或者 __NSStackBlock__讹蘑，但是這些 block座慰，它們繼承自一個(gè)共同的父類(lèi)角骤，也就是 NSBlock邦尊，我們可以使用下面的代碼來(lái)獲取這個(gè)類(lèi)：
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__ 會(huì)在下面的情況下出現(xiàn)：
| ARC | 非 ARC | |
|---|---|---|
| 捕獲外部變量 |
__NSMallocBlock__ __NSStackBlock__
|
__NSStackBlock__ |
| 未捕獲外部變量 | __NSGlobalBlock__ |
__NSGlobalBlock__ |
- 在 ARC 中又沾，捕獲外部了變量的 block 的類(lèi)會(huì)是
__NSMallocBlock__或者__NSStackBlock__杖刷，如果 block 被賦值給了某個(gè)變量在這個(gè)過(guò)程中會(huì)執(zhí)行_Block_copy將原有的__NSStackBlock__變成__NSMallocBlock__滑燃；但是如果 block 沒(méi)有被賦值給某個(gè)變量，那它的類(lèi)型就是__NSStackBlock__典予；沒(méi)有捕獲外部變量的 block 的類(lèi)會(huì)是__NSGlobalBlock__即不在堆上瘤袖，也不在棧上捂敌，它類(lèi)似 C 語(yǔ)言函數(shù)一樣會(huì)在代碼段中黍匾。 - 在非 ARC 中锐涯，捕獲了外部變量的 block 的類(lèi)會(huì)是
__NSStackBlock__纹腌，放置在棧上升薯，沒(méi)有捕獲外部變量的 block 時(shí)與 ARC 環(huán)境下情況相同涎劈。
如果我們不斷打印一個(gè) block 的 superclass 的話(huà)最后就會(huì)在繼承鏈中找到 NSBlock 的身影：
然后可以通過(guò)這種辦法來(lái)判斷當(dāng)前對(duì)象是不是 block：
BOOL FBObjectIsBlock(void *object) {
Class blockClass = _BlockClass();
Class candidate = object_getClass((__bridge id)object);
return [candidate isSubclassOfClass:blockClass];
}
Block 如何持有對(duì)象
在這一小節(jié)蛛枚，我們將討論 block 是如何持有對(duì)象的蹦浦，我們會(huì)通過(guò)對(duì) FBRetainCycleDetector 的源代碼進(jìn)行分析最后盡量詳盡地回答這一問(wèn)題盲镶。
重新回到文章開(kāi)頭提到的 - 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];
}
通過(guò)函數(shù)的符號(hào)我們也能夠猜測(cè)出溉贿，上述方法中通過(guò) FBGetBlockStrongReferences 獲取 block 持有的所有強(qiáng)引用：
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 是對(duì)另一個(gè)私有函數(shù) _GetBlockStrongLayout 的封裝宇色，也是實(shí)現(xiàn)最有意思的部分代兵。
幾個(gè)必要的概念
在具體介紹 _GetBlockStrongLayout 函數(shù)的源代碼之前植影，我希望先對(duì)其原理有一個(gè)簡(jiǎn)單的介紹，便于各位讀者的理解鹿响；在這里有三個(gè)概念需要介紹惶我，首先是 block 持有的對(duì)象都存在的位置绸贡。
如何持有對(duì)象
在文章的上面曾經(jīng)出現(xiàn)過(guò) block 的結(jié)構(gòu)體听怕，不知道各位讀者是否還有印象：
struct BlockLiteral {
void *isa;
int flags;
int reserved;
void (*invoke)(void *, ...);
struct BlockDescriptor *descriptor;
// imported variables
};
在每個(gè) block 結(jié)構(gòu)體的下面就會(huì)存放當(dāng)前 block 持有的所有對(duì)象尿瞭，無(wú)論強(qiáng)弱声搁。我們可以做一個(gè)小實(shí)驗(yàn)來(lái)驗(yàn)證這個(gè)觀點(diǎn)捕发，我們?cè)诔绦蛑新暶鬟@樣一個(gè) 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;
};
然后在代碼中打一個(gè)斷點(diǎn)：
上面代碼中 block 由于被變量引用疏旨，執(zhí)行了
_Block_copy，所以其類(lèi)型為__NSMallocBlock__爬骤，沒(méi)有被變量引用的 block 都是__NSStackBlock__充石。
- 首先打印 block 變量的大小，因?yàn)?block 變量其實(shí)只是一個(gè)指向結(jié)構(gòu)體的指針霞玄，所以大小為 8骤铃，而結(jié)構(gòu)體的大小為 32坷剧；
- 以 block 的地址為基址惰爬，偏移 32，得到一個(gè)指針
- 使用
$3[0]$3[1]$3[2]依次打印地址為0x1001023b00x1001023b80x1001023c0的內(nèi)容惫企，可以發(fā)現(xiàn)它們就是 block 捕獲的全部引用撕瞧，前兩個(gè)是強(qiáng)引用，最后的是弱引用
這可以得出一個(gè)結(jié)論：block 將其捕獲的引用存放在結(jié)構(gòu)體的下面狞尔，但是為什么這里的順序并不是按照引用的順序呢丛版？接下來(lái)增加幾個(gè)變量，再做另一次實(shí)驗(yàn)：
在代碼中多加入了幾個(gè)對(duì)象之后偏序，block 對(duì)持有的對(duì)象的布局的順序依然是強(qiáng)引用在前页畦、弱引用在后，我們不妨做一個(gè)假設(shè)：block 會(huì)將強(qiáng)引用的對(duì)象排放在弱引用對(duì)象的前面研儒。但是這個(gè)假設(shè)能夠幫助我們?cè)?strong>只有 block 但是沒(méi)有上下文信息的情況下區(qū)分哪些是強(qiáng)引用么豫缨？我覺(jué)得并不能，因?yàn)槲覀儧](méi)有辦法知道它們之間的分界線(xiàn)到底在哪里端朵。
dispose_helper
第二個(gè)需要介紹的是 dispose_helper好芭，這是 BlockDescriptor 結(jié)構(gòu)體中的一個(gè)指針：
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)
};
上面的結(jié)構(gòu)體中有兩個(gè)函數(shù)指針，copy_helper 用于 block 的拷貝冲呢，dispose_helper 用于 block 的 dispose 也就是 block 在析構(gòu)的時(shí)候會(huì)調(diào)用這個(gè)函數(shù)指針舍败，銷(xiāo)毀自己持有的對(duì)象，而這個(gè)原理也是區(qū)別強(qiáng)弱引用的關(guān)鍵敬拓，因?yàn)樵?dispose_helper 會(huì)對(duì)強(qiáng)引用發(fā)送 release 消息瓤湘，對(duì)弱引用不會(huì)做任何的處理。
FBBlockStrongRelationDetector
最后就是用于從 dispose_helper 接收消息的類(lèi) FBBlockStrongRelationDetector 了恩尾；它的實(shí)例在接受 release 消息時(shí)弛说，并不會(huì)真正的釋放，只會(huì)將標(biāo)記 _strong 為 YES：
- (oneway void)release {
_strong = YES;
}
- (oneway void)trueRelease {
[super release];
}
只有真正執(zhí)行 trueRelease 的時(shí)候才會(huì)向?qū)ο蟀l(fā)送 release 消息翰意。
因?yàn)檫@個(gè)文件覆寫(xiě)了 release 方法木人，所以要在非 ARC 下編譯：
#if __has_feature(objc_arc)
#error This file must be compiled with MRR. Use -fno-objc-arc flag.
#endif
如果 block 持有了另一個(gè) block 對(duì)象，FBBlockStrongRelationDetector 也可以將自身 fake 成為一個(gè)假的 block 防止在接收到關(guān)于 block 釋放的消息時(shí)發(fā)生 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];
}
該類(lèi)的實(shí)例在初始化時(shí)冀偶，會(huì)設(shè)置 forwarding醒第、byref_keep 和 byref_dispose，后兩個(gè)方法的實(shí)現(xiàn)都是空的进鸠，只是為了防止 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 強(qiáng)引用的對(duì)象
到現(xiàn)在為止稠曼，獲取 block 強(qiáng)引用對(duì)象所需要的知識(shí)都介紹完了，接下來(lái)可以對(duì)私有方法 _GetBlockStrongLayout 進(jìn)行分析了：
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 的構(gòu)造器/析構(gòu)器客年，說(shuō)明它持有的對(duì)象很有可能沒(méi)有按照指針大小對(duì)齊霞幅，我們很難檢測(cè)到所有的對(duì)象
- 如果 block 沒(méi)有
dispose函數(shù)漠吻，說(shuō)明它無(wú)法retain對(duì)象，也就是說(shuō)我們也沒(méi)有辦法測(cè)試其強(qiáng)引用了哪些對(duì)象
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);
}
...
}
- 從
BlockDescriptor取出dispose_helper以及size（block 持有的所有對(duì)象的大兴究摇） - 通過(guò)
(blockLiteral->descriptor->size + ptrSize - 1) / ptrSize向上取整途乃，獲取 block 持有的指針的數(shù)量 - 初始化兩個(gè)包含
elements個(gè)FBBlockStrongRelationDetector實(shí)例的數(shù)組，其中第一個(gè)數(shù)組用于傳入dispose_helper扔傅，第二個(gè)數(shù)組用于檢測(cè)_strong是否被標(biāo)記為YES - 在自動(dòng)釋放池中執(zhí)行
dispose_helper(obj)耍共，釋放 block 持有的對(duì)象
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;
}
因?yàn)?dispose_helper 只會(huì)調(diào)用 release 方法，但是這并不會(huì)導(dǎo)致我們的 FBBlockStrongRelationDetector 實(shí)例被釋放掉猎塞，反而會(huì)標(biāo)記 _string 屬性试读，在這里我們只需要判斷這個(gè)屬性的真假，將對(duì)應(yīng)索引加入數(shù)組荠耽，最后再調(diào)用 trueRelease 真正的釋放對(duì)象钩骇。
我們可以執(zhí)行下面的代碼，分析其工作過(guò)程：
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 調(diào)用之前：
obj 數(shù)組中的每一個(gè)位置都存儲(chǔ)了 FBBlockStrongRelationDetector 的實(shí)例骇塘，但是在 dispose_helper 調(diào)用之后：
索引為 4 和 5 處的實(shí)例已經(jīng)被清空了伊履，這里對(duì)應(yīng)的 FBBlockStrongRelationDetector 實(shí)例的 strong 已經(jīng)被標(biāo)記為 YES、加入到數(shù)組中并返回款违；最后也就獲取了所有強(qiáng)引用的索引唐瀑，同時(shí)得到了 block 強(qiáng)引用的對(duì)象。
總結(jié)
其實(shí)最開(kāi)始筆者對(duì)這個(gè) dispose_helper 實(shí)現(xiàn)的機(jī)制并不是特別的肯定插爹，只是有一個(gè)猜測(cè)哄辣，但是在詢(xún)問(wèn)了 FBBlockStrongRelationDetector 的作者之后，才確定 dispose_helper 確實(shí)會(huì)負(fù)責(zé)向所有捕獲的變量發(fā)送 release 消息赠尾，如果有興趣可以看這個(gè) issue力穗。這部分的代碼其實(shí)最開(kāi)始源于 mikeash 大神的 Circle，不過(guò)對(duì)于他是如何發(fā)現(xiàn)這一點(diǎn)的气嫁，筆者并不清楚当窗，如果各位有相關(guān)的資料或者合理的解釋?zhuān)梢噪S時(shí)聯(lián)系我。
關(guān)注倉(cāng)庫(kù)寸宵，及時(shí)獲得更新：iOS-Source-Code-Analyze
Follow: Draveness · Github
