帶著這篇去通關所有Handler的提問（三）
寫在前面：
大家久等了，前陣花了一周的時間去畢業旅行，所以更新就拖延了一陣，話不多說，我們來回顧一下本系列的前兩篇文章的思路和知識點：
在第一篇文章中，我們總結了Android系統不允許在子線程更新UI的原因，本質上是線程安全問題，從而引出了Handler。
在第二篇文章中，我們又分析了三種在子線程更新UI的方法，分別是：View.post(param); Activity.runOnUIThread(param); Handler，當我們對這三種方法的源碼進一步分析發現，其實都是對Handler做了一些封裝，所以本文我們就來正式全面探究有關Handler的知識點。
當時我去面試的四家公司，都問到了Handler的相關知識，有深有淺，所以重要程度不言而喻。面試官拿起你的簡歷，讓你談談Handler，你僅僅在表象上回答了Android線程通信的機理，然后面試官緊接著問了你如下的幾個問題：
Handler是屬于哪個類的？
Handler、Looper、MessageQueue何時建立的相互關系？
主線程的Looper和MessageQueue是何時創建的？
在同一線程中，Looper和MessageQueue是怎樣的數量對應關系，與Handler又是怎樣的數量對應關系？
MessageQueue中消息為空，線程阻塞掛起等待，為什么不會造成ANR？
有關Handler的內存泄漏是怎么一回事？
so...光知道表象很可能是不夠的，而且還給自己挖了一個坑，所以我們對于一個知識點的探尋要全面充分一點。下面正式開始本文。
Windows和Android消息機制的區別
現在的操作系統普遍采用消息驅動模式。Windows操作系統就是典型的消息驅動模型。但是，Android的消息處理機制和Windows的消息處理機制又不太相同。我給大家畫了圖，看看二者的區別。
通過消息機制圖的對比，Windows消息處理模型中，存在一個系統的消息隊列，這個隊列是整個進程的核心，幾乎所有的動作都要轉換成消息，然后放到這個隊列中，由主線程統一處理。
而Android沒有全局的消息隊列，消息隊列是和某個線程相關聯在一起的。每個線程最多有一個消息隊列，消息的取出和處理，也在這個線程本身中完成。
也就是說，Android中，如果你想在當前線程使用消息模型，則必須構建一個消息隊列，而消息機制的相關主要類是：Looper、Handler、MessageQueue、Message。
我們并不著急去翻看這些類的源碼，理清楚底層實現的邏輯，而且先在宏觀表象上看看，Android消息機制是如何運行的？
Android消息機制的宏觀原理
先來看一張Android消息處理類之間的關系圖
我們從表象上解釋一下原理，Handler負責將Message發送至當前線程的MessageQueue中，Looper時時刻刻監視著MessageQueue，將符合時間要求的Message取出，再帶給發送消息的那個Handler通過HandleMessage處理。
對于消息機制的理解不能僅僅停留在這一步，下面我們從源碼的角度分析一下具體的邏輯細節。
Android消息機制相關類的源碼分析
其實寫這篇文章之前，我就一直在思考，站在什么角度展開這個機制的描述，更容易讓大家理解接受。思來想去，我覺得還是以一個Message游歷的形式去描寫，會顯著有趣和清晰一點。
Message：
人在邊境X（子線程）服役的士兵Message慵懶得躺在一個人數為50（池中最大數量）的軍營（Message池）中。不料這時突然接到了上司的obtain()命令（據說obtain命令更加節省軍費），讓他去首都（主線程）告訴中央領導一些神秘代碼。小Message慌亂地整理了下衣角和帽子，帶上信封，準備出發。
上司讓士兵Message收拾完畢之后等待一個神秘人的電話，并且囑咐他：到了首都之后，0是這次任務的暗號。
Message是消息的載體，Message設計成為Parcelable類的派生類，這表明Message可以通過binder來跨進程發送。
通常我們都會用obtain()方法去創建Message，如果消息池中有Message有，則取出，沒有，再重新創建。這樣可以防止對象的重復創建，節省資源。
"鈴鈴鈴..."小Message接到了一個陌生男子的電話。
“我叫handler，來自activity大本營，是你這次任務的接受者，一會我帶你去首都的消息中心去報道。”
Handler
來自Activity大本營Handler部門是整個消息機制系統的核心部門，當然部門下有很多個 Handler，這次協助小Message任務的叫mHandler。Handler部門下的員工都有一個特點，就是只關心自己的message。
Handler屬于Activity，創建任何一個Handler都屬于重寫了Activity中的Handler。
在Handler的構造中，默認完成了對當前線程Looper的綁定，至于Looper是誰，一會再談。
通過Looper.myLooper()獲取了當前線程保存的Looper實例，又通過mLooper.mQueue獲取了Looper中的MessageQueue實例。在此時，mhandler實例與looper和messageQueue實例，關聯上了。
mHandler神情驕傲得對小Message說：我已經跟首都的消息中心打好了招呼，準備接收你了，現在有兩種車，一種車名叫“send”，一種叫“post”，你想坐哪輛去首都都可以，不過要根據你上司的命令，選擇車種類下對應的型號哦~
-
send
這里寫圖片描述 -
post
這里寫圖片描述
從代碼的實現上來看，post方法也是在使用send類的方法在發送消息，只是他們的參數要求是Runnable對象。
通過對Handler源碼的分析，發現除了sendMessageAtFrontOfQueue方法之外，其余任何send的相關方法，都經過層層包裝走到了sendMessageAtTime方法中，我們來看看源碼：
這時小Message和mHandler一同上了車牌號為“sendMessage”的車，行駛在一條叫“enqueueMessage”的高速公路上，mHandler向一無所知的小Message介紹說，每個像他一樣的Message都是通過enqueueMessage路進入MessageQueue的。我們是要去首都的MessageQueue中心，其實你的消息到時候也是我處理的，不過現在還不是時候哦，因為我很忙。
enqueueMessage是MessageQueue的方法，用來將Message根據時間排序，放入到MessageQueue中。其中msg.target = this，是保證每個發送Message的Handler也能處理這個Message。
Looper
路上的時間不短不長，mHandler依然為小Message熱心介紹著MessageQueue和Looper
“在每個駐扎地（線程）中，只有一個MessageQueue和一個Looper，他們兩個是相殺相愛，同生共死的好基友，Looper是個跑不死的郵差，一直負責取出MessageQueue中的Message”
"不過通常只有首都（主線程）的Looper和MessageQueue是創建好的，其他地方需要我們人為地創建哦~"
Looper類提供了prepare方法來創建Looper。可以看到，當重復創建Looper時，會拋出異常，也就是說，每個線程只有一個Looper。
緊接著在Looper的構造方法中，又創建了與它一一對應的MessageQueue，既然Looper在一個線程中是唯一的，所以MessageQueue也是唯一的。
在Android中，ActivityThread的main方法是程序的入口，主線程的Looper和MessageQueue就是在此時創建的。
可以看到，在main方法中，既創建了Looper，也調用了Looper.loop()方法。
mHandler和小Message通過enqueueMessage路來到了MessageQueue中，進入之前，門衛仔仔細細地給小Message貼上了以下標簽：
“mHandler負責帶入”
“處理時間為0ms”
并且告訴小Message，一定要按照時間順序排隊。
進入隊伍中，Looper大哥正在不辭辛勞的將一個又一個跟小Message一樣的士兵帶走。
分析一下loop方法，有一個for的死循環，不斷地調用queue.next方法，在消息隊列中取Message。并且在Message中取出target，這個target其實就是發送消息的handler，調用它的dispatchMessage方法。
首都的MessageQueue中心雖然人很多，但是大家都井井有條的排著隊伍，Looper老哥看了一眼手里的名單，叫到了小Message的名字，看了一眼小Message身上的標簽，對他說：“喔，又是mHandler帶來的人啊，那把你交給他處理了”
忐忑不安的小Message看到了一個熟悉的身影，mHandler就在面前，顯然mHandler有些健忘，可能是接觸了太多跟小Message一樣的人，為了讓mHandler想起自己，小Message說出了上司交給他的暗號0.
可以看見dispatchMessage方法中的邏輯比較簡單，具體就是如果mCallback不為空，則調用mCallback的handleMessage()方法，否則直接調用Handler的handleMessage()方法，并將消息對象作為參數傳遞過去。
在handlerMessage()方法中，小Message出色的完成了自己的任務。
寫在后面：
下一篇中，我們會探討一下為什么loop方法中for死循環不會造成ANR，有一些有關Handler的使用技巧，以及可能造成的內存泄漏，敬請期待。
