iOS Timer 盘点

在iOS的开发过程中，Timer是一个很常见的功能。苹果提供给了我们好几种可以达到Timer效果的方法，我尝试在这里盘点一下。

NSTimer

NSTimer 是我们最常见的一种Timer,我们从 NSTimer 开始说起。

用法

NSTimer 的用法很简单，个人比较常用的是下面这个方法:

[NSTimer scheduledTimerWithTimeInterval:1.0f                                      target:self                                    selector:@selector(test)                                    userInfo:nil                                     repeats:nil]; 

Tips

为何停止?

有这么一道面试题，题目是这样的:

我们来试验一下:

通过试验，我们发现，在手拖拽或者滑动的过程中，label并没有更新， NSTimer 也没有循环。

那这是为什么呢？这与 RunLoop 有关。在 NSTimer的官方文档 上，苹果是这么说的：

意思就是说，NSTimer并不是一种实时机制，它只会在下面条件满足的情况下才会启动:

1. NSTimer被添加到的RunLoop模式正在运行。
2. NSTimer设定的启动时间还没有过去。

关键在于第一点，我们刚才的 NSTimer 默认添加在 NSDefaultRunLoopMode 上，而 UIScrollView 在滑动的时候，RunLoop会自动切换到 UITrackingRunLoopMode ， NSTimer 并没有添加到这个RunLoop模式上，自然是不会启动的。

所以，如果我们想要 NSTimer 在 UIScrollView 滑动的时候也会启动的话，只要将 NSTimer 添加到 NSRunLoopCommonModes 上即可。 NSRunLoopCommonModes 是RunLoop模式的集合。

我们试验一下：

self.timer = [NSTimer scheduledTimerWithTimeInterval:0.8f                                               target:self selector:@selector(autoIncrement)                                             userInfo:nil                                              repeats:YES]; [[NSRunLoop mainRunLoop] addTimer:self.timer forMode:NSRunLoopCommonModes]; 

是否精确？

在上面的 为何停止 的分析中，我们了解到， NSTimer 只会在它所加入的RunLoop上启动和循环。如果在类似于上面的情况，而 NSTimer 又只是加入 NSDefaultRunLoopMode 的话，这时候的 NSTimer 在切换RunLoop模式之后，必然没有精确可言。

那么，如果RunLoop一直运行在 NSTimer 被加入到的模式上，或者加入到的是 NSRunLoopCommonModes 的模式上，是否就是精确的呢?

首先，我们假设线程正在进行一个比较大的连续运算，这时候，我们的 NSTimer 会被准时启动吗?

我在程序中每0.5秒打印一下”test”,然后用很慢的办法去计算质数，运行结果如下：

在计算质数的过程中，线程完全阻塞，并不打印”test”，等到执行完成才开始打印，第一个”start”和第二个”test”中间间隔了13秒。

所以 NSTimer 是否精确，很大程度上取决于线程当前的空闲情况。

除此之外，还有一点我想提及一下。

在NSTimer的头文件中，苹果新增了一个属性，叫做 tolerance ,我们可以理解为容差。苹果的意思是如果设定了 tolerance 值，那么:

设定时间 <= NSTimer的启动时间 <= 设定时间 + tolerance

那么，这个有什么用呢，因为一般来说，我们想要的就是精确。苹果的解释是：

意思就是，设定容差可以起到省电和优化系统响应性的作用。

tolerance 如果不设定的话，默认为0。那么，是否一定可以精确呢？苹果在头文件中提到了这么一点：

意思就是，哪怕为0，系统依然有权利去设置一个很小的容差。

毕竟一个很小的容差都可以对电量产生一个很大的积极的影响。

所以，从上面的论述中我们可以看到，即使RunLoop模式正确，当前线程并不阻塞，系统依然可能会在 NSTimer 上加上很小的的容差。

如何终止？

