Android之消息機制問題

時間 2019-11-21

標籤 android 消息機制問題欄目 Android 简体版

原文原文鏈接

目錄介紹

6.0.0.1 談談消息機制Hander做用？有哪些要素？流程是怎樣的？簡單說一下你的見解！
6.0.0.2 爲何一個線程只有一個Looper、只有一個MessageQueue，能夠有多個Handler？
6.0.0.3 能夠在子線程直接new一個Handler嗎？會出現什麼問題，如何在子線程中使用handler？
6.0.0.4 說一下Handler內存泄漏有哪些？形成形成內存泄漏緣由是什麼？如何解決handler形成的內存泄漏？
6.0.0.5 Activity如何自動綁定Looper？主線程中的Looper死循環和binder線程中的死循環有哪些區別？
6.0.0.6 爲何系統不建議在子線程訪問UI，不對UI控件的訪問加上鎖機制的緣由？
6.0.0.7 Looper.loop是一個死循環，拿不到須要處理的Message就會阻塞，那在UI線程中爲何不會致使ANR？
6.0.0.8 Handler.sendMessageDelayed()怎麼實現延遲的？結合Looper.loop()循環中，Message=messageQueue.next()和MessageQueue.enqueueMessage()分析。
6.0.0.9 Message能夠如何建立？哪一種效果更好，爲何？
6.0.1.0 MessageQueue做用是幹什麼的？MessageQueue的定義是什麼？MessageQueue主要工做原理是怎樣的？
6.0.1.1 子線程更新UI有哪些方式？runOnUiThread如何實現子線程更新UI？View.post(Runnable r)更新UI？
6.0.1.3 使用Hanlder的postDealy()後消息隊列會發生什麼變化？
6.0.1.4 ThreadLocal有什麼做用？如何避免UI線程儘可能只作跟UI相關的工做?
6.0.1.5 爲何一個線程只有一個Looper、只有一個MessageQueue，能夠有多個Handler？

好消息

博客筆記大彙總【16年3月到至今】，包括Java基礎及深刻知識點，Android技術博客，Python學習筆記等等，還包括平時開發中遇到的bug彙總，固然也在工做之餘收集了大量的面試題，長期更新維護而且修正，持續完善……開源的文件是markdown格式的！同時也開源了生活博客，從12年起，積累共計N篇[近100萬字，陸續搬到網上]，轉載請註明出處，謝謝！
連接地址：github.com/yangchong21…
若是以爲好，能夠star一下，謝謝！固然也歡迎提出建議，萬事起於忽微，量變引發質變！

6.0.0.1 談談消息機制Hander做用？有哪些要素？流程是怎樣的？簡單說一下你的見解！

做用：
- 跨線程通訊。當子線程中進行耗時操做後須要更新UI時，經過Handler將有關UI的操做切換到主線程中執行。
四要素：
- Message（消息）：須要被傳遞的消息，其中包含了消息ID，消息處理對象以及處理的數據等，由MessageQueue統一列隊，最終由Handler處理。技術博客大總結
- MessageQueue（消息隊列）：用來存放Handler發送過來的消息，內部經過單鏈表的數據結構來維護消息列表，等待Looper的抽取。
- Handler（處理者）：負責Message的發送及處理。經過 Handler.sendMessage() 向消息池發送各類消息事件；經過 Handler.handleMessage() 處理相應的消息事件。
- Looper（消息泵）：經過Looper.loop()不斷地從MessageQueue中抽取Message，按分發機制將消息分發給目標處理者。
具體流程
- Handler.sendMessage()發送消息時，會經過MessageQueue.enqueueMessage()向MessageQueue中添加一條消息；
- 經過Looper.loop()開啓循環後，不斷輪詢調用MessageQueue.next()；
- 調用目標Handler.dispatchMessage()去傳遞消息，目標Handler收到消息後調用Handler.handlerMessage()處理消息。

6.0.0.2 Handler的post方法和view的post方法有什麼區別？爲何說要避免在子線程中手動建立looper？

Handler的post方法實現很簡單，以下所示

mHandler.post(new Runnable() {
    @Override
    public void run() {

    }
});

public final boolean post(Runnable r){
   return  sendMessageDelayed(getPostMessage(r), 0);
}
複製代碼

view的post方法也很簡單，以下所示

能夠發現其調用的就是activity中默認保存的handler對象的post方法

