一、前言
倒计时这种，每秒更新 UI 的需求，应该算是比较常见的了。最常见的场景，就是验证码发送超时重试的逻辑，这个逻辑中需要一个倒计时的逻辑去每秒修改 UI ，让倒计时做到用户可感知。
那么倒计时的逻辑，需要如何做到***?
一个倒计时，最少要有两个要求：准、稳。
准就是说，一个 2 分钟的倒计时，就应该执行两分钟，稳的意思就是说，每次同步 UI 的更新，都是差不多间隔 1s。
二、实现思路
1、每次延迟 1s 通知 UI 更新
倒计时说白了就是一个间隔固定时间去做一件固定任务，这样的功能，最简单的就是使用 Handler.postDelayed() 去间隔执行。
那么我们写一个 CountdownUtils 的类，先看看它的结构。
可以看到，它是基于一个 Handler 来做延迟的。这个逻辑非常的简单，直接上代码了。
使用起来也非常的简单，传递进去 2 分钟的时长。
- new CountdownUtils(120).start()
看看 Log 输出的结果，
从 Log 上看，确实是完成了一个倒计时的功能，一秒一秒一直到 0 ，但是这里为了观察准不准，对倒计时执行的完整时间做了一个间隔记录，看到问题了吗?一个 120s 的倒计时，却执行了124s 左右。
这个问题实际上是因为 Handler.postDelayed() 的间隔时长，并不是准确的间隔指定的时长，具体什么时候执行，实际上是看线程的调度的。这种总时长差异的问题，换了 Timer 什么的去实现也是无法解决的。
这个问题，在一些验证码倒计时的场景下，没有参照事件点，每个倒计时，误差几十毫秒，基本上是用户无感知的。但是有一些情况下，例如视频播放的倒计时，这种有参照的情况下，几分钟的倒计时，误差几秒钟，就是非常明显的 Bug 了。
这就是不稳，那么，如何把倒计时做的稳呢?
2、 使用 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 状态的问题。
3、 动态计算 delay 值
没什么好说的，就是计算此次间隔耗时，然后比 1s 多出来的毫秒值，从下一个 1s 中减去，来纠正间隔时长。
既然实现了之后，我们再看看输出的 Log。
可以看到，interval 每一次都在动态的调整，每一秒的状态都会更新出去，并且总时长也保证误差在毫秒级的，基本上***解决了倒计时的问题了。
三、小结
一个倒计时，简简单单使用 Handler.postDelayed() 也是无法保证准和稳的。细节决定成败，一个倒计时也是可以做到***的。
【本文为51CTO专栏作者“张旸”的原创稿件，转载请通过微信公众号联系作者获取授权】
