2. 程式人生 > >Android訊息機制（Handler、MessageQueue、Looper）詳細介紹

Android訊息機制（Handler、MessageQueue、Looper）詳細介紹

阿新 • • 發佈：2019-01-03

Android的訊息機制其實在android的開發過程中指的也就是Handler的執行機制，這也就引出了android中常見的面試問題：

  1. 簡述Handler、Looper、MessageQueue的含義，以及它們之間的關係
  2. 簡述Handler的執行機制
  3. 說明Handler、Looper以及Message之間的關係

Handler機制為什麼這麼重要呢？

我們知道android裝置作為一臺移動裝置，不管是記憶體或者還是它的效能都會受到一定的限制：過多的使用記憶體會使記憶體溢位（OOM）；另外一方面，大量的使用CPU的資 源，一般是指CPU做了大量耗時的操作，會導致手機變得很卡甚至會出現程式無法響應的情況，即出現ANR異常（Application Not Responding）。ANR異常對於我們來說的話其實並不陌生：在UI執行緒中如果5秒之內沒有相應的輸入事件或者是BroadcastReceiver中超過10秒沒有完成返回的話就會觸發ANR異常，這樣就要求我們必須要在寫程式碼的時候格外注意不能將大量耗時的操作放在UI執行緒中去執行，例如網路訪問、資料庫操作、讀取大容量的檔案資源、分析點陣圖資源等…

Handler機制的主要作用

Android系統的這些特性導致開發者在進行開發的時候必須要將比較耗時的操作遠離UI執行緒（ActivityThread），單獨的將這些操作放入到子執行緒中進行執行，在子執行緒完成程式碼執行之後將等到的結果資料返回到UI執行緒（android系統規定在子執行緒中不允許訪問UI），同時UI執行緒根據這些返回的資料更新介面UI，從而實現了人機之間友好的互動。

那麼對於以上的結論，我們會發現如下的問題：

  • 在子執行緒執行完畢的程式碼如何才能將資料返回到UI執行緒呢？
  • 在這個過程中，android系統到底都做了些什麼呢？

接下來我們就開始介紹Handler的具體的執行機制

Handler機制簡介

Handler執行機制是需要MessageQueue、Looper、Handler三者的相互協調工作，但是實際上這三者就是一個整體，只不過我們在開發的過程中只是接觸到了Handler一個而已。Handler的主要作用就是將一個任務切換到指定的執行緒中去執行。而這樣的特性正好可以用來解決在子執行緒中無法訪問UI的矛盾。
那麼接下來我們就來了解下MessageQueue、Looper、Handler的執行機制，以及它們最基本的執行原理。

Handler機制之MessageQueue介紹

MessageQueue通常翻譯為“訊息佇列”，它內部儲存了一組資料，以佇列的形式對外提供插入和刪除操作。雖然被稱之為訊息佇列，但是實際上它的資料結構卻是採用的單鏈表的結構來儲存訊息列表（單鏈表在插入和刪除操作上效率比較高）。
MessageQueue主要包含兩個操作：插入（enqueueMessage）和讀取（next）。

  • 插入：enqueueMessage()方法是往訊息佇列中插入一條資料
  • 讀取：next()方法用於訊息的讀取，讀取操作本身也會伴隨著訊息的刪除操作，即從訊息佇列中取出一條資料並將該資料從訊息佇列中刪除。

對於enqueueMessage和next方法的原始碼請讀者去自行檢視，因為這兩個方法佔得篇幅較大，在這裡就不貼出來了，本處就說明下這兩個方法的主要作用。需要指出的是，next方法是一個無限迴圈的方法，如果訊息佇列中沒有訊息，那麼next方法會一直堵塞，有新訊息的事後，next方法會返回這條訊息並從連結串列中刪除該訊息。

Handler機制之Looper介紹

Looper可以理解為訊息迴圈，因為MessageQueue只是一個儲存訊息佇列，不能去處理訊息，所以需要Looper無限迴圈的去檢視是否有新的訊息，如果有的話就處理訊息，否則就一直等待（阻塞）。 從巨集觀的角度來分析的話，每一個非同步執行緒，都維護著唯一的一個Looper，每一個Looper會初始化（維護）一個MessageQueue，之後進入一個無限迴圈一直在讀取MessageQueue中儲存的訊息，如果沒有訊息那就一直阻塞等待。