public boolean post(Runnable action) {
    final AttachInfo attachInfo = mAttachInfo;
    if (attachInfo != null) {
        return attachInfo.mHandler.post(action);
    }
    ViewRootImpl.getRunQueue().post(action);
    return true;
}

public void post(Runnable action) {
    postDelayed(action, 0);
}

public void postDelayed(Runnable action, long delayMillis) {
    final HandlerAction handlerAction = new HandlerAction(action, delayMillis);

    synchronized (this) {
        if (mActions == null) {
            mActions = new HandlerAction[4];
        }
        mActions = GrowingArrayUtils.append(mActions, mCount, handlerAction);
        mCount++;
    }
}
複製代碼

爲何說要避免在子線程中手動建立looper？
- 下面這種使用方式，是很是危險的一種作法
- 在子線程中，若是手動爲其建立Looper，那麼在全部的事情完成之後應該調用quit方法來終止消息循環，不然這個子線程就會一直處於等待的狀態，而若是退出Looper之後，這個線程就會馬上終止，所以建議不須要的時候終止Looper。(【 Looper.myLooper().quit(); 】)
```
new Thread(new Runnable() {
    @Override
    public void run() {
        Looper.prepare();
        Toast.makeText(MainActivity.this, "run on Thread", Toast.LENGTH_SHORT).show();
        Looper.loop();
    }
}).start();
複製代碼
```

6.0.0.3 能夠在子線程直接new一個Handler嗎？會出現什麼問題，那該怎麼作？

直接在子線程中建立handler，看看會出現什麼狀況？博客
- 運行後能夠得出在子線程中定義Handler對象出錯，難道Handler對象的定義或者是初始化只能在主線程中？其實不是這樣的，錯誤信息中提示的已經很明顯了，在初始化Handler對象以前須要調用Looper.prepare()方法。
- Handler的工做是依賴於Looper的，而Looper（與消息隊列）又是屬於某一個線程（ThreadLocal是線程內部的數據存儲類，經過它能夠在指定線程中存儲數據，其餘線程則沒法獲取到），其餘線程不能訪問。所以Handler就是間接跟線程是綁定在一塊兒了。所以要使用Handler必需要保證Handler所建立的線程中有Looper對象而且啓動循環。由於子線程中默認是沒有Looper的，因此會報錯。
```
tv.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View v) {
        new Thread() {
            @Override
            public void run() {
                Handler mHandler = new Handler() {
                    @Override
                    public void handleMessage(Message msg) {
                        if (msg.what == 1) {
                            Log.i(TAG, "在子線程中定義Handler，接收並處理消息");
                        }
                    }
                };
            }
        }.start();
    }
});
複製代碼
```

如何正確運行。在這裏問一個問題，在子線程中能夠吐司嗎？答案是能夠的，只不過又條件，詳細能夠看這篇文章02.Toast源碼深度分析

這樣程序已經不會報錯，那麼這說明初始化Handler對象的時候咱們是須要調用Looper.prepare()的，那麼主線程中爲何能夠直接初始化Handler呢？難道是主線程建立handler對象的時候，會自動調用Looper.prepare()方法的嗎？博客

tv.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View v) {
        new Thread() {
            @Override
            public void run() {
                Looper.prepare();
                Handler mHandler = new Handler() {
                    @Override
                    public void handleMessage(Message msg) {
                        if (msg.what == 1) {
                            Log.i(TAG, "在子線程中定義Handler，接收並處理消息");
                        }
                    }
                };
                //獲取Looper對象
                mLooper = Looper.myLooper();
                Looper.loop();
                //在適當的時候退出Looper的消息循環，防止內存泄漏
                mLooper.quit();
            }
        }.start();
    }
});
複製代碼

6.0.0.4 說一下Handler內存泄漏有哪些？形成形成內存泄漏緣由是什麼？如何解決handler形成的內存泄漏？

解決Handler內存泄露主要2點
- 有延時消息，要在Activity銷燬的時候移除Messages
- 匿名內部類致使的泄露改成匿名靜態內部類，而且對上下文或者Activity使用弱引用。博客

問題代碼

public class MainActivity extends AppCompatActivity {
    private Handler mHandler = new Handler();
    private TextView mTextView;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        mTextView = (TextView) findViewById(R.id.text);        //模擬內存泄露
        mHandler.postDelayed(new Runnable() {
            @Override
            public void run() {
                mTextView.setText("yangchong");
            }
        }, 2000);
    }
}
複製代碼

