把倒计时作到极致

版权声明：

本帐号发布文章均来自公众号，承香墨影（cxmyDev），版权归承香墨影全部。

未经容许，不得转载。

1、前言

倒计时这种，每秒更新 UI 的需求，应该算是比较常见的了。最多见的场景，就是验证码发送超时重试的逻辑，这个逻辑中须要一个倒计时的逻辑去每秒修改 UI ，让倒计时作到用户可感知。

那么倒计时的逻辑，须要如何作到极致？

一个倒计时，最少要有两个要求：准、稳。

准就是说，一个 2 分钟的倒计时，就应该执行两分钟，稳的意思就是说，每次同步 UI 的更新，都是差很少间隔 1s。

2、实现思路

一、每次延迟 1s 通知 UI 更新

倒计时说白了就是一个间隔固定时间去作一件固定任务，这样的功能，最简单的就是使用 Handler.postDelayed() 去间隔执行。

那么咱们写一个 CountdownUtils 的类，先看看它的结构。

能够看到，它是基于一个 Handler 来作延迟的。这个逻辑很是的简单，直接上代码了。

使用起来也很是的简单，传递进去 2 分钟的时长。

new CountdownUtils(120).start()复制代码

看看 Log 输出的结果，

/cd-log1.png

从 Log 上看，确实是完成了一个倒计时的功能，一秒一秒一直到 0 ，可是这里为了观察准不许，对倒计时执行的完整时间作了一个间隔记录，看到问题了吗？一个 120s 的倒计时，却执行了 124s 左右。

这个问题其实是由于 Handler.postDelayed() 的间隔时长，并非准确的间隔指定的时长，具体何时执行，其实是看线程的调度的。这种总时长差别的问题，换了 Timer 什么的去实现也是没法解决的。

这个问题，在一些验证码倒计时的场景下，没有参照事件点，每一个倒计时，偏差几十毫秒，基本上是用户无感知的。可是有一些状况下，例如视频播放的倒计时，这种有参照的状况下，几分钟的倒计时，偏差几秒钟，就是很是明显的 Bug 了。

这就是不稳，那么，如何把倒计时作的稳呢？

二、 使用 CountDownTimer

实现一个倒计时， Android 实际上是提供了对应的支持类的，那就是 CounDownTimer ，它处于 android.os 包下的，彻底能够实现一个倒计时的逻辑。

咱们先看看它是如何使用的。

CountDownTimer 的使用很是的简单，在 onTick() 中监听倒计时的变化，结束的时候会去调用 onFinish()。

继续运行一下看看 Log 的输出状况。

这个总时长，偏差已是毫秒级的了，看样子比咱们本身实现的好不少。

再仔细看看，onTick() 方法回调的参数，是一个 毫秒 为单位的数值，而这个数值，实际上是有偏差的，可是这个其实也不影响，只须要对其进行四舍五入的运算，就能够获得正确的倒计时秒数。

例如：2830 就是 3s，1828 就是 2s。

可是再仔细看看，就能发现问题，若是使用这种方式来处理倒计时的话，你会发现，拿不到 1s 的状态，会直接 3s - 2s - finish，这个问题，从 Log 上也能够反应出来。

这就很尴尬了，有没有参照物，都是一个 Bug，只能先看看 CountDownTimer 的源码了，它是如何保证总时长的准确的。

从 CountDownTimer 的结构能够看出，它实际上也是使用 mHandler 来作的延迟，继续看最重要的 Handler 的实现代码。

在 handleMessage() 中，用到了一个 SystemClock.elapsedRealtime() ，它实际上获取到的是一个 系统 启动以后，到如今的一个绝对时间，包含系统休眠的间隔。

可是，它并非关键，关键在于，CountDownTimer 会使用这个时间，每次计算出一个相对 1s 间隔的差值，也就是说，每次都去纠正这个偏差值，来保证最终的总时长偏差是毫秒级（其实就是最后一次 postDelayed() 的偏差）。

既然找到了 CountDownTimer 保证时间准确行的关键点，那么咱们能够改写第一个 Demo 的代码，来解决没有 1s 状态的问题。

三、 动态计算 delay 值

没什么好说的，就是计算这次间隔耗时，而后比 1s 多出来的毫秒值，从下一个 1s 中减去，来纠正间隔时长。

既然实现了以后，咱们再看看输出的 Log。

能够看到，interval 每一次都在动态的调整，每一秒的状态都会更新出去，而且总时长也保证偏差在毫秒级的，基本上完美解决了倒计时的问题了。

3、小结

一个倒计时，简简单单使用 Handler.postDelayed() 也是没法保证准和稳的。细节决定成败，一个倒计时也是能够作到极致的。

公众号二维码.jpg