把倒計時作到極致

版權聲明：

本帳號發佈文章均來自公衆號，承香墨影（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