timer中的那些坑

作者: 二亮子 | 来源:发表于2016-05-20 01:04 被阅读1121次

引言

我们在使用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。

欢迎大家和我交流沟通,若文章中有错误和纰漏,恳请指正,谢谢,如果感觉评论不方便欢迎微博私信。

相关文章

网友评论

    本文标题:timer中的那些坑

    本文链接:https://www.haomeiwen.com/subject/xjagrttx.html