Looper中有2個比較重要的方法：

  1. Prepare();
  2. Loop();

Looper.prepare()簡介

Handler的工作需要Looper，沒有Looper的執行緒就會報錯，所以就必須要通過Looper.prepare()方法為當前執行緒建立一個Looper，之後用Looper.loop()方法來開啟訊息迴圈。但是對於我們開發者來說，當我們在UI執行緒中例項化handler的時候並沒有要求對Looper進行初始化，照樣可以是執行沒有任何問題的。其原因就是因為UI執行緒在被建立的時候就會初始化Looper，這樣也就明白了在UI執行緒中可以預設使用handler的原因了。

Looper.prepare()原始碼如下：

 /** Initialize the current thread as a looper.
      * This gives you a chance to create handlers that then reference
      * this looper, before actually starting the loop. Be sure to call
      * {@link #loop()} after calling this method, and end it by calling
      * {@link #quit()}.
      */
    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));
    }

我們發現該方法比較簡單，prepare方法完成了Looper物件的初始化，對於原始碼中所說的sThreadLocal物件來說，它是ThreadLocal的例項化物件，對於ThreadLocal的詳細分析介紹請點選這裡。
通過以上對於原始碼的理解，我們可以知道該方法主要做了如下工作：

  • 檢查是否例項化了ThreadLocal
  • 如果已經例項化ThreadLocal，則將所線上程中Looper物件儲存進去

另外，下面我們通過一個Demo來展示下Handle初始化是需要事先呼叫Looper.perpare()的必要性：

**
 * @author zwjian
 * @des init Looper testActivity
 */
public class InitLooperActivity extends Activity {


    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);


        new Thread("Thread#1") {

            @Override
            public void run() {
                super.run();
                Handler handler = new Handler();

            }
        }.start();

        new Thread("Thread#2") {

            @Override
            public void run() {
                super.run();
                Looper.prepare();
                Handler handler = new Handler();
                Looper.loop();

            }
        }.start();
    }
}

上述程式碼很簡單，我們來看一下執行結果：
這裡寫圖片描述
我們可以發現該執行時異常指的就是在Thread#1中沒有初始化Looper導致handler例項化失敗（後面我們會講到這個異常是怎麼丟擲的）。

Looper.loop()簡介

該方法的主要功能就是不斷從MessageQueue中讀取訊息，交給訊息的target屬性的dispatchMessage去處理。

其原始碼展示如下：

 /**
     * Run the message queue in this thread. Be sure to call
     * {@link #quit()} to end the loop.
     */
    public static void loop() {
        final Looper me = myLooper();
        if (me == null) {
            throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
        }
        final MessageQueue queue = me.mQueue;

        // Make sure the identity of this thread is that of the local process,
        // and keep track of what that identity token actually is.
        Binder.clearCallingIdentity();
        final long ident = Binder.clearCallingIdentity();

        for (;;) {
            Message msg = queue.next(); // might block
            if (msg == null) {
                // No message indicates that the message queue is quitting.
                return;
            }

            // This must be in a local variable, in case a UI event sets the logger
            Printer logging = me.mLogging;
            if (logging != null) {
                logging.println(">>>>> Dispatching to " + msg.target + " " +
                        msg.callback + ": " + msg.what);
            }

            msg.target.dispatchMessage(msg);

            if (logging != null) {
                logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
            }

            // Make sure that during the course of dispatching the
            // identity of the thread wasn't corrupted.
            final long newIdent = Binder.clearCallingIdentity();
            if (ident != newIdent) {
                Log.wtf(TAG, "Thread identity changed from 0x"
                        + Long.toHexString(ident) + " to 0x"
                        + Long.toHexString(newIdent) + " while dispatching to "
                        + msg.target.getClass().getName() + " "
                        + msg.callback + " what=" + msg.what);
            }

            msg.recycleUnchecked();
        }
    }

