java timer很坑_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。