一:block内部可能存在的self的集中使用情况
(1)什么时候在 block 里面用 self，不需要使用 weak self？
当 block 本身不被 self 持有，而被别的对象持有，同时不产生循环引用的时候，就不需要使用 weak self 了。最常见的代码就是 UIView 的动画代码，我们在使用 UIView 的 animateWithDuration:animations 方法 做动画的时候，并不需要使用 weak self，因为引用持有关系是：UIView 的某个负责动画的对象持有了 block
block 持有了 self
因为 self 并不持有 block，所以就没有循环引用产生，因为就不需要使用 weak self 了。
(2)有没有这样一个需求场景，block 会产生循环引用，但是业务又需要你不能使用 weak self? 如果有，请举一个例子并且解释这种情况下如何解决循环引用问题。
需要不使用 weak self 的场景是：
例如 : 在使用NSOperation进行异步下载网络图片的方法,然后在主线程进行显示的时候,在将操作添加到队列的步奏 中,因为操作是由block构成的,在block内部先实现异步下载图片,然后在主线程中加载图片,刷新self.tableview的操作,此时因为self.queue 引用操作block,block内部又引用self,构成循环引用;我们只要在将操作block添加到queue之后,将其果断致为nil,就可以解除循环引用了
总结来说，解决循环引用问题主要有两个办法：
代码如下:
// 已知 : op->self(VC)
self.myblock = ^{
NSLog(@"从网络中加载...%@",app.name);
// 模拟网络延迟
if (indexPath.row > 9) {
[NSThread sleepForTimeInterval:10];
}
// 同步下载图片
NSURL *url = [NSURL URLWithString:app.icon];
NSData *data = [NSData dataWithContentsOfURL:url];
UIImage *image = [UIImage imageWithData:data];
// 图片下载完成之后,回到主线程更新UI
[[NSOperationQueue mainQueue] addOperationWithBlock:^{
if (image != nil) {
// 将图片保存到图片缓存中(dict),内存缓存策略
// 字典和数组赋值空对象
[self.imageCache setObject:image forKey:app.icon];
// 刷新对应的行
[self.tableView reloadRowsAtIndexPaths:@[indexPath] withRowAnimation:UITableViewRowAnimationNone];
// 移除操作,当图片为nil不能移除op
}
// 移除操作
[self.operationCache removeObjectForKey:app.icon];
}];
};
NSBlockOperation *op = [NSBlockOperation blockOperationWithBlock:_myblock];
#pragma attention 此处打破block循环的关键,在使用完block后果断将其指为nil
self.myblock = nil;
// 将操作添加到操作缓存
[self.operationCache setObject:op forKey:app.icon];
// 将操作添加到队列
[self.queue addOperation:op];
第一个办法是「事前避免」，我们在会产生循环引用的地方使用 weak 弱引用，以避免产生循环引用。
第二个办法是「事后补救」，我们明确知道会存在循环引用，但是我们在合理的位置主动断开环中的一个引用，使得对象得以回收。
二:如何检测block内部是否存在循环引用
<1>利用第三方框架FBRetainCycleDetector
demo下载地址
看到facebook的一套内存泄漏检测工具，感觉不错，想要查看原文可以点击这里，后续在去分析相关的开源工具FBRetainCycleDetector,源码如下
在Facebook，许多工程师在不同的代码仓库上工作，这不可避免会有内存泄漏的情况发生，当出现这种情况时，我们需要快速的找到并修复它们。
已经有一些工具来辅助我们找到内存泄漏，不过需要大量的人工干预：
传统办法:
打开Xcode，选择build for profiling.
载入Instruments工具
使用app, 尝试尽可能多的重现场景和行为
查看instrument的leaks/memory
查找内存泄漏的根源
修复问题
这意味着每次都需要大量的手动操作，导致我们可能在开发周期内无法尽早的定位以及修复内存泄漏的问题。
如果该过程能够自动化，我们就能够在太多开发者干预的情况下快速找到内存泄漏。为此我们构建一系列的工具来自动化查找以及修复代码仓库中的一些问题，这些工具包括：FBRetainCycleDetector, FBAllocationTracker以及FBMemoryProfiler
Retain cycles(循环引用)
Objective-C使用引用计数来管理内存以及释放不使用的对象，任何一个对象可以持有(retain)其它对象，这样只要前面的对象需要使用它，该对象就会一直保存在内存，可以认为对象“拥有”其它对象。
大部分情况下这都工作的很好，但是假如两个对象最后互相“拥有”对方，直接或着更多通过其它对象间接的连接它们，这就会陷入一个僵局。这种持有引用的环就叫做循环引用。
使用第三方框架解决
这一次分享的内容就是用于检测循环引用的框架 FBRetainCycleDetector 我们会分几个部分来分析 FBRetainCycleDetector 是如何工作的：
检测循环引用的基本原理以及过程
检测设计 NSObject 对象的循环引用问题
检测涉及 Associated Object 关联对象的循环引用问题
检测涉及 Block 的循环引用问题
我们会以类FBRetainCycleDetector
的- findRetainCycles
方法为入口，分析其实现原理以及运行过程。
简单介绍一下FBRetainCycleDetector
的使用方法：
_RCDTestClass *testObject = [_RCDTestClass new];
testObject.object = testObject;
FBRetainCycleDetector *detector = [FBRetainCycleDetector new];
[detector addCandidate:testObject];
NSSet *retainCycles = [detector findRetainCycles];
NSLog(@"%@", retainCycles);
初始化一个 FBRetainCycleDetector 的实例
调用 - addCandidate: 方法添加潜在的泄露对象
执行 - findRetainCycles 返回 retainCycles
在控制台中的输出是这样的：
2016-07-29 15:26:42.043 xctest[30610:1003493] {(
(
"-> _object -> _RCDTestClass "
)
)}
说明 FBRetainCycleDetector 在代码中发现了循环引用。
findRetainCycles 的实现
在具体开始分析 FBRetainCycleDetector 代码之前，我们可以先观察一下方法 findRetainCycles 的调用栈：
- (NSSet<NSArray<FBObjectiveCGraphElement *> *> *)findRetainCycles
└── - (NSSet<NSArray<FBObjectiveCGraphElement *> *> *)findRetainCyclesWithMaxCycleLength:(NSUInteger)length
└── - (NSSet<NSArray<FBObjectiveCGraphElement *> *> *)_findRetainCyclesInObject:(FBObjectiveCGraphElement *)graphElement stackDepth:(NSUInteger)stackDepth
└── - (instancetype)initWithObject:(FBObjectiveCGraphElement *)object
└── - (FBNodeEnumerator *)nextObject
├── - (NSArray<FBObjectiveCGraphElement *> *)_unwrapCycle:(NSArray<FBNodeEnumerator *> *)cycle
├── - (NSArray<FBObjectiveCGraphElement *> *)_shiftToUnifiedCycle:(NSArray<FBObjectiveCGraphElement *> *)array
└── - (void)addObject:(ObjectType)anObject;
调用栈中最上面的两个简单方法的实现都是比较容易理解的：
- (NSSet<NSArray<FBObjectiveCGraphElement *> *> *)findRetainCycles {
return [self findRetainCyclesWithMaxCycleLength:kFBRetainCycleDetectorDefaultStackDepth];
}
- (NSSet<NSArray<FBObjectiveCGraphElement *> *> *)findRetainCyclesWithMaxCycleLength:(NSUInteger)length {
NSMutableSet<NSArray<FBObjectiveCGraphElement *> *> *allRetainCycles = [NSMutableSet new];
for (FBObjectiveCGraphElement *graphElement in _candidates) {
NSSet<NSArray<FBObjectiveCGraphElement *> *> *retainCycles = [self _findRetainCyclesInObject:graphElement
stackDepth:length];
[allRetainCycles unionSet:retainCycles];
}
[_candidates removeAllObjects];
return allRetainCycles;
}
- findRetainCycles 调用了 - findRetainCyclesWithMaxCycleLength: 传入了 kFBRetainCycleDetectorDefaultStackDepth 参数来限制查找的深度，如果超过该深度（默认为 10）就不会继续处理下去了（查找的深度的增加会对性能有非常严重的影响）。
在 - findRetainCyclesWithMaxCycleLength: 中，我们会遍历所有潜在的内存泄露对象 candidate，执行整个框架中最核心的方法 - _findRetainCyclesInObject:stackDepth:，由于这个方法的实现太长，这里会分几块对其进行介绍，并会省略其中的注释：
- (NSSet<NSArray<FBObjectiveCGraphElement *> *> *)_findRetainCyclesInObject:(FBObjectiveCGraphElement *)graphElement
stackDepth:(NSUInteger)stackDepth {
NSMutableSet<NSArray<FBObjectiveCGraphElement *> *> *retainCycles = [NSMutableSet new];
FBNodeEnumerator *wrappedObject = [[FBNodeEnumerator alloc] initWithObject:graphElement];
NSMutableArray<FBNodeEnumerator *> *stack = [NSMutableArray new];
NSMutableSet<FBNodeEnumerator *> *objectsOnPath = [NSMutableSet new];
}
其实整个对象的相互引用情况可以看做一个有向图，对象之间的引用就是图的 Edge，每一个对象就是 Vertex，查找循环引用的过程就是在整个有向图中查找环的过程，所以在这里我们使用 DFS 来扫面图中的环，这些环就是对象之间的循环引用
<2>采用第三方框架MLeaksFinder进行检测
(1):MLeaksFinder的使用方法
利用cocoa pods引入第三方框架后运行项目(甚至在项目代码中连头文件都不用导入),效果图如下:
就可以根据提示找到造成内存泄漏的位置
(2)MLeaksFinder的简介
MLeaksFinder 提供了内存泄露检测更好的解决方案。只需要引入 MLeaksFinder，就可以自动在 App 运行过程检测到内存泄露的对象并立即提醒，无需打开额外的工具，也无需为了检测内存泄露而一个个场景去重复地操作。MLeaksFinder 目前能自动检测 UIViewController 和 UIView 对象的内存泄露，而且也可以扩展以检测其它类型的对象。
MLeaksFinder 的使用很简单，参照 https://github.com/Zepo/MLeaksFinder ，基本上就是把 MLeaksFinder 目录下的文件添加到你的项目中，就可以在运行时（debug 模式下）帮助你检测项目里的内存泄露了，无需修改任何业务逻辑代码，而且只在 debug 下开启，完全不影响你的 release 包。
当发生内存泄露时，MLeaksFinder 会中断言，并准确的告诉你哪个对象泄露了。这里设计为中断言而不是打日志让程序继续跑，是因为很多人不会去看日志，断言则能强制开发者注意到并去修改，而不是犯拖延症。
中断言时，控制台会有如下提示，View-ViewController stack 从上往下看，该 stack 告诉你，MyTableViewController 的 UITableView 的 subview UITableViewWrapperView 的 subview MyTableViewCell 没被释放。而且，这里我们可以肯定的是 MyTableViewController，UITableView，UITableViewWrapperView 这三个已经成功释放了。
从 MLeaksFinder 的使用方法可以看出，MLeaksFinder 具备以下优点：
使用简单，不侵入业务逻辑代码，不用打开 Instrument
不需要额外的操作，你只需开发你的业务逻辑，在你运行调试时就能帮你检测
内存泄露发现及时，更改完代码后一运行即能发现（这点很重要，你马上就能意识到哪里写错了）
精准，能准确地告诉你哪个对象没被释放
(3) MLeaksFinder的实现原理
MLeaksFinder 一开始从 UIViewController 入手。我们知道，当一个 UIViewController 被 pop 或 dismiss 后，该 UIViewController 包括它的 view，view 的 subviews 等等将很快被释放（除非你把它设计成单例，或者持有它的强引用，但一般很少这样做）。于是，我们只需在一个 ViewController 被 pop 或 dismiss 一小段时间后，看看该 UIViewController，它的 view，view 的 subviews 等等是否还存在。
具体的方法是，为基类 NSObject 添加一个方法 -willDealloc 方法，该方法的作用是，先用一个弱指针指向 self，并在一小段时间(3秒)后，通过这个弱指针调用 -assertNotDealloc，而 -assertNotDealloc 主要作用是直接中断言。
- (BOOL)willDealloc {
__weak id weakSelf = self;
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(3 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
[weakSelf assertNotDealloc];
});
return YES;
}
- (void)assertNotDealloc {
NSAssert(NO, @“”);
}
这样，当我们认为某个对象应该要被释放了，在释放前调用这个方法，如果3秒后它被释放成功，weakSelf 就指向 nil，不会调用到 -assertNotDealloc 方法，也就不会中断言，如果它没被释放（泄露了），-assertNotDealloc 就会被调用中断言。这样，当一个 UIViewController 被 pop 或 dismiss 时（我们认为它应该要被释放了），我们遍历该 UIViewController 上的所有 view，依次调 -willDealloc，若3秒后没被释放，就会中断言。
在这里，有几个问题需要解决：
不入侵开发代码
这里使用了 AOP 技术，hook 掉 UIViewController 和 UINavigationController 的 pop 跟 dismiss 方法，关于如何 hook，请参考 Method Swizzling。
遍历相关对象
在实际项目中，我们发现有时候一个 UIViewController 被释放了，但它的 view 没被释放，或者一个 UIView 被释放了，但它的某个 subview 没被释放。这种内存泄露的情况很常见，因此，我们有必要遍历基于 UIViewController 的整棵 View-ViewController 树。我们通过 UIViewController 的 presentedViewController 和 view 属性，UIView 的 subviews 属性等递归遍历。对于某些 ViewController，如 UINavigationController，UISplitViewController 等，我们还需要遍历 viewControllers 属性。
构建堆栈信息
需要构建 View-ViewController stack 信息以告诉开发者是哪个对象没被释放。在递归遍历 View-ViewController 树时，子节点的 stack 信息由父节点的 stack 信息加上子结点信息即可。
例外机制
对于有些 ViewController，在被 pop 或 dismiss 后，不会被释放（比如单例），因此需要提供机制让开发者指定哪个对象不会被释放，这里可以通过重载上面的 -willDealloc 方法，直接 return NO 即可。
特殊情况
对于某些特殊情况，释放的时机不大一样（比如系统手势返回时，在划到一半时 hold 住，虽然已被 pop，但这时还不会被释放，ViewController 要等到完全 disappear 后才释放），需要做特殊处理，具体的特殊处理视具体情况而定。
系统View
某些系统的私有 View，不会被释放（可能是系统 bug 或者是系统出于某些原因故意这样做的，这里就不去深究了），因此需要建立白名单
手动扩展
MLeaksFinder目前只检测 ViewController 跟 View 对象。为此，MLeaksFinder 提供了一个手动扩展的机制，你可以从 UIViewController 跟 UIView 出发，去检测其它类型的对象的内存泄露。如下所示，我们可以检测 UIViewController 底下的 View Model：
- (BOOL)willDealloc {
if (![super willDealloc]) {
return NO;
}
MLCheck(self.viewModel);
return YES;
}
这里的原理跟上面的是一样的，宏 MLCheck() 做的事就是为传进来的对象建立 View-ViewController stack 信息，并对传进来的对象调用 -willDealloc 方法。
未来
MLeaksFinder 目前还在起步阶段，它的内存泄露检测的想法是很简单，很直接的。虽然目前只能自动地检测 UIViewController 和 UIView 相关的对象，然而在我们几个大的项目中，已经起到很大的作用，帮助我们发现很多历史存在的内存泄露，而且确保新提交的 UI 相关代码不会引进新的问题。MLeaksFinder 会继续探索覆盖更广的情况，提供更全面的检测，包括网络层，数据存储层等等。
详细参考:
http://wereadteam.github.io/2016/02/22/MLeaksFinder/
https://github.com/Draveness/iOS-Source-Code-Analyze/blob/master/contents/FBRetainCycleDetector/如何在%20iOS%20中解决循环引用的问题.md
//www.greatytc.com/p/79d6a3a6a479