形成內存泄漏緣由分析
- 上述代碼經過內部類的方式建立mHandler對象,此時mHandler會隱式地持有一個外部類對象引用這裏就是MainActivity，當執行postDelayed方法時，該方法會將你的Handler裝入一個Message，並把這條Message推到MessageQueue中，MessageQueue是在一個Looper線程中不斷輪詢處理消息，那麼當這個Activity退出時消息隊列中還有未處理的消息或者正在處理消息，而消息隊列中的Message持有mHandler實例的引用，mHandler又持有Activity的引用，因此致使該Activity的內存資源沒法及時回收，引起內存泄漏。

如何解決handler形成的內存泄漏

第一種解決辦法
- 要想避免Handler引發內存泄漏問題，須要咱們在Activity關閉退出的時候的移除消息隊列中全部消息和全部的Runnable。
- 上述代碼只需在onDestroy()函數中調用mHandler.removeCallbacksAndMessages(null);就好了。
```
@Override
protected void onDestroy() {
    super.onDestroy();
    if(handler!=null){
        handler.removeCallbacksAndMessages(null);
        handler = null;
    }
}
複製代碼
```

第二種解決方案

使用弱引用解決handler內存泄漏問題，關於代碼案例，能夠參考個人開源項目：github.com/yangchong21…

//自定義handler
public static class HandlerHolder extends Handler {
    WeakReference<OnReceiveMessageListener> mListenerWeakReference;
    /**
     * @param listener 收到消息回調接口
     */
    HandlerHolder(OnReceiveMessageListener listener) {
        mListenerWeakReference = new WeakReference<>(listener);
    }

    @Override
    public void handleMessage(Message msg) {
        if (mListenerWeakReference!=null && mListenerWeakReference.get()!=null){
            mListenerWeakReference.get().handlerMessage(msg);
        }
    }
}

//建立handler對象
private HandlerHolder handler = new HandlerHolder(new OnReceiveMessageListener() {
    @Override
    public void handlerMessage(Message msg) {
        switch (msg.what){
            case 1:
                TextView textView1 = (TextView) msg.obj;
                showBottomInAnimation(textView1);
                break;
            case 2:
                TextView textView2 = (TextView) msg.obj;
                showBottomOutAnimation(textView2);
                break;
        }
    }
});

//發送消息
Message message = new Message();
message.what = 1;
message.obj = textView;
handler.sendMessageDelayed(message,time);


即推薦使用靜態內部類 + WeakReference 這種方式。每次使用前注意判空。
複製代碼

6.0.0.5 Activity如何自動綁定Looper？主線程中的Looper死循環和binder線程中的死循環有哪些區別？

主線程如何自動調用Looper.prepare()。那就是ActivityThread，而且在main方法中咱們會看到主線程也是經過Looper方式來維持一個消息循環。那麼這個死循環會不會致使應用卡死，即便不會的話，它會慢慢的消耗愈來愈多的資源嗎？
- 對於線程便是一段可執行的代碼，當可執行代碼執行完成後，線程生命週期便該終止了，線程退出。而對於主線程，咱們是毫不但願會被運行一段時間，本身就退出，那麼如何保證能一直存活呢？簡單作法就是可執行代碼是能一直執行下去的，死循環便能保證不會被退出。
- 例如，binder線程也是採用死循環的方法，經過循環方式不一樣與Binder驅動進行讀寫操做，固然並不是簡單地死循環，無消息時會休眠。但這裏可能又引起了另外一個問題，既然是死循環又如何去處理其餘事務呢？經過建立新線程的方式。真正會卡死主線程的操做是在回調方法onCreate/onStart/onResume等操做時間過長，會致使掉幀，甚至發生ANR，looper.loop自己不會致使應用卡死。
- 能夠看到Looper.prepare()方法在這裏調用，因此在主線程中能夠直接初始化Handler了。
```
//ActivityThread類中的main方法中重點代碼
//注意：這裏省略了許多代碼
public static void main(String[] args) {
    ……
    //建立Looper和MessageQueue對象，用於處理主線程的消息
    Looper.prepareMainLooper();
    //建立ActivityThread對象
    ActivityThread thread = new ActivityThread();
    //創建Binder通道 (建立新線程)
    thread.attach(false);
    ……
    //消息循環運行
    Looper.loop();
    //若是能執行下面方法，說明應用崩潰或者是退出了...
    throw new RuntimeException("Main thread loop unexpectedly exited");
}
複製代碼
```