在該方法中，我們可以看到通過之前儲存在threadLocal物件中的looper物件得到了該執行緒中對應looper物件中維護的MessageQueue訊息佇列，之後進入了一個無限迴圈，對訊息佇列中的資料進行讀取，並且會把訊息通過msg.target.dispatchMessage(msg);進行處理，對於msg.target來說，其實它就是與之繫結的handler例項，在下面我們會進行詳細分析。

以上就是對於Looper的詳細介紹了，對於Looper的總結可以如下：

  • 與當前的執行緒繫結，保證一個執行緒只有一個Looper例項，同時一個Looper例項只有一個MessageQueue
  • loop方法不斷的從MessageQueue中去取訊息，交給訊息的target屬性的dispatchMessage去處理

Handler機制之Handler介紹

handler的工作主要是訊息的傳送和接收過程。訊息的傳送可以通過post和send等一系列的方法來實現。但是需要說明的是，通過post的方法最後還是通過send來實現的。

通常我們在使用handler之前都會進行初始化，比如說比較常見的更新UI執行緒，我們會在宣告的時候直接初始化。那麼問題來了，handler是怎樣和Looper以及MessageQueue聯絡起來的呢？它在子執行緒中傳送的訊息怎麼傳送到了MessageQueue中呢？

下面我們通過檢視Handler的原始碼來進行這些疑點的解釋：

首先我們先來看下Handler的建構函式：

public Handler(Callback callback, boolean async) {
        if (FIND_POTENTIAL_LEAKS) {
            final Class<? extends Handler> klass = getClass();
            if ((klass.isAnonymousClass() || klass.isMemberClass() || klass.isLocalClass()) &&
                    (klass.getModifiers() & Modifier.STATIC) == 0) {
                Log.w(TAG, "The following Handler class should be static or leaks might occur: " +
                    klass.getCanonicalName());
            }
        }

        mLooper = Looper.myLooper();
        if (mLooper == null) {
            throw new RuntimeException(
                "Can't create handler inside thread that has not called Looper.prepare()");
        }
        mQueue = mLooper.mQueue;
        mCallback = callback;
        mAsynchronous = async;
    }

很顯然，我們可以發現在該建構函式中完成了該handler與looper的繫結，以及獲得該looper物件中的訊息佇列等操作。同時在對mLooper進行判空的時候我們就可以發現一句熟悉的異常：”Can’t create handler inside thread that has not called Looper.prepare()”，而這個異常就是在前文中我們在沒有呼叫Looper.prepare()方法而直接例項化handler時所報的異常資訊了。

接下來我們來看一下handler傳送訊息的過程：

一般我們使用handler傳送訊息的函式可以有好幾個，在這裡我們使用如下程式碼進行傳送：

handler.sendMessage(new Message());

接下來我們就去看看它的傳送過程是怎樣的：

    public final boolean sendMessage(Message msg)
    {
        return sendMessageDelayed(msg, 0);
    }
 public final boolean sendMessageDelayed(Message msg, long delayMillis)
    {
        if (delayMillis < 0) {
            delayMillis = 0;
        }
        return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
    }
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);
    }
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
        msg.target = this;
        if (mAsynchronous) {
            msg.setAsynchronous(true);
        }
        return queue.enqueueMessage(msg, uptimeMillis);
    }

最後呼叫的是handler的enqueueMessage方法，在該方法中我們發現了一條熟悉的語句：msg.target=this;這句話就是對msg.target賦值為handler物件本身，正好對應上前文在looper.loop()方法中msg.target.dispatchMessage(msg);

同時我們一路跟下來發現最後呼叫的就是queue.enqueueMessage方法，而這個方法就是我們前面介紹的訊息佇列中進行插入訊息的那個方法。這樣一來，我們就明確了handler傳送的訊息其實最後是進入了訊息佇列中，那插入訊息到訊息佇列之後的操作是什麼呢？我們接著往下看。

