把倒计时做到极致

版权声明：

本账号发布文章均来自公众号，承香墨影（cxmyDev），版权归承香墨影所有。

未经允许，不得转载。

一、前言

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

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

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

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

二、实现思路

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

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

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

可以看到，它是基于一个 Handler 来做延迟的。这个逻辑非常的简单，直接上代码了。

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

new CountdownUtils(120).start()

看看 Log 输出的结果，

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 状态的问题。

3、 动态计算 delay 值

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

既然实现了之后，我们再看看输出的 Log。

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

三、小结

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

公众号二维码.jpg