而且能夠看到還調用了：Looper.loop()方法，能夠知道一個Handler的標準寫法實際上是這樣的

Looper.prepare();
Handler mHandler = new Handler() {
   @Override
   public void handleMessage(Message msg) {
      if (msg.what == 101) {
         Log.i(TAG, "在子線程中定義Handler，並接收到消息");
       }
   }
};
Looper.loop();
複製代碼

6.0.0.6 Looper.prepare()可否調用屢次？調用屢次會出現什麼狀況？Looper中用什麼存儲消息？

思考：Looper.prepare()可否調用兩次或者屢次

若是運行，則會報錯，並提示prepare中的Excetion信息。由此能夠得出在每一個線程中Looper.prepare()能且只能調用一次

//這裏Looper.prepare()方法調用了兩次
Looper.prepare();
Looper.prepare();
Handler mHandler = new Handler() {
   @Override
   public void handleMessage(Message msg) {
       if (msg.what == 1) {
          Log.i(TAG, "在子線程中定義Handler，並接收到消息。。。");
       }
   }
};
Looper.loop();
複製代碼

Looper中用什麼存儲消息
- 先看一下下面得源代碼
- 能夠看到Looper中有一個ThreadLocal成員變量，熟悉JDK的同窗應該知道，當使用ThreadLocal維護變量時，ThreadLocal爲每一個使用該變量的線程提供獨立的變量副本，因此每個線程均可以獨立地改變本身的副本，而不會影響其它線程所對應的副本。
- 看Looper對象的構造方法，能夠看到在其構造方法中初始化了一個MessageQueue對象。MessageQueue也稱之爲消息隊列，特色是先進先出，底層實現是單鏈表數據結構。
```
private static void prepare(boolean quitAllowed) {
    if (sThreadLocal.get() != null) {
        throw new RuntimeException("Only one Looper may be created per thread");
    }
    sThreadLocal.set(new Looper(quitAllowed));
}

private Looper(boolean quitAllowed) {
    mQueue = new MessageQueue(quitAllowed);
    mThread = Thread.currentThread();
}
複製代碼
```

6.0.0.6 爲何系統不建議在子線程訪問UI，不對UI控件的訪問加上鎖機制的緣由？

出自《Android藝術探索》
這是由於Android的UI控件不是線程安全的，若是在多線程中併發訪問可能會致使UI控件處於不可預期的狀態，那麼爲何系統不對UI控件的訪問加上鎖機制呢？缺點有兩個：
- ①首先加上鎖機制會讓UI訪問的邏輯變得複雜
- ②鎖機制會下降UI訪問的效率，由於鎖機制會阻塞某些線程的執行。
- 因此最簡單且高效的方法就是採用單線程模型來處理UI操做。
爲何說子線程不能更新UI？
- 子線程是不能直接更新UI的。Android實現View更新有兩組方法，分別是invalidate和postInvalidate。前者在UI線程中使用，後者在非UI線程即子線程中使用。換句話說，在子線程調用 invalidate 方法會致使線程不安全。熟悉View工做原理的人都知道，invalidate 方法會通知 view 當即重繪，刷新界面。做一個假設，如今用 invalidate 在子線程中刷新界面，同時UI線程也在用 invalidate 刷新界面，這樣會不會致使界面的刷新不能同步？這就是invalidate不能在子線程中使用的緣由。博客

6.0.0.7 Looper.loop是一個死循環，拿不到須要處理的Message就會阻塞，那在UI線程中爲何不會致使ANR？

問題描述
- 在處理消息的時候使用了Looper.loop()方法，而且在該方法中進入了一個死循環，同時Looper.loop()方法是在主線程中調用的，那麼爲何沒有形成阻塞呢？
ActivityThread中main方法
- ActivityThread類的註釋上能夠知道這個類管理着咱們日常所說的主線程(UI線程)
  - 首先 ActivityThread 並非一個 Thread，就只是一個 final 類而已。咱們常說的主線程就是從這個類的 main 方法開始，main 方法很簡短
```
public static final void main(String[] args) {
    ...
    //建立Looper和MessageQueue
    Looper.prepareMainLooper();
    ...
    //輪詢器開始輪詢
    Looper.loop();
    ...
}
複製代碼
```