通過前面我們所說的Looper中的loop方法，Looper . Loop()方法中通過無限迴圈對訊息佇列進行讀取訊息，得到訊息之後通過訊息的target屬性中的disPatchMessage()方法回撥handlerMessage等方法。而handlerMessage方法就是我們在UI執行緒中例項化handler的過程中重寫的handlerMessage方法。

disPatchMessage()原始碼如下：

/**
     * Handle system messages here.
     */
    public void dispatchMessage(Message msg) {
        if (msg.callback != null) {
            handleCallback(msg);
        } else {
            if (mCallback != null) {
                if (mCallback.handleMessage(msg)) {
                    return;
                }
            }
            handleMessage(msg);
        }
    }

我們發現在這個函式中其實有兩種處理，一個是執行handleCallback(msg);另外一個就是執行handleMessage(msg);對應原始碼如下：

private static void handleCallback(Message message) {
        message.callback.run();
    }
/**
     * Subclasses must implement this to receive messages.
     */
    public void handleMessage(Message msg) {
    }

我們知道在我們例項化handler的時候，如果採用post方法，一般要new 一個Runnable物件，具體如下：

handler = new Handler();
        handler.post(new Runnable() {
            @Override
            public void run() {
               //to do change UI
            }
        });

或者是這樣的形式：

handler = new Handler() {
            @Override
            public void handleMessage(Message msg) {
                switch (msg.what) {
                    case xxx:
                        //to do  change UI
                        break;
                }

            }
        };

而所謂的disPatchMessage所要做的就是對這兩種操作進行回撥，之後執行開發者自行重寫的程式碼，這樣就實現了從一個執行緒中傳送訊息，在另外一個執行緒收到訊息的全過程。

下面我們照樣是通過一個簡單的Demo來說明下：

相應的xml佈局檔案：

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:paddingBottom="@dimen/activity_vertical_margin"
    android:paddingLeft="@dimen/activity_horizontal_margin"
    android:paddingRight="@dimen/activity_horizontal_margin"
    android:paddingTop="@dimen/activity_vertical_margin"
    tools:context="com.example.zwjian.myapplication.HandlerAct">

    <TextView
        android:id="@+id/test_tv"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_below="@+id/toolbar"
        android:layout_margin="20dp"
        android:text="你是一個壞人" />
</RelativeLayout>

對應的Activity

/**
 * @author zwjian
 * @des show handler + message changes UI
 */
public class HandlerAct extends AppCompatActivity {
    private static final int HANDLER_TEST_VALUE = 0X10;
    private Handler handler;
    private TextView test_tv;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_handler);

        test_tv = (TextView) findViewById(R.id.test_tv);
        //first method
        handler = new Handler() {
            @Override
            public void handleMessage(Message msg) {
                switch (msg.what) {
                    case HANDLER_TEST_VALUE:
                        test_tv.setText("我是第一個方法：誰說的？你才是一個壞人！");
                        break;
                }

            }
        };
        //another method
        handler = new Handler();
        handler.post(new Runnable() {
            @Override
            public void run() {
                test_tv.setText("我是第二個方法：誰說的？你才是一個壞人！");
            }
        });

        new Thread("Thread#2") {

            @Override
            public void run() {
                super.run();
//                handler.sendEmptyMessage(HANDLER_TEST_VALUE);
                handler.sendMessage(new Message());
            }
        }.start();
    }

}

以上，我們通過在thread#2中傳送了一條訊息，在UI執行緒中進行接收，當然這裡寫了2種接收方式，讀者可以自行去註釋掉某一種去進行演示，最後可以通過這個demo發現這兩種方式都是可以被回撥執行的，通過執行我們可以看到textView的顯示發生了相對應的變化，這樣，我們就完成了handler訊息的傳遞的全過程。

