timer中的那些坑
引言
我们在使用timer的时候多多少少都遇到过一些坑，今天就来说说timer使用中的那些坑
1.循环引用导致的内存泄露的问题
@implementation SecondController {
NSTimer *_testTimer;
}
- (void)viewDidLoad {
_testTimer = [NSTimer scheduledTimerWithTimeInterval:1 target:self selector:@selector(handleTestTimer) userInfo:nil repeats:NO];
}
- (void)dealloc {
NSLog(@"dealloc!");
[_testTimer invalidate];
}
- (void)handleTestTimer {
NSLog(@"hello world!");
}
@end
我们可能写过类似上面的代码，一般情况下它是可以正常执行的，我们并没有过多的去想timer的问题，但是实际上这样写是有问题的。如果创建timer时repeats:YES，再运行的话，我们发现dealloc函数就永远不会调用了(我们这里SecondController是被另一个vc push进来的)。
引起这个问题的原因就是：timer会强引用自己的target，在上面的例子中，我们的vc是强引用_testTimer对象的，但是创建这个timer的时候我们的target传入的是self，此时就导致了tiemr也强引用了self，导致循环引用的产生。
准确的说，timer在isValid为YES的时候是强引用自己的target的，所以一般我们都把invalidate的时机放在viewWillDisappear:或viewDidDisappear:的时候，这样vc就会正常释放了。
@implementation SecondController {
NSTimer *_testTimer;
}
- (void)viewDidLoad {
[super viewDidLoad];
_testTimer = [NSTimer scheduledTimerWithTimeInterval:1 target:self selector:@selector(handleTestTimer) userInfo:nil repeats:YES];
}
- (void)viewWillDisappear:(BOOL)animated {
[super viewWillDisappear:animated];
if (_testTimer.isValid) {
[_testTimer invalidate];
}
}
- (void)dealloc {
NSLog(@"dealloc!");
}
- (void)handleTestTimer {
NSLog(@"hello world!");
}
@end
上面这样就可以正常释放了，但这里还要说一点：
循环引用和内存泄露还是稍有不同的
就拿我们的timer举例，如果我们在创建timer的时候repeats:NO，但是触发的时机是30s，但是我们在这个vc中停留小于30s，就会造成暂时的循环引用，但是这种情况也不能说是内存泄露，从我们退出vc开始到timer触发时的这一段时间内，vc和timer造成了循环引用，但是当timer触发后，你会发现，vc的dealloc也被调用了，此时vc和timer的内存都能够得到释放，循环引用是有暂时性的，所以要理解循环引用和内存泄露是稍有不同的。
可能有人会想，为什么非要用一个全部变量呢？直接：
[NSTimer scheduledTimerWithTimeInterval:1 target:self selector:@selector(handleTestTimer) userInfo:nil repeats:YES];
不引入任何全局或局部变量不行吗？答案是不行，即使像上面那样，创建了timer，虽然没有引入任何变量，但是依然会产生循环引用，如果repeats:YES，就会造成内存泄露了。
为什么没有任何全局或局部变量的timer仍然会循环引用？下面要说的坑会解决这个问题。
2.不用scheduledTimerWithTimeInterval方式创建timer的问题
@implementation SecondController {
NSTimer *_testTimer;
}
- (void)viewDidLoad {
[super viewDidLoad];
_testTimer = [NSTimer timerWithTimeInterval:1 target:self selector:@selector(handleTestTimer) userInfo:nil repeats:YES];
}
- (void)viewWillDisappear:(BOOL)animated {
[super viewWillDisappear:animated];
if (_testTimer.isValid) {
[_testTimer invalidate];
}
}
- (void)dealloc {
NSLog(@"dealloc!");
[_testTimer invalidate];
}
- (void)handleTestTimer {
NSLog(@"hello world!");
}
@end
当我们不用scheduledTimerWithTimeInterval方式创建timer的时候你会发现timer并不能正常的进行回调。
有人会想，是不是这种情况要手动触发呢，但是即使我们调用：
[_testTimer fire];
也还是不能让timer正常的回调。
正确的做法是：
[[NSRunLoop currentRunLoop] addTimer:_testTimer forMode:NSDefaultRunLoopMode];
这里就解释了为什么不设置成任何全局或局部变量的timer也会导致循环应用的问题，因为我们要把timer放到runloop里，这个过程中timer就会一直在内存中，即使你没有给他赋值给任何变量，这也说明runloop在addTimer的时候也是强引用的。
这里有一个关于timer很重要的一点：NSTimer是基于Runloop的
这里重点不是要讲解Runloop，毕竟Runloop要比timer复杂的多，但为了帮助大家理解，这里简单的说说Runloop：
1.Runloop是用于管理线程的，它可以让一个线程在有任务执行的时候去执行，没有任务执行的时候去休息。
2.一个线程总是对应一个或零个Runloop对象，主线程默认有一个Runloop对象，其他线程默认没有Runloop对象，但是可以通过currentRunLoop创建一个Runloop对象。
3.Runloop可以保证程序循环执行，而非线性执行，实际上Runloop就是用while循环来实现的，而且它并不是iOS系统特有的概念，只要能保证程序非线性的执行的系统都有先关的概念，像Android里的looper。
3.timer触发时机不准的问题
timer发生回调的时机有时候并不一定完全由你设置的回调时间来决定，这要说到runloop mode，为了说明这个坑，还是简单的介绍一下runloop mode。
1.一般常用的runloop mode是Default和Common modes，除此之外，还有Connection、Modal、Event tracking等不同的mode。
2.一个线程可以对应一个或零个runloop，一个runloop可以对应一个或多个runloop mode，一个runloop mode中会有多个source。
3.一个runloop同时只能执行一个runloop mode里的source，系统对不同的runloop mode有不同的处理策略和优先级。
我们常用的Default mode，优先级很低，例如当我们滚动scrollview的时候，此时runloop会切换到Event tracking的mode上，此时处于Default mode里的timer就不能得到执行，直到这个runloop把mode切换到Default的时候timer才能被触发，而没有触发timer的这段时间会按照timer设置的回调时间取整的进行一次性触发多次timer回调。为了保证timer的回调时机准确，我们可以把timer放在Common modes里。
4.子线程中timer的坑
@implementation SecondController {
NSTimer *_testTimer;
}
- (void)viewDidLoad {
[super viewDidLoad];
NSLog(@"1:%p", [NSRunLoop currentRunLoop]);
[self performSelectorInBackground:@selector(testTimer) withObject:nil];
}
- (void)testTimer {
NSLog(@"2:%p", [NSRunLoop currentRunLoop]);
_testTimer = [NSTimer timerWithTimeInterval:1 target:self selector:@selector(handleTestTimer) userInfo:nil repeats:YES];
[[NSRunLoop currentRunLoop] addTimer:_testTimer forMode:NSDefaultRunLoopMode];
}
- (void)viewWillDisappear:(BOOL)animated {
[super viewWillDisappear:animated];
if (_testTimer.isValid) {
[_testTimer invalidate];
}
}
- (void)dealloc {
NSLog(@"dealloc!");
[_testTimer invalidate];
}
- (void)handleTestTimer {
NSLog(@"hello world!");
}
@end
当我们用performSelector的方式把timer放到子线程中的runloop里时发现timer又不好使了。
这个坑的主要原因是，子线程默认是没有runloop的，currentRunloop的方式是可以获得runloop的，但是此时的这个runloop并没有run，我们要在[[NSRunLoop currentRunLoop] addTimer:_testTimer forMode:NSDefaultRunLoopMode];后调用[[NSRunLoop currentRunLoop] run];才可以使得这个timer正常工作的。
结论
一个小小的timer当我们仔细去研究的时候发现它大有文章可做，好多东西都值得我们深入研究，例如timer会强引用自己的target导致循环引用，所以我们在每次用timer的时候都要小心，当timer页面要消失的时候我们总是要调用invalidate, 这样很麻烦，我们能不能使用timer的时候不用去考虑它的释放问题，这个问题就是自释放的问题，我们可以想想能不能实现一个自释放的timer。
