我們知道android是基于Looper消息循環(huán)的系統(tǒng)，我們通過Handler向Looper包含的MessageQueue投遞Message, 不過我們常見的用法是這樣吧？

一般我們比較少接觸MessageQueue, 其實(shí)它內(nèi)部的IdleHandler接口有很多有趣的用法，首先看看它的定義：

簡(jiǎn)而言之，就是在looper里面的message暫時(shí)處理完了，這個(gè)時(shí)候會(huì)回調(diào)這個(gè)接口，返回false，那么就會(huì)移除它，返回true就會(huì)在下次message處理完了的時(shí)候繼續(xù)回調(diào)，讓我們看看它有哪些有趣的用法吧~~

一、提供一個(gè)android沒有的聲明周期回調(diào)時(shí)機(jī)

如果有這種需求，想要在某個(gè)activity繪制完成去做一些事情，那這個(gè)時(shí)機(jī)是什么時(shí)候呢？有同學(xué)可能覺得onResume()是一個(gè)合適的機(jī)會(huì)，不是可是這個(gè)onResume() 真的是各種繪制都已經(jīng)完成才回調(diào)的嗎？No, too naive ~~

你看谷老師說了，onStart是用戶可見，onResume是用戶可交互，谷老師可沒說onResume是繪制完成吧~那么android那些耗時(shí)的measure, layout, draw是在什么時(shí)候執(zhí)行的呢？它們跟onResume()又有何關(guān)系呢？讓我們先來看看源碼吧~

1. ActivityThread.java

我們知道app的進(jìn)程其實(shí)是ActivityThread, 那么activity的生命周期自然是它來執(zhí)行了，

performResumeActivity就是回調(diào)onResume了， 我們繼續(xù)看wm.addView方法， 這個(gè)ViewManager是一個(gè)接口，其實(shí)現(xiàn)者是WindowManagerImpl

2.WindowManagerImpl.java

這個(gè)mGlobal是WindowManagerGlobal對(duì)象，我們繼續(xù)

3.WindowManagerGlobal.java

這里我們new 出了ViewRootImpl對(duì)象， 我們知道這個(gè)對(duì)象就是android view的根對(duì)象了，負(fù)責(zé)view繪制的measure, layout, draw的巨長(zhǎng)的方法 performTraversals就是這個(gè)類的，我們繼續(xù)看setView方法

4.ViewRootImpl.java

這個(gè)函數(shù)調(diào)用了關(guān)鍵方法requestLayout(), 我們繼續(xù)跟蹤，順便說下，后面一連串的BadTokenException就是我們常常遇到的dialog相關(guān)拋出的，也有些特殊場(chǎng)景也會(huì)出這個(gè)異常，可以到這里查看線索。

調(diào)用了scheduleTraversals， 從名字就能看出來了吧：

它往Choreographer里面post了一個(gè)runnable， 這個(gè)Choreographer是android負(fù)責(zé)幀率刷新相關(guān)的東西，我們暫時(shí)可以不關(guān)注它，可以理解為往主線程post一個(gè)消息是一樣的，順便說下這個(gè)Choreographer可以做幀率檢測(cè)相關(guān)的東西，，可以用于卡頓檢測(cè)什么的···

我們看這個(gè)runnable果然是去執(zhí)行了那個(gè)巨長(zhǎng)無比的函數(shù)performTraversals函數(shù), 現(xiàn)在我們可以總結(jié)下流程了：

結(jié)論：所以如果我們想在界面繪制出來后做點(diǎn)什么，那么在onResume里面顯然是不合適的，它先于measure等流程了， 有人可能會(huì)說在onResume里面post一個(gè)runnable可以嗎？還是不行，因?yàn)槟菢泳蜁?huì)變成這個(gè)樣子

所以你的行為一樣會(huì)在繪制之前執(zhí)行，這個(gè)時(shí)候我們的主角IdleHandler就發(fā)揮作用了，我們前面說了，它是在looper里面message暫時(shí)執(zhí)行完畢了就會(huì)回調(diào)，顧名思義嘛，Idle就是隊(duì)列為空的意思，那么我們的onResume和measure, layout, draw都是一個(gè)個(gè)message的話，這個(gè)IdleHandler就提供了一個(gè)它們都執(zhí)行完畢的回調(diào)了，大概就是這樣

說了這么多，那么現(xiàn)在獲取到這個(gè)時(shí)機(jī)有什么用呢？ look！！

這個(gè)是我們地圖的公交詳情頁(yè)面， 進(jìn)入之后產(chǎn)品要求左邊的頁(yè)卡需要展示，可以看到左邊的頁(yè)卡是一個(gè)非常復(fù)雜的布局，那么進(jìn)入之后的效果可以明顯看到頭部的展示信息是先顯示空白再100毫秒左右之后才展示出來的，原因就是這個(gè)頁(yè)卡的內(nèi)容比較復(fù)雜，用數(shù)據(jù)向它填充的時(shí)候花了較長(zhǎng)時(shí)間，代碼如下：

可以看到這個(gè)detailView就是這個(gè)側(cè)滑的頁(yè)卡了，填充里面的數(shù)據(jù)花了90ms，如果這個(gè)時(shí)間是用在了界面view繪制之前的話，就會(huì)出現(xiàn)以上的效果了，view先是白的，再出現(xiàn)，這樣就體驗(yàn)不好了，如果我們把它放到IdleHandler里面呢？代碼如下：

效果是這樣的：