Looper.loop()方法無限循環

看看Looper.loop()方法無限循環部分的代碼

while (true) {
   //取出消息隊列的消息，可能會阻塞
   Message msg = queue.next(); // might block
   ...
   //解析消息，分發消息
   msg.target.dispatchMessage(msg);
   ...
}
複製代碼

爲何這個死循環不會形成ANR異常呢？
- 由於Android 的是由事件驅動的，looper.loop() 不斷地接收事件、處理事件，每個點擊觸摸或者說Activity的生命週期都是運行在 Looper.loop() 的控制之下，若是它中止了，應用也就中止了。只能是某一個消息或者說對消息的處理阻塞了 Looper.loop()，而不是 Looper.loop() 阻塞它。技術博客大總結

處理消息handleMessage方法

以下所示

能夠看見Activity的生命週期都是依靠主線程的Looper.loop，當收到不一樣Message時則採用相應措施。
若是某個消息處理時間過長，好比你在onCreate(),onResume()裏面處理耗時操做，那麼下一次的消息好比用戶的點擊事件不能處理了，整個循環就會產生卡頓，時間一長就成了ANR。

public void handleMessage(Message msg) {
    if (DEBUG_MESSAGES) Slog.v(TAG, ">>> handling: " + codeToString(msg.what));
    switch (msg.what) {
        case LAUNCH_ACTIVITY: {
            Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityStart");
            final ActivityClientRecord r = (ActivityClientRecord) msg.obj;
            r.packageInfo = getPackageInfoNoCheck(r.activityInfo.applicationInfo, r.compatInfo);
            handleLaunchActivity(r, null);
            Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
        }
        break;
        case RELAUNCH_ACTIVITY: {
            Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityRestart");
            ActivityClientRecord r = (ActivityClientRecord) msg.obj;
            handleRelaunchActivity(r);
            Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
        }
        break;
        case PAUSE_ACTIVITY:
            Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityPause");
            handlePauseActivity((IBinder) msg.obj, false, (msg.arg1 & 1) != 0, msg.arg2, (msg.arg1 & 2) != 0);
            maybeSnapshot();
            Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
            break;
        case PAUSE_ACTIVITY_FINISHING:
            Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityPause");
            handlePauseActivity((IBinder) msg.obj, true, (msg.arg1 & 1) != 0, msg.arg2, (msg.arg1 & 1) != 0);
            Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
            break;
        ...........
    }
}
複製代碼

loop的循環消耗性能嗎？
- 主線程Looper從消息隊列讀取消息，當讀完全部消息時，主線程阻塞。子線程往消息隊列發送消息，而且往管道文件寫數據，主線程即被喚醒，從管道文件讀取數據，主線程被喚醒只是爲了讀取消息，當消息讀取完畢，再次睡眠。所以loop的循環並不會對CPU性能有過多的消耗。
- 簡單的來講：ActivityThread的main方法主要就是作消息循環，一旦退出消息循環，那麼你的程序也就能夠退出了。

6.0.0.9 Message能夠如何建立？哪一種效果更好，爲何？runOnUiThread如何實現子線程更新UI？

建立Message對象的幾種方式：技術博客大總結
- Message msg = new Message();
- Message msg = Message.obtain();
- Message msg = handler1.obtainMessage();
後兩種方法都是從整個Messge池中返回一個新的Message實例，能有效避免重複Message建立對象，所以更鼓勵這種方式建立Message

runOnUiThread如何實現子線程更新UI

看看源碼，以下所示
若是msg.callback爲空的話，會直接調用咱們的mCallback.handleMessage(msg)，即handler的handlerMessage方法。因爲Handler對象是在主線程中建立的，因此handler的handlerMessage方法的執行也會在主線程中。
在runOnUiThread程序首先會判斷當前線程是不是UI線程，若是是就直接運行，若是不是則post，這時其實質仍是使用的Handler機制來處理線程與UI通信。

public void dispatchMessage(Message msg) {
    if (msg.callback != null) {
        handleCallback(msg);
    } else {
        if (mCallback != null) {
            if (mCallback.handleMessage(msg)) {
                return;
            }
        }
        handleMessage(msg);
    }
}

@Override
public final void runOnUiThread(Runnable action) {
    if (Thread.currentThread() != mUiThread) {
        mHandler.post(action);
    } else {
        action.run();
    }
}
複製代碼

