面试中，经常会问道 NSTimer 循环引用的问题。
闲话少叙。下面来讲讲 NSTimer 为什么会造成循环引用？
使用 NSTimer 的 block 的方式来创建定时器。
一般情况下，我们会把 NSTimer 定义成当前控制器的一个属性/成员变量。
@implementation ViewController {
NSTimer *_timer;
}
到此步为止，造成了一个单向引用
ViewController -> NSTimer
使用 NSTimer 的 block 语法，来创建定时器任务。
- (void)blockTimer {
// 创建一个 _timer。
_timer = [NSTimer timerWithTimeInterval:1 repeats:YES block:^(NSTimer * _Nonnull timer) {
// 此控制器的内部并没有捕获控制器，于是就没有造成对控制器的强引用。
NSLog(@"%@",@"timer 开始执行。");
}];
[[NSRunLoop currentRunLoop] addTimer:_timer forMode:NSDefaultRunLoopMode];
由于定时器执行任务的 block，并没有引用 self，到次为止，引用关系仍然是单向的。
重写 dealloc 方法来检测，当前控制器是否可以被销毁。
- (void)dealloc {
NSLog(@"%@",@"控制器不能被销毁？");
}
运行结果：
2017-11-06 19:14:50.195 CodeForNSTimerRetainCycle[18912:19230566] timer 开始执行。
2017-11-06 19:14:51.196 CodeForNSTimerRetainCycle[18912:19230566] timer 开始执行。
2017-11-06 19:14:52.196 CodeForNSTimerRetainCycle[18912:19230566] timer 开始执行。
2017-11-06 19:14:53.196 CodeForNSTimerRetainCycle[18912:19230566] timer 开始执行。
timer 可以正常执行。
当点击了返回按钮，退出此控制器的 Log 输出。
2017-11-06 19:15:36.344 CodeForNSTimerRetainCycle[18949:19234509] 控制器不能被销毁？
2017-11-06 19:15:36.482 CodeForNSTimerRetainCycle[18949:19234509] timer 开始执行。
2017-11-06 19:15:37.483 CodeForNSTimerRetainCycle[18949:19234509] timer 开始执行。
2017-11-06 19:15:38.482 CodeForNSTimerRetainCycle[18949:19234509] timer 开始执行。
2017-11-06 19:15:39.482 CodeForNSTimerRetainCycle[18949:19234509] timer 开始执行。
控制器可以正常销毁。但是 NSTimer 仍然在继续执行。
当点击控制器的返回按钮时，图中那条白色的箭头断开，当前控制器又没有其他的对象引用(除了 navigationController,但pop 的时候，这条连接已经断开了)。所以，控制器可以被正确释放。
2017-11-06 19:15:36.344 CodeForNSTimerRetainCycle[18949:19234509] 控制器不能被销毁？
NSTimer 没有被释放，是因为，当我们把 NSTimer 添加到运行循环时，运行循环强引用了这个 NSTimer(也就是图中红色的箭头)。
而 Runloop 是无法销毁的(UI线程)。
所以，这条红色的箭头，就无法断开。NSTimer 不能被释放。
于是就出现了控制器被正确销毁，但是在控制器里创建的 NSTimer 却可以仍然运行的情况。
是 Runloop 强引用了这个 NSTimer。
但这种写法，并不阻碍当前控制器的释放。
但为了保证，NSTimer 在控制器释放的时候，就不要在继续执行了，可以在 dealloc 方法里，让 NSTimer 过期。
- (void)dealloc {
NSLog(@"%@",@"控制器不能被销毁？");
[_timer invalidate];
}
使用 NSTimer 的 block 的方式来创建定时器,在 block 内部访问 self。
在 block 的内部访问 self，肯定会造成循环引用，道理也很简单。
解决办法，使用经典的 weak-strong dance即可。
- (void)blockTimer {
// 创建一个 _timer。
__weak typeof(self) weakSelf = self;
_timer = [NSTimer timerWithTimeInterval:1 repeats:YES block:^(NSTimer * _Nonnull timer) {
__strong typeof(weakSelf) strongSelf = weakSelf;
// 此控制器的内部并没有捕获控制器，于是就没有造成对控制器的强引用。
// NSLog(@"%@",@"timer 开始执行。");
strongSelf.view.backgroundColor = [UIColor colorWithRed:arc4random_uniform(256)/255.0 green:arc4random_uniform(256)/255.0 blue:arc4random_uniform(256)/255.0 alpha:arc4random_uniform(256)/255.0];
NSLog(@"%@",strongSelf.view);
}];
[[NSRunLoop currentRunLoop] addTimer:_timer forMode:NSDefaultRunLoopMode];
运行结果：
2017-11-06 19:33:36.518 CodeForNSTimerRetainCycle[19195:19304854] 控制器不能被销毁？
控制器可以正常退出，NSTimer 也不会继续执行了。
使用 NSTimer 的 target 方式来来创建定时任务。
使用NSTimer 的 target 方式来来创建定时任务。NSTimer 一定会强引用住当前控制器。
#pragma mark timer 的 target 方式
- (void)targetTimer {
// 这种方式创建，timer 会强引用 self。导致这个控制器无法被销毁。
_timer = [[NSTimer alloc] initWithFireDate:[NSDate dateWithTimeIntervalSinceNow:1] interval:1 target:self selector:@selector(timerAction) userInfo:nil repeats:YES];
[[NSRunLoop currentRunLoop] addTimer:_timer forMode:NSRunLoopCommonModes];
}
运行结果：
2017-11-06 19:35:56.565 CodeForNSTimerRetainCycle[19241:19313152] timer 事件执行！
2017-11-06 19:35:57.565 CodeForNSTimerRetainCycle[19241:19313152] timer 事件执行！
2017-11-06 19:35:58.565 CodeForNSTimerRetainCycle[19241:19313152] timer 事件执行！
当pop 当前控制器的时候，dealloc 方法也没有被执行。说明当前控制器没有被释放。
为什么使用了 target 的方式来NSTimer 定时任务的时候，当前控制器不能被释放呢？
因为 NSTimer 强引用了这个控制器。
为什么 NSTimer 通过 target 的方式创建定时任务的时候，要强引用这个控制器呢？
NSTimer 的任务来源的 SEL 来自于这个控制器，只有在当前控制器上才能通过 SEL 找到方法的实现。如果 控制器不被强引用住，那么会会影响 NSTimer 定时任务的执行。
所以，为了保证 NSTimer 任务能够定时的执行，就必须强引用这个控制器。
也就是说，NSTimer 内部有一个 __strong target，强引用了这个控制器，于是就造成了循环引用。
两个对象，如果双发都被强引用了，一般 strong，一般 weak 即可。
但是 NSTimer 是系统的类，且当前控制器的传递是使用 target 的方式。又不是我们自己定义类，把属性改成 weak 修饰就好了。
幸好的是，NSTimer 提供了一个可以断开和当前 target 强引用关系的方法。
[_timer invalidate];
当我们调用这个方法的时候。
- NSTimer 会断开自己和 target 的强引用关系。
- Runloop 会断开自己和 NSTimer 的强引用关系。
第一条解决了控制器释放的问题。
第二条解决了在控制器释放之后,NSTimer仍然在继续执行的问题。
于是就开心的在当前控制器的 dealloc 方法里加了这么一行代码。
- (void)dealloc {
NSLog(@"%@",@"控制器不能被销毁？");
[_timer invalidate];
}
运行结果：
2017-11-06 19:43:58.682 CodeForNSTimerRetainCycle[19305:19325055] timer 事件执行！
2017-11-06 19:43:59.682 CodeForNSTimerRetainCycle[19305:19325055] timer 事件执行！
2017-11-06 19:44:00.682 CodeForNSTimerRetainCycle[19305:19325055] timer 事件执行！
2017-11-06 19:44:01.682 CodeForNSTimerRetainCycle[19305:19325055] timer 事件执行！
发现等控制器pop 出的时候,NSTimer 既没断开和控制器的强引用，也没有被 Runloop 断开对自身的强引用。
问题出在哪？
- NSTimer & ViewController 双向引用了。
- Runloop & NSTimer 单向引用了。
- NSTimer invalidate 方法写在了 ViewController 的 dealloc 方法里了。
答案呼之欲出了：
由于第一条，NSTimer & ViewController 双向引用了，当前控制器根本无法被释放。
从而无法执行到 dealloc , 就无法执行 [_timer invalidate] 这个方法。
但这个方法，又是 NSTimer 断开和控制器以及 runloop 的核心方法。
所以，就造成了无法控制器无法释放，以及 NSTimer 仍然在继续执行的问题。
终极解决方案：
在当前控制器的 - (void)viewDidDisappear:(BOOL)animated 里调用 [_timer invalidate]。
当 NSTimer 提前断开和当前控制器&runloop的强引用。
- (void)viewDidDisappear:(BOOL)animated {
[super viewDidDisappear:animated];
// 界面消失的时候，让 timer 过期。
[_timer invalidate]; // 这个方法会断开 timer 和 runloop 以及 当前控制器之间的两个强引用关系。
}
[图片上传失败...(image-3c6521-1509969579725)]
关于 NSTimer 循环引用最后总结
只要在控制器中使用了 NSTimer，都可以在 - (void)viewDidDisappear:(BOOL)animated 里让 NSTimer 断开和当前控制器的循环引用关系(如果有),以及一定断开和 Runloop 的强引用关系。
