詳解Android中Handler的內(nèi)部實現(xiàn)原理
本文主要是對Handler和消息循環(huán)的實現(xiàn)原理進行源碼分析,如果不熟悉Handler可以參見博文《詳解Android中Handler的使用方法》,里面對Android為何以引入Handler機制以及如何使用Handler做了講解。
概括來說,Handler是Android中引入的一種讓開發(fā)者參與處理線程中消息循環(huán)的機制。我們在使用Handler的時候與Message打交道最多,Message是Hanlder機制向開發(fā)人員暴露出來的相關(guān)類,可以通過Message類完成大部分操作Handler的功能。但作為程序員,我不能只知道怎么用Handler,還要知道其內(nèi)部如何實現(xiàn)的。Handler的內(nèi)部實現(xiàn)主要涉及到如下幾個類: Thread、MessageQueue和Looper。這幾類之間的關(guān)系可以用如下的圖來簡單說明:
Thread是最基礎(chǔ)的,Looper和MessageQueue都構(gòu)建在Thread之上,Handler又構(gòu)建在Looper和MessageQueue之上,我們通過Handler間接地與下面這幾個相對底層一點的類打交道。
一圖勝千言
我們在本文討論了Thread、MessageQueue、Looper以及Hanlder的之間的關(guān)系,我們可以通過如下一張傳送帶的圖來更形象的理解他們之間的關(guān)系。
在現(xiàn)實生活的生產(chǎn)生活中,存在著各種各樣的傳送帶,傳送帶上面灑滿了各種貨物,傳送帶在發(fā)動機滾輪的帶動下一直在向前滾動,不斷有新的貨物放置在傳送帶的一端,貨物在傳送帶的帶動下送到另一端進行收集處理。
我們可以把傳送帶上的貨物看做是一個個的Message,而承載這些貨物的傳送帶就是裝載Message的消息隊列MessageQueue。傳送帶是靠發(fā)送機滾輪帶動起來轉(zhuǎn)動的,我們可以把發(fā)送機滾輪看做是Looper,而發(fā)動機的轉(zhuǎn)動是需要電源的,我們可以把電源看做是線程Thread,所有的消息循環(huán)的一切操作都是基于某個線程的。一切準(zhǔn)備就緒,我們只需要按下電源開關(guān)發(fā)動機就會轉(zhuǎn)動起來,這個開關(guān)就是Looper的loop方法,當(dāng)我們按下開關(guān)的時候,我們就相當(dāng)于執(zhí)行了Looper的loop方法,此時Looper就會驅(qū)動著消息隊列循環(huán)起來。
那Hanlder在傳送帶模型中相當(dāng)于什么呢?我們可以將Handler看做是放入貨物以及取走貨物的管道:貨物從一端順著管道劃入傳送帶,貨物又從另一端順著管道劃出傳送帶。我們在傳送帶的一端放入貨物的操作就相當(dāng)于我們調(diào)用了Handler的sendMessageXXX、sendEmptyMessageXXX或postXXX方法,這就把Message對象放入到了消息隊列MessageQueue中了。當(dāng)貨物從傳送帶的另一端順著管道劃出時,我們就相當(dāng)于調(diào)用了Hanlder的dispatchMessage方法,在該方法中我們完成對Message的處理。
下面重點介紹Handler:
Handler是暴露給開發(fā)者最頂層的一個類,其構(gòu)建在Thread、Looper與MessageQueue之上。
Handler具有多個構(gòu)造函數(shù),簽名分別如下所示:
- 1. publicHandler()
- 2. publicHandler(Callbackcallback)
- 3. publicHandler(Looperlooper)
- 4. publicHandler(Looperlooper, Callbackcallback)
第1個和第2個構(gòu)造函數(shù)都沒有傳遞Looper,這兩個構(gòu)造函數(shù)都將通過調(diào)用Looper.myLooper()獲取當(dāng)前線程綁定的Looper對象,然后將該Looper對象保存到名為mLooper的成員字段中。
第3個和第4個構(gòu)造函數(shù)傳遞了Looper對象,這兩個構(gòu)造函數(shù)會將該Looper保存到名為mLooper的成員字段中。
第2個和第4個構(gòu)造函數(shù)還傳遞了Callback對象,Callback是Handler中的內(nèi)部接口,需要實現(xiàn)其內(nèi)部的handleMessage方法,Callback代碼如下:
public interface Callback { public boolean handleMessage(Message msg); }
Handler.Callback是用來處理Message的一種手段,如果沒有傳遞該參數(shù),那么就應(yīng)該重寫Handler的handleMessage方法,也就是說為了使得Handler能夠處理Message,我們有兩種辦法:
1. 向Hanlder的構(gòu)造函數(shù)傳入一個Handler.Callback對象,并實現(xiàn)Handler.Callback的handleMessage方法
2. 無需向Hanlder的構(gòu)造函數(shù)傳入Handler.Callback對象,但是需要重寫Handler本身的handleMessage方法
也就是說無論哪種方式,我們都得通過某種方式實現(xiàn)handleMessage方法,這點與Java中對Thread的設(shè)計有異曲同工之處。
在Java中,如果我們想使用多線程,有兩種辦法:
1. 向Thread的構(gòu)造函數(shù)傳入一個Runnable對象,并實現(xiàn)Runnable的run方法
2. 無需向Thread的構(gòu)造函數(shù)傳入Runnable對象,但是要重寫Thread本身的run方法
所以只要用過多線程Thread,應(yīng)該就對Hanlder這種需要實現(xiàn)handleMessage的兩種方式了然于心了。
我們知道通過sendMessageXXX系列方法可以向消息隊列中添加消息,我們通過源碼可以看出這些方法的調(diào)用順序,
sendMessage調(diào)用了sendMessageDelayed,sendMessageDelayed又調(diào)用了sendMessageAtTime。
Handler中還有一系列的sendEmptyMessageXXX方法,而這些sendEmptyMessageXXX方法在其內(nèi)部又分別調(diào)用了其對應(yīng)的sendMessageXXX方法。
通過以下調(diào)用關(guān)系圖我們可以看的更清楚些:
由此可見所有的sendMessageXXX方法和sendEmptyMessageXXX最終都調(diào)用了sendMessageAtTime方法。
我們再來看看postXXX方法,會發(fā)現(xiàn)postXXX方法在其內(nèi)部又調(diào)用了對應(yīng)的sendMessageXXX方法,我們可以查看下sendMessage的源碼:
public final boolean post(Runnable r) { return sendMessageDelayed(getPostMessage(r), 0); }
可以看到內(nèi)部調(diào)用了getPostMessage方法,該方法傳入一個Runnable對象,得到一個Message對象,getPostMessage的源碼如下:
private static Message getPostMessage(Runnable r) { Message m = Message.obtain(); m.callback = r; return m; }
通過上面的代碼我們可以看到在getPostMessage方法中,我們創(chuàng)建了一個Message對象,并將傳入的Runnable對象賦值給Message的callback成員字段,然后返回該Message,然后在post方法中該攜帶有Runnable信息的Message傳入到sendMessageDelayed方法中。由此我們可以看到所有的postXXX方法內(nèi)部都需要借助sendMessageXXX方法來實現(xiàn),所以postXXX與sendMessageXXX并不是對立關(guān)系,而是postXXX依賴sendMessageXXX,所以postXXX方法可以通過sendMessageXXX方法向消息隊列中傳入消息,只不過通過postXXX方法向消息隊列中傳入的消息都攜帶有Runnable對象(Message.callback)。
我們可以通過如下關(guān)系圖看清楚postXXX系列方法與sendMessageXXX方法之間的調(diào)用關(guān)系:
通過分別分析sendEmptyMessageXXX、postXXX方法與sendMessageXXX方法之間的關(guān)系,我們可以看到在Handler中所有可以直接或間接向消息隊列發(fā)送Message的方法最終都調(diào)用了sendMessageAtTime方法,該方法的源碼如下:
public boolean sendMessageAtTime(Message msg, long uptimeMillis) { MessageQueue queue = mQueue; if (queue == null) { RuntimeException e = new RuntimeException( this + " sendMessageAtTime() called with no mQueue"); Log.w("Looper", e.getMessage(), e); return false; } //注意下面這行代碼 return enqueueMessage(queue, msg, uptimeMillis); }
該方法內(nèi)部調(diào)用了enqueueMessage方法,該方法的源碼如下:
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) { //注意下面這行代碼 msg.target = this; if (mAsynchronous) { msg.setAsynchronous(true); } //注意下面這行代碼 return queue.enqueueMessage(msg, uptimeMillis); }
在該方法中有兩件事需要注意:
- 1. msg.target = this
該代碼將Message的target綁定為當(dāng)前的Handler
- 2. queue.enqueueMessage
變量queue表示的是Handler所綁定的消息隊列MessageQueue,通過調(diào)用queue.enqueueMessage(msg, uptimeMillis)我們將Message放入到消息隊列中。
所以我們通過下圖可以看到完整的方法調(diào)用順序:
我們在分析Looper.loop()的源碼時發(fā)現(xiàn),Looper一直在不斷的從消息隊列中通過MessageQueue的next方法獲取Message,然后通過代碼msg.target.dispatchMessage(msg)讓該msg所綁定的Handler(Message.target)執(zhí)行dispatchMessage方法以實現(xiàn)對Message的處理。
Handler的dispatchMessage的源碼如下:
public void dispatchMessage(Message msg) { //注意下面這行代碼 if (msg.callback != null) { handleCallback(msg); } else { //注意下面這行代碼 if (mCallback != null) { if (mCallback.handleMessage(msg)) { return; } } //注意下面這行代碼 handleMessage(msg); } }
我們來分析下這段代碼:
1.首先會判斷msg.callback存不存在,msg.callback是Runnable類型,如果msg.callback存在,那么說明該Message是通過執(zhí)行Handler的postXXX系列方法將Message放入到消息隊列中的,這種情況下會執(zhí)行handleCallback(msg), handleCallback源碼如下:
private static void handleCallback(Message message) { message.callback.run(); }
這樣我們我們就清楚地看到我們執(zhí)行了msg.callback的run方法,也就是執(zhí)行了postXXX所傳遞的Runnable對象的run方法。
2.如果我們不是通過postXXX系列方法將Message放入到消息隊列中的,那么msg.callback就是null,代碼繼續(xù)往下執(zhí)行,接著我們會判斷Handler的成員字段mCallback存不存在。mCallback是Hanlder.Callback類型的,我們在上面提到過,在Handler的構(gòu)造函數(shù)中我們可以傳遞Hanlder.Callback類型的對象,該對象需要實現(xiàn)handleMessage方法,如果我們在構(gòu)造函數(shù)中傳遞了該Callback對象,那么我們就會讓Callback的handleMessage方法來處理Message。
3.如果我們在構(gòu)造函數(shù)中沒有傳入Callback類型的對象,那么mCallback就為null,那么我們會調(diào)用Handler自身的hanldeMessage方法,該方法默認(rèn)是個空方法,我們需要自己是重寫實現(xiàn)該方法。
綜上,我們可以看到Handler提供了三種途徑處理Message,而且處理有前后優(yōu)先級之分:首先嘗試讓postXXX中傳遞的Runnable執(zhí)行,其次嘗試讓Handler構(gòu)造函數(shù)中傳入的Callback的handleMessage方法處理,最后才是讓Handler自身的handleMessage方法處理Message。
希望本文對于大家理解Android中的Handler和消息循環(huán)機制有所幫助。
相關(guān)文章
Android控件ViewFlipper仿淘寶頭條垂直滾動廣告條
這篇文章主要為大家詳細介紹了Android控件ViewFlipper仿淘寶頭條垂直滾動廣告條,具有一定的參考價值,感興趣的小伙伴們可以參考一下2017-05-05Android App啟動圖啟動界面(Splash)的簡單實現(xiàn)代碼
這篇文章主要介紹了Android App啟動圖啟動界面(Splash)的簡單實現(xiàn)代碼,本文通過實例圖文詳解相結(jié)合給大家介紹的非常詳細,對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值,需要的朋友可以參考下2020-05-05Android 使用Vitamio打造自己的萬能播放器(5)——在線播放(播放優(yōu)酷視頻)
本文主要介紹Android Vitamio的使用,這里給大家提供效果圖和代碼實例,來說明Vitamio組件播放網(wǎng)絡(luò)視頻,有需要的小伙伴可以參考下2016-07-07Android 實現(xiàn)圖片模糊、高斯模糊、毛玻璃效果的三種方法
在前幾天寫過一個使用glide-transformations的方法實現(xiàn)高斯模糊的方法,今天偶然間有發(fā)現(xiàn)一個大神寫的另一個方法,感覺挺不錯的,分享一下2016-12-12Android程序開發(fā)之使用Design包實現(xiàn)QQ動畫側(cè)滑效果和滑動菜單導(dǎo)航
這篇文章主要介紹了Android程序開發(fā)之使用Design包實現(xiàn)QQ動畫側(cè)滑效果和滑動菜單導(dǎo)航的相關(guān)資料,非常不錯,具有參考借鑒價值,需要的朋友可以參考下2016-07-07Android App將數(shù)據(jù)寫入內(nèi)部存儲和外部存儲的示例
這篇文章主要介紹了Android App將數(shù)據(jù)寫入內(nèi)部存儲和外部存儲的示例,使用外部存儲即訪問并寫入SD卡,需要的朋友可以參考下2016-03-03