6.0.1.0 MessageQueue做用是幹什麼的？MessageQueue的定義是什麼？MessageQueue主要工做原理是怎樣的？

MessageQueue做用是幹什麼的
- MessageQueue，主要包含2個操做：插入和讀取。
  - 讀取操做會伴隨着刪除操做，插入和讀取對應的方法分別爲enqueueMessage和next，其中enqueueMessage的做用是往消息隊列中插入一條消息，而next的做用是從消息隊列中取出一條消息並將其從消息隊列中移除。
- 雖然MessageQueue叫消息隊列，可是它的內部實現並非用的隊列。
  - 實際上它是經過一個單鏈表的數據結構來維護消息列表，單鏈表在插入和刪除上比較有優點。

MessageQueue的定義是什麼

經過源碼咱們能夠知道，MessageQueue維護了一個消息列表。Messgae並非直接添加到MessageQueue中，而是經過和Looper相關聯的Handler來添加的。在當前線程中能夠經過調用Looper.myQueue()方法來獲取當前線程的MessageQueue。博客

/**
 * Low-level class holding the list of messages to be dispatched by a
 * {@link Looper}.  Messages are not added directly to a MessageQueue,
 * but rather through {@link Handler} objects associated with the Looper.
 * 
 * <p>You can retrieve the MessageQueue for the current thread with
 * {@link Looper#myQueue() Looper.myQueue()}.
 */
public final class MessageQueue
複製代碼

MessageQueue主要工做原理是怎樣的？

源碼以下所示

在Message的源碼中定義了一個成員屬性target，其類型爲Handler。由上面enqueuMessage的源碼，咱們能夠看到，當Message沒有處理其的Handler或該Message正在被處理的時候，都不能正常進入MessageQueue，這一點也是很容易理解的。當線程處於死亡狀態的時候，Message會被回收掉，而再也不進入該線程對應的MessageQueue中。不然，一切正常，enqueMessage就執行單鏈表的插入操做，將Message插入到MessageQueue中。