NSTimer 提供了一个 invalidate 方法，用于终止 NSTimer 。但是，这里涉及到一个多线程的问题。假设，我在A线程启动 NSTimer ，在B线程调用 invalidate 方法来终止 NSTimer ，那么， NSTimer 是否会终止呢。

我们来试验一下：

dispatch_async(dispatch_get_main_queue(), ^{         self.timer = [NSTimer scheduledTimerWithTimeInterval:0.5f                                                       target:self                                                     selector:@selector(test)                                                     userInfo:nil                                                      repeats:YES];     });  dispatch_async(dispatch_get_global_queue(0, 0), ^{         [self.timer invalidate];     }); 

结果是并不会停止。

在 NSTimer的官方文档 上，苹果是这么说的：

所以，我们必须哪个线程调用，哪个线程终止。

CFRunLoopTimerRef

在 NSTimer的官方文档 上,苹果提到：

NSTimer 可以直接桥接到 CFRunLoopTimerRef 上，两者的数据结构是相同的，是可以互换的。我们可以理解为， NSTimer 是objc版本的 CFRunLoopTimerRef 封装。

用法

CFRunLoopTimerRef 一般用法如下：

NSTimeInterval fireDate = CFAbsoluteTimeGetCurrent(); CFRunLoopTimerRef timer = CFRunLoopTimerCreateWithHandler(kCFAllocatorDefault, fireDate, 0.5f, 0, 0, ^(CFRunLoopTimerRef timer) {         NSLog(@"test");     }); CFRunLoopAddTimer(CFRunLoopGetCurrent(), timer, kCFRunLoopCommonModes); 

其他用法可以参考苹果的 CFRunLoopTimerRef文档 。

Tips

和RunLoop有什么关系？

CoreFoundation框架中有主要有5个RunLoop类：

• CFRunLoopRef
• CFRunLoopModeRef
• CFRunLoopSourceRef
• CFRunLoopTimerRef
• CFRunLoopObserverRef

CFRunLoopTimerRef 属于其中之一。

关于RunLoop， ibireme 大神写了一个非常好的文章，大家可以围观学习一下：

http://blog.ibireme.com/2015/05/18/runloop/

有没有需要使用CFRunLoopTimerRef?

既然 CFRunLoopTimer is “toll-free bridged” with its Cocoa Foundation counterpart, NSTimer.  ,那么如果在使用CF框架写内容的话，可以直接使用，否则，还是使用 NSTimer 吧。

dispatch_after

用法

dispatch_after 的用法比较简单，一般设定一个时间，然后指定一个队列，比如 Main Dispatch Queue 。

dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(3 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{         NSLog(@"test");     }); 

和上面说到的 NSTimer 和 CFRunLoopTimerRef 不同， NSTimer 和 CFRunLoopTimerRef 是在指定的RunLoop上注册启动时间，而 dispatch_after 是在指定的时间后，将整个执行的Block块添加到指定队列的RunLoop上。

所以，如果此队列处于繁重任务或者阻塞之中， dispatch_after 的Block块肯定是要延后执行的。

Tips

强引用

假设现在有这么一个情况， dispatch_after 中引用了 Self ,那么在设定时间之前， Self 可以被释放吗?

dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(3 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{         self.label.text = @"ok";     }); 

我来试验一下，我从A-VC push到B-VC，之后再pop回来，B-VC有个5秒的 dispatch_after :

dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(5 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{         self.label.text = @"ok";         NSLog(@"-- %@",self.description);     }); 

我们看一下输出：

结果是，在pop回去之后， Self 并没有得到释放，在 dispatch_after 的Block块执行完成之后， Self 才得到正确释放。

如何解决dispatch_after的Block块中的强引用问题？

MLeaksFinder 是一个开源的iOS内存泄露检测工具。作者很有想法，他在 ViewController 被pop或dismiss之后，在一定时间之后(默认为3秒)，去看看这个 ViewController 和它的 subviews 是否还存在。

基本上是类似于这样：

__weak id weakSelf = self; dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(3 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{         [weakSelf assertNotDealloc];     }); 