看出不同了嗎？頂部的頁(yè)卡先展示出來了，這樣體驗(yàn)是不是會(huì)更好一些呢。雖然只有短短90ms，不過我們做app也應(yīng)該關(guān)注這種細(xì)節(jié)優(yōu)化的，是吧~ 這個(gè)做法也提供了一種思路，android本身提供的activity框架和fragment框架并沒有提供繪制完成的回調(diào)，如果我們自己實(shí)現(xiàn)一個(gè)框架，就可以使用這個(gè)IdleHandler來實(shí)現(xiàn)一個(gè)onRenderFinished這種回調(diào)了。

二、可以結(jié)合HandlerThread, 用于單線程消息通知器

我們先思考一個(gè)問題，如果有一個(gè)model數(shù)據(jù)管理模塊，怎么設(shè)計(jì)？比如地圖的收藏模塊的model部分。就是下面這個(gè)圖的小星星：

它原來的model設(shè)計(jì)大概是這個(gè)樣子的：

由于這個(gè)model是單例的，而且是多線程可以訪問的，所以它的增刪改查都加上了鎖，而且由于外部訪問需要遍歷有哪些收藏點(diǎn)，所以外部遍歷列表也需要加鎖，大概是這樣的：

因?yàn)槭嵌嗑€程可訪問的，如果遍歷不加鎖的話，其他線程刪除了一個(gè)收藏，就會(huì)crash的，原來的這樣設(shè)計(jì)有幾個(gè)不好的地方：

1. 外部使用者需要關(guān)系鎖的使用，增加了負(fù)擔(dān)，不用還不安全

2. 如果在主線程加鎖的話，可能另一個(gè)線程執(zhí)行操作會(huì)阻塞主線程造成anr

總之，多線程代碼就是容易出錯(cuò)，而且真的出錯(cuò)的時(shí)候查起來太費(fèi)勁了，目前收藏夾模塊就有N多bug，所以我想用單線程來解決這個(gè)問題，由于model層的訪問需要數(shù)據(jù)庫(kù)和網(wǎng)絡(luò)等，所以需要異步線程，那么單線程隊(duì)列+異步線程，首先想到的就是HandlerThread, 大概架構(gòu)如下：

現(xiàn)在，我們把原來多線程的邏輯改到了單線程里面，各種收藏的model共用一個(gè)HandlerThread，這樣我們?cè)鰟h改查都不用加鎖了，出錯(cuò)幾率大大減小，而且這種model的設(shè)計(jì)有點(diǎn)類似插件的意思，可以很方便的增加其他收藏。

Ok， 那么跟我們的主題IdleHandler有什么關(guān)系呢？思考這樣一個(gè)問題，地圖上的小星星需要實(shí)時(shí)更新，也就是model的任何變化都需要顯示到地圖上，那么收藏的小星星就應(yīng)該作為model的觀察者，以前的做法是向收藏model注冊(cè)監(jiān)聽，在每一個(gè)增刪改查操作后都對(duì)觀察者回調(diào)，大概是這樣：

這樣有一個(gè)小小的問題，就是如果有一個(gè)操作生成10個(gè)快速連續(xù)的增刪改查操作，那么我們的UI就會(huì)收到10次回調(diào)，而這種場(chǎng)景下我們其實(shí)只需要最后一次回調(diào)就夠了，中間操作其實(shí)不用刷新UI的。

那么現(xiàn)在改成單線程模型，我們又該如何處理這個(gè)問題呢？當(dāng)然我們也能在每個(gè)post到異步線程的runnable里面去回調(diào)觀察者，但這樣未免不夠優(yōu)雅，所以這個(gè)時(shí)候IdleHandler不就又可以發(fā)揮作用了嗎？它是在消息暫時(shí)處理完的時(shí)候回調(diào)的呀，不是很符合我們的時(shí)機(jī)么，對(duì)吧？

就是這個(gè)樣子了，這里為什么不用第一個(gè)場(chǎng)景下的Looper.myQueue().addIdleHandler()呢？注意這個(gè)地方Looper.myQueue()如果在主線程調(diào)用就會(huì)使用主線程looper了，所以我選擇反射這個(gè)HandlerThread的looper來設(shè)置它，這個(gè)IdleHandler我們返回了true, 表示我們要長(zhǎng)期監(jiān)聽消息隊(duì)列，因?yàn)榉祷豧alse，下次就沒有回調(diào)了哦。

好了，結(jié)論是這個(gè)地方IdleHandler用作了一個(gè)消息的觸發(fā)器，是不是挺有意思的呢？

三、 結(jié)語(yǔ)

如果你沒有用過它，從今天開始試試吧，這篇文章只是我個(gè)人的一點(diǎn)小思路，說不定這個(gè)IdleHandler有很多其他的用法呢~~

騰訊WeTest提供上千臺(tái)真實(shí)手機(jī)，隨時(shí)隨地進(jìn)行測(cè)試，保障應(yīng)用/手游品質(zhì)。節(jié)省百萬(wàn)硬件費(fèi)用，加速敏捷研發(fā)流程。

同時(shí)騰訊WeTest兼容性測(cè)試團(tuán)隊(duì)積累了10年的手游測(cè)試經(jīng)驗(yàn)，旨在通過制定針對(duì)性的測(cè)試方案，精準(zhǔn)選取目標(biāo)機(jī)型，執(zhí)行專業(yè)、完整的測(cè)試用例，來提前發(fā)現(xiàn)游戲版本的兼容性問題，針對(duì)性地做出修正和優(yōu)化，來保障手游產(chǎn)品的質(zhì)量。目前該團(tuán)隊(duì)已經(jīng)支持所有騰訊在研和運(yùn)營(yíng)的手游項(xiàng)目。