iOS 定时器的比较

然而，在iOS中有很多方法完成以上的任务，到底有多少种方法呢？经过查阅资料，大概有三种方法：NSTimer、CADisplayLink、GCD。接下来我就一一介绍它们的用法。

一、NSTimer

1. 创建方法

TimerInterval : 执行之前等待的时间。比如设置成1.0，就代表1秒后执行方法

target : 需要执行方法的对象。

selector : 需要执行的方法

repeats : 是否需要循环

2. 释放方法

注意 :

调用创建方法后，target对象的计数器会加1，直到执行完毕，自动减1。如果是循环执行的话，就必须手动关闭，否则可以不执行释放方法。

3. 特性

存在延迟

不 管是一次性的还是周期性的timer的实际触发事件的时间，都会与所加入的RunLoop和RunLoop Mode有关，如果此RunLoop正在执行一个连续性的运算，timer就会被延时出发。重复性的timer遇到这种情况，如果延迟超过了一个周期，则 会在延时结束后立刻执行，并按照之前指定的周期继续执行。

必须加入Runloop

使用上面的创建方式，会自动把timer加入MainRunloop的NSDefaultRunLoopMode中。如果使用以下方式创建定时器，就必须手动加入Runloop:

二、CADisplayLink

1. 创建方法

2. 停止方法

3. 特性

屏幕刷新时调用

CADisplayLink 是一个能让我们以和屏幕刷新率同步的频率将特定的内容画到屏幕上的定时器类。CADisplayLink以特定模式注册到runloop后，每当屏幕显示 内容刷新结束的时候，runloop就会向CADisplayLink指定的target发送一次指定的selector消息， CADisplayLink类对应的selector就会被调用一次。所以通常情况下，按照iOS设备屏幕的刷新率60次/秒

延迟

iOS设备的屏幕刷新频率是固定的，CADisplayLink在正常情况下会在每次刷新结束都被调用，精确度相当高。但如果调用的方法比较耗时，超过了屏幕刷新周期，就会导致跳过若干次回调调用机会。

如果CPU过于繁忙，无法保证屏幕60次/秒的刷新率，就会导致跳过若干次调用回调方法的机会，跳过次数取决CPU的忙碌程度。

使用场景

从原理上可以看出，CADisplayLink适合做界面的不停重绘，比如视频播放的时候需要不停地获取下一帧用于界面渲染。

4. 重要属性

frameInterval

NSInteger类型的值，用来设置间隔多少帧调用一次selector方法，默认值是1，即每帧都调用一次。

duration

readOnly 的CFTimeInterval值，表示两次屏幕刷新之间的时间间隔。需要注意的是，该属性在target的selector被首次调用以后才会被赋值。 selector的调用间隔时间计算方式是：调用间隔时间 = duration × frameInterval。

三、GCD方式

执行一次

重复执行

PS:NSTimer的内存泄露问题

NSTimer

fire

我们先用 NSTimer 来做个简单的计时器，每隔5秒钟在控制台输出 Fire 。比较想当然的做法是这样的：

运行之后确实在控制台每隔3秒钟输出一次 Fire ，然而当我们从这个界面跳转到其他界面的时候却发现：控制台还在源源不断的输出着 Fire 。看来 Timer 并没有停止。

invalidate

既然没有停止，那我们在 DemoViewController 的 dealloc 里加上 invalidate 的方法：

再次运行，还是没有停止。原因是 Timer 添加到 Runloop 的时候，会被 Runloop 强引用：

然后 Timer 又会有一个对 Target 的强引用（也就是 self ）：

也就是说 NSTimer 强引用了 self ，导致 self 一直不能被释放掉，所以也就走不到 self 的 dealloc 里。

既然如此，那我们可以再加个 invalidate 按钮：

嗯这样就可以了。（在 SOF 上有人说该在 invalidate 之后执行 _timer = nil ，未能理解为什么，如果你知道原因可以告诉我：）

在 invalidate 方法的文档里还有这这样一段话：

You must send this message from the thread on which the timer was installed. If you send this message from another thread, the input source associated with the timer may not be removed from its run loop, which could prevent the thread from exiting properly.

NSTimer 在哪个线程创建就要在哪个线程停止，否则会导致资源不能被正确的释放。看起来各种坑还不少。

dealloc

那么问题来了：如果我就是想让这个 NSTimer 一直输出，直到 DemoViewController 销毁了才停止，我该如何让它停止呢？

NSTimer 被 Runloop 强引用了，如果要释放就要调用 invalidate 方法。

但是我想在 DemoViewController 的 dealloc 里调用 invalidate 方法，但是 self 被 NSTimer 强引用了。

所以我还是要释放 NSTimer 先，然而不调用 invalidate 方法就不能释放它。

然而你不进入到 dealloc 方法里我又不能调用 invalidate 方法。

嗯…

HWWeakTimer

weakSelf

问题的关键就在于 self 被 NSTimer 强引用了，如果我们能打破这个强引用问题自然而然就解决了。所以一个很简单的想法就是：weakSelf：

然而这并没有什么卵用，这里的 __weak 和 __strong 唯一的区别就是：如果在这两行代码执行的期间 self 被释放了， NSTimer 的 target 会变成 nil 。

target

既然没办法通过 __weak 把 self 抽离出来，我们可以造个假的 target 给 NSTimer 。这个假的 target 类似于一个中间的代理人，它做的唯一的工作就是挺身而出接下了 NSTimer 的强引用。类声明如下：

然后我们再封装个假的 scheduledTimerWithTimeInterval 方法，但是在调用的时候已经偷梁换柱了：

再次运行，问题解决。

block

如果能用 block 来调用 NSTimer 那岂不是更好了。我们可以这样来实现：

这样我们就可以直接在 block 里写相关逻辑了：

嗯就是这样。

More

把上面的的代码简单的封装到了 HWWeakTimer 中，欢迎试用。

参考文献：

NStimer

How to stop/invalidate NStimer

Weak Reference to NSTimer Target To Prevent Retain Cycle

performSelector may cause a leak because its selector is unknown