boolean enqueueMessage(Message msg, long when) {
    if (msg.target == null) {
        throw new IllegalArgumentException("Message must have a target.");
    }
    if (msg.isInUse()) {
        throw new IllegalStateException(msg + " This message is already in use.");
    }

    synchronized (this) {
        if (mQuitting) {
            IllegalStateException e = new IllegalStateException(
                    msg.target + " sending message to a Handler on a dead thread");
            Log.w(TAG, e.getMessage(), e);
            msg.recycle();
            return false;
        }

        msg.markInUse();
        msg.when = when;
        Message p = mMessages;
        boolean needWake;
        if (p == null || when == 0 || when < p.when) {
            // New head, wake up the event queue if blocked.
            msg.next = p;
            mMessages = msg;
            needWake = mBlocked;
        } else {
            // Inserted within the middle of the queue.  Usually we don't have to wake // up the event queue unless there is a barrier at the head of the queue // and the message is the earliest asynchronous message in the queue. needWake = mBlocked && p.target == null && msg.isAsynchronous(); Message prev; for (;;) { prev = p; p = p.next; if (p == null || when < p.when) { break; } if (needWake && p.isAsynchronous()) { needWake = false; } } msg.next = p; // invariant: p == prev.next prev.next = msg; } // We can assume mPtr != 0 because mQuitting is false. if (needWake) { nativeWake(mPtr); } } return true; } 複製代碼

next()方法源碼分析

在 MessageQueue 中消息的讀取實際上是經過內部的 next() 方法進行的，next() 方法是一個無限循環的方法。博客
若是消息隊列中沒有消息，則該方法會一直阻塞，
當有新消息來的時候 next() 方法會返回這條消息並將其從單鏈表中刪除。

Message next() {
    // Return here if the message loop has already quit and been disposed.
    // This can happen if the application tries to restart a looper after quit
    // which is not supported.
    final long ptr = mPtr;
    if (ptr == 0) {
        return null;
    }

    int pendingIdleHandlerCount = -1; // -1 only during first iteration
    int nextPollTimeoutMillis = 0;
    for (;;) {
        if (nextPollTimeoutMillis != 0) {
            Binder.flushPendingCommands();
        }

        nativePollOnce(ptr, nextPollTimeoutMillis);

        synchronized (this) {
            // Try to retrieve the next message.  Return if found.
            final long now = SystemClock.uptimeMillis();
            Message prevMsg = null;
            Message msg = mMessages;
            if (msg != null && msg.target == null) {
                // Stalled by a barrier.  Find the next asynchronous message in the queue.
                do {
                    prevMsg = msg;
                    msg = msg.next;
                } while (msg != null && !msg.isAsynchronous());
            }
            if (msg != null) {
                if (now < msg.when) {
                    // Next message is not ready.  Set a timeout to wake up when it is ready.
                    nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
                } else {
                    // Got a message.
                    mBlocked = false;
                    if (prevMsg != null) {
                        prevMsg.next = msg.next;
                    } else {
                        mMessages = msg.next;
                    }
                    msg.next = null;
                    if (DEBUG) Log.v(TAG, "Returning message: " + msg);
                    msg.markInUse();
                    return msg;
                }
            } else {
                // No more messages.
                nextPollTimeoutMillis = -1;
            }

            // Process the quit message now that all pending messages have been handled.
            if (mQuitting) {
                dispose();
                return null;
            }

            // If first time idle, then get the number of idlers to run.
            // Idle handles only run if the queue is empty or if the first message
            // in the queue (possibly a barrier) is due to be handled in the future.
            if (pendingIdleHandlerCount < 0
                    && (mMessages == null || now < mMessages.when)) {
                pendingIdleHandlerCount = mIdleHandlers.size();
            }
            if (pendingIdleHandlerCount <= 0) {
                // No idle handlers to run.  Loop and wait some more.
                mBlocked = true;
                continue;
            }

            if (mPendingIdleHandlers == null) {
                mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
            }
            mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
        }

        // Run the idle handlers.
        // We only ever reach this code block during the first iteration.
        for (int i = 0; i < pendingIdleHandlerCount; i++) {
            final IdleHandler idler = mPendingIdleHandlers[i];
            mPendingIdleHandlers[i] = null; // release the reference to the handler

            boolean keep = false;
            try {
                keep = idler.queueIdle();
            } catch (Throwable t) {
                Log.wtf(TAG, "IdleHandler threw exception", t);
            }

            if (!keep) {
                synchronized (this) {
                    mIdleHandlers.remove(idler);
                }
            }
        }

        // Reset the idle handler count to 0 so we do not run them again.
        pendingIdleHandlerCount = 0;

        // While calling an idle handler, a new message could have been delivered
        // so go back and look again for a pending message without waiting.
        nextPollTimeoutMillis = 0;
    }
}
複製代碼

6.0.1.1 子線程更新UI有哪些方式？runOnUiThread如何實現子線程更新UI？View.post(Runnable r)更新UI？

子線程更新UI有哪些方式
- 主線程中定義Handler，子線程經過mHandler發送消息，主線程Handler的handleMessage更新UI
- 用Activity對象的runOnUiThread方法
- 建立Handler，傳入getMainLooper
- View.post(Runnable r)

runOnUiThread如何實現子線程更新UI

如何使用代碼以下所示

new Thread(new Runnable() {
    @Override
    public void run() {
        runOnUiThread(new Runnable() {
            @Override
            public void run() {
                tv_0.setText("滾犢子++++");
            }
        });
    }
}).start();
複製代碼

看看源碼，以下所示
若是msg.callback爲空的話，會直接調用咱們的mCallback.handleMessage(msg)，即handler的handlerMessage方法。因爲Handler對象是在主線程中建立的，因此handler的handlerMessage方法的執行也會在主線程中。
在runOnUiThread程序首先會判斷當前線程是不是UI線程，若是是就直接運行，若是不是則post，這時其實質仍是使用的Handler機制來處理線程與UI通信。博客

public void dispatchMessage(Message msg) {
    if (msg.callback != null) {
        handleCallback(msg);
    } else {
        if (mCallback != null) {
            if (mCallback.handleMessage(msg)) {
                return;
            }
        }
        handleMessage(msg);
    }
}

@Override
public final void runOnUiThread(Runnable action) {
    if (Thread.currentThread() != mUiThread) {
        mHandler.post(action);
    } else {
        action.run();
    }
}
複製代碼

View.post(Runnable r)更新UI

代碼以下所示

tv_0.post(new Runnable() {
    @Override
    public void run() {
        tv_0.setText("滾犢子");
    }
});
複製代碼

源碼原理以下所示

public boolean post(Runnable action) {
    final AttachInfo attachInfo = mAttachInfo;
    if (attachInfo != null) {
        return attachInfo.mHandler.post(action);
    }

    // Postpone the runnable until we know on which thread it needs to run.
    // Assume that the runnable will be successfully placed after attach.
    getRunQueue().post(action);
    return true;
}

private HandlerActionQueue getRunQueue() {
    if (mRunQueue == null) {
        mRunQueue = new HandlerActionQueue();
    }
    return mRunQueue;
}
複製代碼

View.post(Runnable r)使用注意事項
看源碼的註釋可知：若是view已經attached，則調用ViewRootImpl中的ViewRootHandler，放入主線程Lopper等待執行。若是detach，則將其暫存在RunQueue當中，等待其它線程取出執行。
View.post(Runnable r)不少時候在子線程調用，用於進行子線程沒法完成的操做，或者在該方法中經過getMeasuredWidth()獲取view的寬高。須要注意的是，在子線程調用該函數，可能不會被執行，緣由是該view不是attached狀態。博客

子線程更新UI總結歸納
- handler.post(Runnable r)、 view.post(Runnable r)、activity.runOnUIThread(Runnable r)等方法。跟進去看源碼，發現其實它們的實現原理都仍是同樣，最終都是經過Handler發送消息來實現的。

6.0.1.3 使用Hanlder的postDealy()後消息隊列會發生什麼變化？

post delay的Message並非先等待必定時間再放入到MessageQueue中，而是直接進入並阻塞當前線程，而後將其delay的時間和隊頭的進行比較，按照觸發時間進行排序，若是觸發時間更近則放入隊頭，保證隊頭的時間最小、隊尾的時間最大。此時，若是隊頭的Message正是被delay的，則將當前線程堵塞一段時間，直到等待足夠時間再喚醒執行該Message，不然喚醒後直接執行。

6.0.1.4 ThreadLocal有什麼做用？如何避免UI線程儘可能只作跟UI相關的工做?

線程本地存儲的功能
- ThreadLocal類可實現線程本地存儲的功能，把共享數據的可見範圍限制在同一個線程以內，無須同步就能保證線程之間不出現數據爭用的問題，這裏可理解爲ThreadLocal幫助Handler找到本線程的Looper。
- 技術博客大總結
怎麼存儲呢？底層數據結構是啥？
- 每一個線程的Thread對象中都有一個ThreadLocalMap對象，它存儲了一組以ThreadLocal.threadLocalHashCode爲key、以本地線程變量爲value的鍵值對，而ThreadLocal對象就是當前線程的ThreadLocalMap的訪問入口，也就包含了一個獨一無二的threadLocalHashCode值，經過這個值就能夠在線程鍵值值對中找回對應的本地線程變量。
如何避免UI線程儘可能只作跟UI相關的工做?
- 耗時的操做(好比數據庫操做，I/O,鏈接網絡或者別的有可能阻塞UI線程的操做)把它放在單獨的線程處理儘可能用Handler來處理UIthread和別的thread之間的交互.使用Thread或者HandlerThread時，調用Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND)設置優先級，不然仍然會下降程序響應，由於默認Thread的優先級和主線程相同。使用Handler處理工做線程結果，而不是使用Thread.wait()或者Thread.sleep()來阻塞主線程。

6.0.1.5 爲何一個線程只有一個Looper、只有一個MessageQueue，能夠有多個Handler？

注意：一個Thread只能有一個Looper，能夠有多個Handler
- Looper有一個MessageQueue，能夠處理來自多個Handler的Message；MessageQueue有一組待處理的Message，這些Message可來自不一樣的Handler；Message中記錄了負責發送和處理消息的Handler；Handler中有Looper和MessageQueue。
爲何一個線程只有一個Looper？技術博客大總結
- 需使用Looper的prepare方法，Looper.prepare()。能夠看下源代碼，Android中一個線程最多僅僅能有一個Looper，若在已有Looper的線程中調用Looper.prepare()會拋出RuntimeException(「Only one Looper may be created per thread」)。
- 因此一個線程只有一個Looper，不知道這樣解釋是否合理！更多能夠查看個人博客彙總：github.com/yangchong21…
```
public static void prepare() {
    prepare(true);
}

private static void prepare(boolean quitAllowed) {
    if (sThreadLocal.get() != null) {
        throw new RuntimeException("Only one Looper may be created per thread");
    }
    sThreadLocal.set(new Looper(quitAllowed));
}
複製代碼
```