关注仓库,及时得到更新:iOS-Source-Code-Analyzegit
Follow: Draveness · Githubgithub
Block 是 Objective-C 中笔者最喜欢的特性,它为 Objective-C 这门语言提供了强大的函数式编程能力,而最近苹果推出的不少新的 API 都已经开始原生的支持 block 语法,可见它在 Objective-C 中变得愈来愈重要。编程
这篇文章并不会详细介绍 block 在内存中究竟是以什么形式存在的,主要会介绍 block 是如何持有而且释放对象的。文章中的代码都出自 Facebook 开源的用于检测循环引用的框架 FBRetainCycleDetector,这是分析该框架文章中的最后一篇,也是笔者以为最有意思的一部分。数组
若是你但愿了解 FBRetainCycleDetector 的原理能够阅读如何在 iOS 中解决循环引用的问题以及后续文章。框架
可能不少读者会有这样的疑问,本文既然是对 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 实际上是一个结构体,其结构大概是这样的:测试
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:
BOOL FBObjectIsBlock(void *object) { Class blockClass = _BlockClass(); Class candidate = object_getClass((__bridge id)object); return [candidate isSubclassOfClass:blockClass]; }
在这一小节,咱们将讨论 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 因为被变量引用,执行了
_Block_copy
,因此其类型为__NSMallocBlock__
,没有被变量引用的 block 都是__NSStackBlock__
。
首先打印 block 变量的大小,由于 block 变量其实只是一个指向结构体的指针,因此大小为 8,而结构体的大小为 32;
以 block 的地址为基址,偏移 32,获得一个指针
使用 $3[0]
$3[1]
$3[2]
依次打印地址为 0x1001023b0
0x1001023b8
0x1001023c0
的内容,能够发现它们就是 block 捕获的所有引用,前两个是强引用,最后的是弱引用
这能够得出一个结论:block 将其捕获的引用存放在结构体的下面,可是为何这里的顺序并非按照引用的顺序呢?接下来增长几个变量,再作另外一次实验:
在代码中多加入了几个对象以后,block 对持有的对象的布局的顺序依然是强引用在前、弱引用在后,咱们不妨作一个假设:block 会将强引用的对象排放在弱引用对象的前面。可是这个假设可以帮助咱们在只有 block 可是没有上下文信息的状况下区分哪些是强引用么?我以为并不能,由于咱们没有办法知道它们之间的分界线到底在哪里。
第二个须要介绍的是 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
消息,对弱引用不会作任何的处理。
最后就是用于从 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 强引用对象所须要的知识都介绍完了,接下来能够对私有方法 _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); } ... }
从 BlockDescriptor
取出 dispose_helper
以及 size
(block 持有的全部对象的大小)
经过 (blockLiteral->descriptor->size + ptrSize - 1) / ptrSize
向上取整,获取 block 持有的指针的数量
初始化两个包含 elements
个 FBBlockStrongRelationDetector
实例的数组,其中第一个数组用于传入 dispose_helper
,第二个数组用于检测 _strong
是否被标记为 YES
在自动释放池中执行 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
调用以前:
obj
数组中的每个位置都存储了 FBBlockStrongRelationDetector
的实例,可是在 dispose_helper
调用以后:
索引为 4 和 5 处的实例已经被清空了,这里对应的 FBBlockStrongRelationDetector
实例的 strong
已经被标记为 YES
、加入到数组中并返回;最后也就获取了全部强引用的索引,同时获得了 block 强引用的对象。
其实最开始笔者对这个 dispose_helper
实现的机制并非特别的确定,只是有一个猜想,可是在询问了 FBBlockStrongRelationDetector
的做者以后,才肯定 dispose_helper
确实会负责向全部捕获的变量发送 release
消息,若是有兴趣能够看这个 issue。这部分的代码其实最开始源于 mikeash 大神的 Circle,不过对于他是如何发现这一点的,笔者并不清楚,若是各位有相关的资料或者合理的解释,能够随时联系我。
关注仓库,及时得到更新:iOS-Source-Code-Analyze
Follow: Draveness · Github