iOS之UITableView计时器的实现方式总结(NSTimer、DispatchSource、CADisplayLink)

前言

最近工作比较忙，但是还是出来更新博客了。今天博客中所涉及的内容并不复杂，都是一些平时常见的一些问题，通过这篇博客算是对uitableview中使用定时器的几种方式进行总结。本篇博客会给出在tableview中使用nstimer或者dispatchsourcer中常见的五种方式。当然下方第一种方式是常规做法，不过也是uitableview中使用nstimer的一个坑。其他三种方式是为了绕过这个坑的解决方案。

当然，本篇博客共涉及到了uitableview中使用定时器的四种实现方式，当然应该也还有其他实现方式，只不过目前我没有涉及到。欢迎在评论区提供其他实现方式，我会及时的整合到目前的demo中。

接下来我们先来总结一下本篇博客所涉及的四种方式：

• 第一种就是直接在tableview的cell上使用nstimer，当然这种方式是有问题的，稍后会介绍。
• 第二种是将nstimer添加到当前线程所对应的runloop中的commonmodes中。
• 第三种是通过dispatch中的timersource来实现定时器。
• 第四种是开启一个新的子线程，将nstimer添加到这个子线程中的runloop中，并使用defaultrunloopmodes来执行。
• 第五种方式就是使用cadisplaylink来实现。

下方我们将会根据具体的示例来详细的介绍以上这五种实现方式。

一、在cell中直接使用nstimer

首先我们按照常规做法，直接在uitableview的cell上添加相应的nstimer, 并使用scheduledtimer执行相应的代码块。这种方式没有什么特殊的就是对timer的直接使用。下方是我们本部分的timer的使用代码，当然是使用swift来实现的，不过与oc的代码差不多。代码如下所示 ：

上述代码比较简单，就是在cell上添加了一个定时器，然后没1秒更新一次时间，并在cell的timelabel上显示，运行效果如下所示。从该运行效果中我们不难发现，当我们滑动tableview时，该定时器就停止了工作。具体原因就是当前线程的runloop在tableview滑动时将defaultmode切换到了trackingrunloopmode。因为timer默认是添加在runloop上的defaultmode上的，当mode切换后timer就停止了运行。

但是当停止滑动后，mode又切换了回来，所以timer有可以正常工作了。

　　

为了进一步看一下mode的切换，我们可以在相应的地方获取当前线程的runloop并且打印对应的mode。下方代码就是在tableview所对应的vc上添加的，我们在viewdidload()、viewdidappear()以及scrollviewdidscroll()这个代理方法中对当前线程所对应的runloop下的currentmode进行了打印，其代码如下。

下方就是最终的运行结果。从输出结果中我们不难看出，在viewdidload()方法中打印的current mode为uiinitializationrunloopmode, 从该mode的名字中我们不难发现，该mode负责ui的初始化。在viewdidapperar()方法中，也就是ui显示后，runloop的mode切换成了kcfrunloopdefaultmode。紧接着，我们去滑动tableview，然后在scrollviewdidscroll()代理方法中打印滑动时当前runloop所对应的mode。从下方运行结果不难看出，当tableview滑动时，打印出的currentmodel为uitrackingrunloopmode。当停止滑动后，点击show current mode按钮获取当前mode时，打印的有时runloopdefaultmode。具体如下所示：

二、将timer添加到commonmode中

上一部分的定时器是不能正常运行的，因为nstimer对象默认添加到了当前runloop的defaultmode中，而在切换成trackingrunloopmode时，定时器就停止了工作。解决该问题最直接方法是，将nstimer在trackingrunloopmode中也添加一份。这样的话无论是在defaultmode还是trackingrunloopmode中，定时器都会正常的工作。

如果你对runloop比较熟悉的话，可以知道commonmodes就是defaultmode和trackingrunloopmode的集合，所以我们只需要将nstimer对象与当前线程所对应的runloop中的commonmodes关联即可，具体代码如下所示：

上述代码与第一部分的代码不同的地方在于我们将创建好的定时器添加到了当前runloop中的commonmodes中，这样的话可以保证tableview在滑动时定时器也可以正常运行。上述代码最终的运行效果如下所示。

　　

从该运行效果我们不难发现，当该tableview滚动式，其cell上的定时器是可以正常工作的。但是当我们滑动右上角的这个tableview时，第一个的tableview中的定时器也是不能正常工作的，因为这些tableview都在主线程中工作，也就是说这些tableview所在的runloop是同一个。

三、将timer添加到子线程的runloop下的defaultmode中

接下来我们来看另一种解决方案，就是开启一个新的子线程，然后将timer添加到这个子线程所对应的runloop中。当然因为是子线程的runloop，在添加timer时，我们可以将timer添加到子线程中的runloop中的defaultmode中。添加完毕后，手动运行该runloop。

因为是在子线程中添加的timer, timer肯定是在子线程中工作的，所以在更新ui时，我们需要在主线程中进行更新，具体代码如下所示：

在上述代码中我们可以看到我们使用全局的并行队列来异步创建了一个timer对象，然后将该对象添加进了该异步线程中的defaultrunloopmode中，然后运行该runloop。当然在子线程中更新ui还是需要在主线程中去操作的。下方就是上述代码的运行效果。从该效果中我们不难看出，当滑动tableview时定时器是可以正常工作的。

　　

四、dispatchtimersource

接下来我们就不使用nstimer来实现定时器了。在之前的博客中聊gcd时其中用到了dispatchtimersource来实现定时器。接下来我们就在tableview的cell上添加dispatchtimersource，然后看一下运行效果。当然下方代码片段我们是在全局队列中添加的dispatchtimersource，在主线程中进行更新。当然我们也可以在mainqueue中添加dispatchtimersource，这样也是可以正常工作的。当然我们不建议在mainqueue中做，因为在编程时尽量的把一些和主线程关联不太大的操作放到子线程中去做。代码如下所示：

接下来我们来看一下上述的代码的运行效果，从该效果中我们可以看出该定时器是可以正常工作的。

　　

五、cadisplaylink

接下来我们来使用cadisplaylink来实现定时器功能，在之前的博客中我们也使用过cadisplaylink，不过是用来计算fps的。下方代码片段中我们就使用cadisplaylink来实现的定时器。cadisplaylink可以添加到runloop中，runloop的每一次循环都会触发cadisplaylink所关联的方法。在屏幕不卡顿的情况下，每次循环的时间时1/60秒。

下方代码，为了不让屏幕的卡顿等引起的主线程所对应的runloop阻塞所造成的定时器不精确的问题。我们开启了一个新的线程，并且将cadisplaylink对象添加到这个子线程的runloop中，然后在主线程中更新ui即可。具体代码如下：

我们对上述代码运行，下方是其对应的运行结果。从下方运行结果中我们不难看出，在tableview滚动时该定时器也是可以正常运行的。当然该方式实现的定时器的精度是比较高的。

　　

经过上述五大部分，我们罗列了定时器的几种实现方式，通过对比我们不难发现其优劣性。上述定时器中dispatchsourcetime以及cadisplaylink的精度要比nstimer的精度要高。从代码实现中我们不难看出cadisplaylink的精度是比较高的。

本篇博客所涉及代码的github分享地址为：https://github.com/lizelu/nstimerwithrunloop （本地下载）

总结

以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对的支持。