建站
咨詢
售后
建站咨詢
新聞中心
一、前言
倒計(jì)時(shí)這種，每秒更新 UI 的需求，應(yīng)該算是比較常見的了。最常見的場景，就是驗(yàn)證碼發(fā)送超時(shí)重試的邏輯，這個(gè)邏輯中需要一個(gè)倒計(jì)時(shí)的邏輯去每秒修改 UI ，讓倒計(jì)時(shí)做到用戶可感知。
那么倒計(jì)時(shí)的邏輯，需要如何做到***?
一個(gè)倒計(jì)時(shí)，最少要有兩個(gè)要求：準(zhǔn)、穩(wěn)。
準(zhǔn)就是說，一個(gè) 2 分鐘的倒計(jì)時(shí)，就應(yīng)該執(zhí)行兩分鐘，穩(wěn)的意思就是說，每次同步 UI 的更新，都是差不多間隔 1s。
二、實(shí)現(xiàn)思路
1、每次延遲 1s 通知 UI 更新
倒計(jì)時(shí)說白了就是一個(gè)間隔固定時(shí)間去做一件固定任務(wù)，這樣的功能，最簡單的就是使用 Handler.postDelayed() 去間隔執(zhí)行。
那么我們寫一個(gè) CountdownUtils 的類，先看看它的結(jié)構(gòu)。
可以看到，它是基于一個(gè) Handler 來做延遲的。這個(gè)邏輯非常的簡單，直接上代碼了。
使用起來也非常的簡單，傳遞進(jìn)去 2 分鐘的時(shí)長。
- new CountdownUtils(120).start()
看看 Log 輸出的結(jié)果，
從 Log 上看，確實(shí)是完成了一個(gè)倒計(jì)時(shí)的功能，一秒一秒一直到 0 ，但是這里為了觀察準(zhǔn)不準(zhǔn)，對倒計(jì)時(shí)執(zhí)行的完整時(shí)間做了一個(gè)間隔記錄，看到問題了嗎?一個(gè) 120s 的倒計(jì)時(shí)，卻執(zhí)行了124s 左右。
這個(gè)問題實(shí)際上是因?yàn)?Handler.postDelayed() 的間隔時(shí)長，并不是準(zhǔn)確的間隔指定的時(shí)長，具體什么時(shí)候執(zhí)行，實(shí)際上是看線程的調(diào)度的。這種總時(shí)長差異的問題，換了 Timer 什么的去實(shí)現(xiàn)也是無法解決的。
這個(gè)問題，在一些驗(yàn)證碼倒計(jì)時(shí)的場景下，沒有參照事件點(diǎn)，每個(gè)倒計(jì)時(shí)，誤差幾十毫秒，基本上是用戶無感知的。但是有一些情況下，例如視頻播放的倒計(jì)時(shí)，這種有參照的情況下，幾分鐘的倒計(jì)時(shí)，誤差幾秒鐘，就是非常明顯的 Bug 了。
這就是不穩(wěn)，那么，如何把倒計(jì)時(shí)做的穩(wěn)呢?
2、 使用 CountDownTimer
實(shí)現(xiàn)一個(gè)倒計(jì)時(shí)， Android 其實(shí)是提供了對應(yīng)的支持類的，那就是 CounDownTimer ，它處于 android.os 包下的，完全可以實(shí)現(xiàn)一個(gè)倒計(jì)時(shí)的邏輯。
我們先看看它是如何使用的。
CountDownTimer 的使用非常的簡單，在 onTick() 中監(jiān)聽倒計(jì)時(shí)的變化，結(jié)束的時(shí)候會去調(diào)用 onFinish()。
繼續(xù)運(yùn)行一下看看 Log 的輸出情況。
這個(gè)總時(shí)長，誤差已經(jīng)是毫秒級的了，看樣子比我們自己實(shí)現(xiàn)的好很多。
再仔細(xì)看看，onTick() 方法回調(diào)的參數(shù)，是一個(gè) 毫秒 為單位的數(shù)值，而這個(gè)數(shù)值，其實(shí)是有誤差的，但是這個(gè)其實(shí)也不影響，只需要對其進(jìn)行四舍五入的運(yùn)算，就可以得到正確的倒計(jì)時(shí)秒數(shù)。
例如：2830 就是 3s，1828 就是 2s。
但是再仔細(xì)看看，就能發(fā)現(xiàn)問題，如果使用這種方式來處理倒計(jì)時(shí)的話，你會發(fā)現(xiàn)，拿不到 1s 的狀態(tài)，會直接 3s - 2s - finish，這個(gè)問題，從 Log 上也可以反應(yīng)出來。
這就很尷尬了，有沒有參照物，都是一個(gè) Bug，只能先看看 CountDownTimer 的源碼了，它是如何保證總時(shí)長的準(zhǔn)確的。
從 CountDownTimer 的結(jié)構(gòu)可以看出，它實(shí)際上也是使用 mHandler 來做的延遲，繼續(xù)看最重要的 Handler 的實(shí)現(xiàn)代碼。
在 handleMessage() 中，用到了一個(gè) SystemClock.elapsedRealtime() ，它實(shí)際上獲取到的是一個(gè) 系統(tǒng) 啟動(dòng)之后，到現(xiàn)在的一個(gè)絕對時(shí)間，包含系統(tǒng)休眠的間隔。
但是，它并不是關(guān)鍵，關(guān)鍵在于，CountDownTimer 會使用這個(gè)時(shí)間，每次計(jì)算出一個(gè)相對 1s 間隔的差值，也就是說，每次都去糾正這個(gè)誤差值，來保證最終的總時(shí)長誤差是毫秒級(其實(shí)就是***一次 postDelayed() 的誤差)。
既然找到了 CountDownTimer 保證時(shí)間準(zhǔn)確行的關(guān)鍵點(diǎn)，那么我們可以改寫***個(gè) Demo 的代碼，來解決沒有 1s 狀態(tài)的問題。
3、 動(dòng)態(tài)計(jì)算 delay 值
沒什么好說的，就是計(jì)算此次間隔耗時(shí)，然后比 1s 多出來的毫秒值，從下一個(gè) 1s 中減去，來糾正間隔時(shí)長。
既然實(shí)現(xiàn)了之后，我們再看看輸出的 Log。
可以看到，interval 每一次都在動(dòng)態(tài)的調(diào)整，每一秒的狀態(tài)都會更新出去，并且總時(shí)長也保證誤差在毫秒級的，基本上***解決了倒計(jì)時(shí)的問題了。
三、小結(jié)
一個(gè)倒計(jì)時(shí)，簡簡單單使用 Handler.postDelayed() 也是無法保證準(zhǔn)和穩(wěn)的。細(xì)節(jié)決定成敗，一個(gè)倒計(jì)時(shí)也是可以做到***的。
【本文為專欄作者“張旸”的原創(chuàng)稿件，轉(zhuǎn)載請通過微信公眾號聯(lián)系作者獲取授權(quán)】
網(wǎng)頁名稱：把倒計(jì)時(shí)做到極致
本文URL：http://m.5511xx.com/article/djsoidi.html