这里如果直接使用 Self 的话， ViewController 被pop或者dismiss之后，依然是无法释放的，而 __weak 就可以解决这个问题。在这里， Self 如果被正确释放的话， weakSelf 自然会变成 nil 。

我们修改一下我们试验的代码：

__weak typeof(self) weakSelf = self; dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(5 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{         weakSelf.label.text = @"ok";         NSLog(@"-- %@",weakSelf.description);     }); 

OK,没有问题。

performSelector:withObject:afterDelay:

用法

这依然是对 CFRunLoopTimerRef 的封装，和 NSTimer 同源。既然是同源，那么同样具有 NSTimer 的RunLoop特性。依据 苹果文档 中提到内容， performSelector:withObject:afterDelay: 运行的RunLoop模式是 NSDefaultRunLoopMode ，那么， ScrollView 滚动的时候，RunLoop会切换， performSelector:withObject:afterDelay: 自然不会被回调。

performSelector:withObject:afterDelay: 的用法也比较简单。

[self performSelector:@selector(test) withObject:nil afterDelay:1.0f]; 

Tips

强引用

假设是 Self 去调用 performSelector:withObject:afterDelay: 方法，在Delay时间未到之前， Self 能否被释放呢？

我们试验一下：

[self performSelector:@selector(printDescription) withObject:nil afterDelay:5.0f]; 

结果和上面的 dispatch_after 一样，我们修改一下代码，再看一下：

__weak typeof(self) weakSelf = self; [weakSelf performSelector:@selector(printDescription) withObject:nil afterDelay:5.0f]; 

很遗憾，没有用。但是我们可以取消这个 performSelector 。

这种方法可以取消Target指定的带执行的方法。

[NSObject cancelPreviousPerformRequestsWithTarget:self selector:@selector(printDescription) object:nil]; 

这种方法可以取消Target的所有待执行的方法。

[NSObject cancelPreviousPerformRequestsWithTarget:self]; 

能否正确释放返回值？

和 performSelector 不同的是， performSelector:withObject:afterDelay: 并不会出现”PerformSelector may cause a leak because its selector is unknown.”的警告。

那么，这是否意味着 performSelector:withObject:afterDelay: 可以正确释放返回值呢？

如果现在 performSelector:withObject:afterDelay: 所执行的 Selector 并不确定，并且可能会返回一个对象，那么系统能否正确释放这个返回值呢？

我们试验一下，这里 printDescriptionA 和 printDescriptionB 方法各会返回一个不同类型的 View (此View是新建的对象), printDescriptionC 会返回 Void 。

NSArray *array = @[@"printDescriptionA",                    @"printDescriptionB",                    @"printDescriptionC"];  NSString *selString = array[arc4random()%3]; NSLog(@"sel = %@", selString); SEL tempSel = NSSelectorFromString(selString); if ([self respondsToSelector:tempSel]) {     [self performSelector:tempSel withObject:nil afterDelay:3.0f]; } 

几次尝试之后，我发现，这是可以正常释放的。

在 Effective Objective-C 2.0 一书中，作者在第42条上提到:

关于这个问题，stackoverflow上也有很多讨论:

http://stackoverflow.com/questions/7017281/performselector-may-cause-a-leak-because-its-selector-is-unknown

我不知道如何触发这种内存泄露，有知道的告诉我一声，学习一下，谢谢。

参考资料

https://developer.apple.com/library/ios/documentation/Cocoa/Reference/Foundation/Classes/NSTimer_Class/index.html#//apple_ref/occ/cl/NSTimer https://developer.apple.com/library/ios/documentation/CoreFoundation/Reference/CFRunLoopTimerRef/ https://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFRunLoopRef/index.html https://developer.apple.com/library/ios/documentation/CoreFoundation/Conceptual/CFDesignConcepts/Articles/tollFreeBridgedTypes.html#//apple_ref/doc/uid/TP40010677 http://blog.ibireme.com/2015/05/18/runloop/