最後，我們來總結下handler機制的全過程：

  1. 首先Looper.prepare()會在當前執行緒儲存一個looper物件，並且會維護一個訊息佇列messageQueue，而且規定了messageQueue在每個執行緒中只會存在唯一的一個
  2. Looper.loop()方法會使執行緒進入一個無限迴圈，不斷地從訊息佇列中獲取訊息，之後回撥msg.target.disPatchMessage方法。
  3. 我們在例項化handler的過程中，會先得到當前所線上程的looper物件，之後得到與該looper物件相對應的訊息佇列。（程式碼見handler的構造方法）
  4. 當我們傳送訊息的時候，即handler.sendMessage或者handler.post，會將msg中的target賦值為handler自身，之後加入到訊息佇列中。
  5. 在第三步實現例項化handler的過程中，我們一般會重寫handlerMessage方法（使用post方法需要實現run方法），而這些方法將會在第二步中的msg.target.disPatchMessage方法中被回撥，從而實現了message從一個執行緒到另外一個執行緒的傳遞。

以上就是handler機制的所有分析，由於個人理解有限，有錯誤之處還請諸位讀者能批評指正。

相關推薦

Android訊息機制（Handler、MessageQueue和Looper三者的工作原理）

Android的訊息機制主要是指Handler的執行機制以及Handler所附帶的MessageQueue和Looper的工作過程。messagequeue意思是訊息佇列，它內部儲存一組訊息，有插入和刪除的功能，其實內部是以單鏈表的形式來實現佇列功能的。looper的意思是迴圈，它的主要功能是迴

Android訊息機制（Handler、MessageQueue、Looper）詳細介紹

Android的訊息機制其實在android的開發過程中指的也就是Handler的執行機制，這也就引出了android中常見的面試問題： 簡述Handler、Looper、MessageQueue的含義，以及它們之間的關係 簡述Handler的執行機制 說明

Android的訊息機制（Handler、Looper、MessageQueue）

注：本文原始碼基於Android7.0先大概概括一下訊息機制：這裡有三個角色，Handler、looper、MessageQueue。Handler負責發訊息和處理訊息，Looper負責從MessageQueue中取出訊息給Handler處理，MessageQueue則負責儲

Android 訊息機制：Handler、MessageQueue 和 Looper

在這篇文章中，我們將會討論 Android 的訊息機制。提到 Handler，有過一些 Android 開發經驗的都應該很清楚它的作用，通常我們使用它來通知主執行緒更新 UI。但是 Handler 需要底層的 MessageQueue 和 Looper 來支援才能運作。這篇文章中，我們將會討論它們三個之間的關

深入理解android訊息機制（一）——handler Looper原始碼

android 重要核心知識點，怎麼深刻理解都不為過,本篇部落格從常用api ，Looper Hanldery以及HanlderTread原始碼角度解讀 一 常用api，主執行緒接收處理訊息 private Handler handler = ne

Android訊息機制（一）之 ThreadLocal

前言 　　今天重溫了Android開發藝術探索上的訊息機制，花了一些時間，書上寫很好，但是可能文章一些先後順序問題，不是特別好理解，這篇文章博主用了自己的理解，看原始碼，結合書上的知識，希望大家能更容易理解。（可能會寫的不太好。。。不正確的地方歡迎指出） 　

Android訊息處理機制、Hanlder機制（Handler、Looper、MessageQueue和Message）

·前言長久以來，我使用Hanlder僅限於它的基本使用：post 和 sendMessage而對於Hanlder的原理和訊息處理機制並不清楚。找了兩篇比較深入的部落格：學習了一下，又對照了原始碼，小有收穫，俗話說“好記性不如爛筆頭”，所以做一下筆記，總結一下，方便以後回顧。·

Android訊息機制分析：Handler、Looper、MessageQueue原始碼分析

1.前言 關於Handler訊息機制的部落格實際上是非常多的了。 之前也是看別人的部落格過來的，但是過了一段時間之後，一些細節也就忘了。 所以，就自己擼一篇，權當筆記，方便以後翻閱。 這篇文章主要是分析Handler訊息機制原理以及收集一些面試題來講解，

Android訊息機制之Looper、Handler、MessageQueen

Android訊息機制之Looper、Handler、MessageQueen 本篇文章包括以下內容： 前言 Android訊息機制的簡介 Android訊息機制的使用 Android訊息機制的相關概念 Android訊息機制的通訊流程

android 消息系統Handler、MessageQueue、Looper源代碼學習

