Android中消息機制簡述
前幾天，和同事探討了一下Android中的消息機制，探究了消息的發送和接收過程以及與線程之間的關系。雖然我們經常使用這些基礎的東西，但對于其內部原理的了解，能使我們更加容易、合理地架構系統，并避免一些低級錯誤。
Android中的Handler, Looper, MessageQueue和Thread，對于這部分的內容，將分成4小節來描述：
1.職責與關系
2.消息循環
3.線程與更新
4.幾點小結
1） 接下來，我們開始這部分的內容，首先了解一下各自的職責及相互之間的關系。
職責
Message：消息，其中包含了消息ID，消息處理對象以及處理的數據等，由MessageQueue統一列隊，終由Handler處理。
Handler：處理者，負責Message的發送及處理。使用Handler時，需要實現handleMessage(Message msg)方法來對特定的Message進行處理，例如更新UI等。
MessageQueue：消息隊列，用來存放Handler發送過來的消息，并按照FIFO規則執行。當然，存放Message并非實際意義的保存，而是將Message以鏈表的方式串聯起來的，等待Looper的抽取。
Looper：消息泵，不斷地從MessageQueue中抽取Message執行。因此，一個MessageQueue需要一個Looper。
Thread：線程，負責調度整個消息循環，即消息循環的執行場所。
關系
Handler，Looper和MessageQueue就是簡單的三角關系。Looper和MessageQueue一一對應，創建一個Looper的同時，會創建一個MessageQueue。而Handler與它們的關系，只是簡單的聚集關系，即Handler里會引用當前線程里的特定Looper和MessageQueue。
這樣說來，多個Handler都可以共享同一Looper和MessageQueue了。當然，這些Handler也就運行在同一個線程里。
2） 接下來，我們簡單地看一下消息的循環過程：
生成
- Message msg = mHandler.obtainMessage();
- msg.what = what;
- msg.sendToTarget();
發送
- MessageQueue queue = mQueue;
- if (queue != null) {
- msg.target = this;
- sent = queue.enqueueMessage(msg, uptimeMillis);
- }
在Handler.java的sendMessageAtTime(Message msg, long uptimeMillis)方法中，我們看到，它找到它所引用的MessageQueue，然后將Message的target設定成自己（目的是為了在處理消息環節，Message能找到正確的Handler），再將這個Message納入到消息隊列中。
抽取
- Looper me = myLooper();
- MessageQueue queue = me.mQueue;
- while (true) {
- Message msg = queue.next(); // might block
- if (msg != null) {
- if (msg.target == null) {
- // No target is a magic identifier for the quit message.
- return;
- }
- msg.target.dispatchMessage(msg);
- msg.recycle();
- }
- }
在Looper.java的loop()函數里，我們看到，這里有一個死循環，不斷地從MessageQueue中獲取下一個（next方法）Message，然后通過Message中攜帶的target信息，交由正確的Handler處理（dispatchMessage方法）。
處理
- if (msg.callback != null) {
- handleCallback(msg);
- } else {
- if (mCallback != null) {
- if (mCallback.handleMessage(msg)) {
- return;
- }
- }
- handleMessage(msg);
- }
在Handler.java的dispatchMessage(Message msg)方法里，其中的一個分支就是調用handleMessage方法來處理這條Message，而這也正是我們在職責處描述使用Handler時需要實現handleMessage(Message msg)的原因。
至于dispatchMessage方法中的另外一個分支，我將會在后面的內容中說明。
至此，我們看到，一個Message經由Handler的發送，MessageQueue的入隊，Looper的抽取，又再一次地回到Handler的懷抱。而繞的這一圈，也正好幫助我們將同步操作變成了異步操作。
3）剩下的部分，我們將討論一下Handler所處的線程及更新UI的方式。
在主線程（UI線程）里，如果創建Handler時不傳入Looper對象，那么將直接使用主線程（UI線程）的Looper對象（系統已經幫我們創建了）；在其它線程里，如果創建Handler時不傳入Looper對象，那么，這個Handler將不能接收處理消息。在這種情況下，通用的作法是：
- class LooperThread extends Thread {
- public Handler mHandler;
- public void run() {
- Looper.prepare();
- mHandler = new Handler() {
- public void handleMessage(Message msg) {
- // process incoming messages here
- }
- };
- Looper.loop();
- }
- }
在創建Handler之前，為該線程準備好一個Looper（Looper.prepare），然后讓這個Looper跑起來（Looper.loop），抽取Message，這樣，Handler才能正常工作。
因此，Handler處理消息總是在創建Handler的線程里運行。而我們的消息處理中，不乏更新UI的操作，不正確的線程直接更新UI將引發異常。因此，需要時刻關心Handler在哪個線程里創建的。
如何更新UI才能不出異常呢？SDK告訴我們，有以下4種方式可以從其它線程訪問UI線程：
· Activity.runOnUiThread(Runnable)
· View.post(Runnable)
· View.postDelayed(Runnable, long)
· Handler
其中，重點說一下的是View.post(Runnable)方法。在post(Runnable action)方法里，View獲得當前線程（即UI線程）的Handler，然后將action對象post到Handler里。在Handler里，它將傳遞過來的action對象包裝成一個Message（Message的callback為action），然后將其投入UI線程的消息循環中。在Handler再次處理該Message時，有一條分支（未解釋的那條）就是為它所設，直接調用runnable的run方法。而此時，已經路由到UI線程里，因此，我們可以毫無顧慮的來更新UI。
4） 幾點小結
· Handler的處理過程運行在創建Handler的線程里
· 一個Looper對應一個MessageQueue
· 一個線程對應一個Looper
· 一個Looper可以對應多個Handler
· 不確定當前線程時，更新UI時盡量調用post方法
