神刀安全网

iOS Timer 盘点

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

NSTimer

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

用法

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

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

Tips

为何停止?

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

UITableViewCell上有个UILabel,显示NSTimer实现的秒表时间,手指滚动cell过程中,label是否刷新,为什么?

我们来试验一下:

iOS Timer 盘点

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

那这是为什么呢?这与 RunLoop 有关。在 NSTimer的官方文档 上,苹果是这么说的:

A timer is not a real-time mechanism; it fires only when one of the run loop modes to which the timer has been added is running and able to check if the timer’s firing time has passed.

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

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

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

所以,如果我们想要 NSTimerUIScrollView 滑动的时候也会启动的话,只要将 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]; 

iOS Timer 盘点

是否精确?

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

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

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

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

iOS Timer 盘点

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

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

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

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

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

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

Setting a tolerance for a timer allows it to fire later than the scheduled fire date, improving the ability of the system to optimize for increased power savings and responsiveness.

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

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

The system reserves the right to apply a small amount of tolerance to certain timers regardless of the value of this property.

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

Even a small amount of tolerance will have a significant positive impact on the power usage of your application.

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

所以,从上面的论述中我们可以看到,即使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];     }); 

结果是并不会停止。

iOS Timer 盘点

NSTimer的官方文档 上,苹果是这么说的:

You should always call the invalidate method from the same thread on which the timer was installed.

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

CFRunLoopTimerRef

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

NSTimer is “toll-free bridged” with its Core Foundation counterpart, CFRunLoopTimerRef. See Toll-Free Bridgingfor more information on toll-free bridging.

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");     }); 

和上面说到的 NSTimerCFRunLoopTimerRef 不同, NSTimerCFRunLoopTimerRef 是在指定的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);     }); 

我们看一下输出:

iOS Timer 盘点

结果是,在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);     }); 

iOS Timer 盘点

OK,没有问题。

performSelector:withObject:afterDelay:

用法

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

This method sets up a timer to perform the aSelector message on the current thread’s run loop. The timer is configured to run in the default mode (NSDefaultRunLoopMode).

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]; 

iOS Timer 盘点

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

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

iOS Timer 盘点

很遗憾,没有用。但是我们可以取消这个 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.”的警告。

iOS Timer 盘点

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

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

我们试验一下,这里 printDescriptionAprintDescriptionB 方法各会返回一个不同类型的 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]; } 

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

iOS Timer 盘点

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

performSelector系列方法在内存管理方面容易有疏失。它无法确定要执行的选择子具体是什么,因而ARC编译器也就无法插入适当的内存管理方法。

关于这个问题,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/

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » iOS Timer 盘点

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
分享按钮