red css llb patch ... handle eas 除了 pro android消息系統 總體框架如圖所看到的 在安卓的消息系統中，每一個線程有

Android Handler 訊息機制（解惑篇）

Android中的訊息處理機制概述 大家對於Android中的訊息處理機制的用法一定都比較熟悉，至於工作原理估計不少人有研究。就像我們自己寫的類我們用起來比較熟悉一樣，如果我們熟悉了訊息處理機制的具體實現，那麼我們用起來肯定也會事半功倍。 博主之前只是稍有涉

Android 安全機制（1）uid 、 gid 與 pid

1、概述        Android 安全機制來源於Linux，並且以Linux許可權管理為基礎，要了解Android的安全機制，需要從linux中的安全機制瞭解開始，而使用者的許可權管理又是linux安全機制的最基本的一個組成. Android的創新之處是在linux使

Android訊息機制-Handler（一）

Android為了執行緒安全，不允許我們在UI執行緒外（即主執行緒外的子執行緒）操作UI。 1. 子執行緒為啥不能操作UI呢？ 試想一下，如果多個執行緒都可以操作UI，不同執行緒都可以控制同一個UI，那麼勢必會出現執行緒安全問題。執行緒A在修改UI的同事，執行緒B也在改同一

從Handler.post(Runnable r)再一次梳理Android的訊息機制（以及handler的記憶體洩露）

Handler 每個初學Android開發的都繞不開Handler這個“坎”，為什麼說是個坎呢，首先這是Android架構的精髓之一，其次大部分人都是知其然卻不知其所以然。今天看到Handler.post這個方法之後決定再去翻翻原始碼梳理一下Handler

Android訊息機制Handler解析（原始碼+Demo）

新建了一個qq群 482543750，歡迎一起學習Android的小夥伴加入。 提供各種Android學習資料，面試資料，Android簡歷模板。 Handler是開發人員在面試過程中最常見的問題之一了，這篇文章將較為全面地對Handler進行解讀，包括原始碼層，

《Android開發藝術探索》讀書筆記——Handler訊息機制（ThreadLocal）

ThreadLocal ThreadLocal是一個執行緒內部的資料儲存類。它可以為各執行緒儲存資料，同時只能由當前執行緒獲取到儲存的資料，對於其他執行緒來說則獲取不到。它可以在不同執行緒中維護一套資料的副本，並且彼此互不干擾。 一言不合上程式碼： privat

SpringCloud系列七：Hystrix 熔斷機制（Hystrix基本配置、服務降級、HystrixDashboard服務監控、Turbine聚合監控）

bsp 但是 mem style 查詢 packages discover seconds ID 1、概念：Hystrix 熔斷機制 2、具體內容 所謂的熔斷機制和日常生活中見到電路保險絲是非常相似的，當出現了問題之後，保險絲會自動燒斷，以保護我們的電器， 那麽如果換到了程

Android訊息機制Handler原理分析

文章目錄 1、App中Handler的使用 2、Java層Handler的原理 2.1 Handler模型 2.2 圖解Handler 2.3 Handler執行緒的典型例項 2.4 Looper 2.5 Handl

Android常用佈局（FrameLayout(框架佈局)、LinearLayout（線性佈局）、RelativeLayout（相對佈局））詳解

很多開發者一聽說Android終端的螢幕尺寸五花八門，螢幕解析度千奇百怪，就覺得Android開發在螢幕適配方面是必定是一件頭疼的事情。因為在Android問世之前，廣大開發者知道的UI解決方案大致分為兩類： 1、在Web開發中的CSS，一層一層的去層疊樣式。

Android訊息機制原理，仿寫Handler Looper原始碼解析跨執行緒通訊原理--之仿寫模擬Handler(四)

前篇總結：上一篇實現了用Looper管理訊息佇列和訊息迴圈，但是訊息的傳送和訊息處理都是在Looper中進行的。寫一個子執行緒使用這樣的Looper怎麼才能獲取到loop()死迴圈訊息佇列取出的訊息呢？用回撥！callBack！ 第四節 仿寫Handler來發送訊息,實現回