Android異步消息機制

時間 2019-12-09

標籤 android 異步消息機制欄目 Android 简体版

原文原文鏈接

目錄介紹

1.Handler的常見的使用方式
2.如何在子線程中定義Handler
3.主線程如何自動調用Looper.prepare()
4.Looper.prepare()方法源碼分析
5.Looper中用什麼存儲消息
6.Handler發送消息如何運做
7.Looper.loop()方法源碼分析
8.runOnUiThread如何實現子線程更新UI
9.Handler的post方法和view的post方法
10.主線程中Looper的輪詢死循環爲什麼沒阻塞主線程
11.得出部分結論

好消息

01.基礎組件(9篇)
02.IPC機制(0篇)
03.View原理(7篇)
04.動畫機制(2篇)
05.View事件(9篇)
06.消息機制(6篇)
07.多媒體(9篇)
08.View事件(4篇)
09.多線程(4篇)
10.Window(11篇)
11.WebView(4篇)
12.網絡相關(7篇)
13.註解(14篇)
14.音視頻(13篇)
15.優化相關(8篇)
16.設計模式(4篇)
20.零碎筆記(12篇)
21.kotlin學習(1篇)
22.源碼分析(11篇)
23.架構技術(13篇)
25.RecyclerView(21篇)
博客筆記大彙總【16年3月到至今】，包括Java基礎及深刻知識點，Android技術博客，Python學習筆記等等，還包括平時開發中遇到的bug彙總，固然也在工做之餘收集了大量的面試題，長期更新維護而且修正，持續完善……開源的文件是markdown格式的！同時也開源了生活博客，從12年起，積累共計N篇[近100萬字，陸續搬到網上]，轉載請註明出處，謝謝！
連接地址：https://github.com/yangchong2...
若是以爲好，能夠star一下，謝謝！固然也歡迎提出建議，萬事起於忽微，量變引發質變！

1.Handler的常見的使用方式

handler機制你們都比較熟悉呢。在子線程中發送消息，主線程接受到消息而且處理邏輯。以下所示php

通常handler的使用方式都是在主線程中定義Handler，而後在子線程中調用mHandler.sendXx()方法，這裏有一個疑問能夠在子線程中定義Handler嗎？

public class MainActivity extends AppCompatActivity {

    private TextView tv ;

    /**
     * 在主線程中定義Handler，並實現對應的handleMessage方法
     */
    public static Handler mHandler = new Handler() {
        @Override
        public void handleMessage(Message msg) {
            if (msg.what == 101) {
                Log.i("MainActivity", "接收到handler消息...");
            }
        }
    };

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        tv = (TextView) findViewById(R.id.tv);
        tv.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                new Thread() {
                    @Override
                    public void run() {
                        // 在子線程中發送異步消息
                        mHandler.sendEmptyMessage(1);
                    }
                }.start();
            }
        });
    }
}

2.如何在子線程中定義Handler

直接在子線程中建立handler，看看會出現什麼狀況？android
- 運行後能夠得出在子線程中定義Handler對象出錯，難道Handler對象的定義或者是初始化只能在主線程中？其實不是這樣的，錯誤信息中提示的已經很明顯了，在初始化Handler對象以前須要調用Looper.prepare()方法
```
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源碼深度分析git
  - 這樣程序已經不會報錯，那麼這說明初始化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.loop();
            }
        }.start();
    }
});

3.主線程如何自動調用Looper.prepare()

首先直接能夠看在App初始化的時候會執行ActivityThread的main方法中的代碼，以下所示github

能夠看到Looper.prepare()方法在這裏調用，因此在主線程中能夠直接初始化Handler了。

public static void main(String[] args) {
    //省略部分代碼
    Looper.prepareMainLooper();
    ActivityThread thread = new ActivityThread();
    thread.attach(false);
    if (sMainThreadHandler == null) {
        sMainThreadHandler = thread.getHandler();
    }
    if (false) {
        Looper.myLooper().setMessageLogging(new
                LogPrinter(Log.DEBUG, "ActivityThread"));
    }
    Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
    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();

4.Looper.prepare()方法源碼分析

源碼以下所示segmentfault
- 能夠看到Looper中有一個ThreadLocal成員變量，熟悉JDK的同窗應該知道，當使用ThreadLocal維護變量時，ThreadLocal爲每一個使用該變量的線程提供獨立的變量副本，因此每個線程均可以獨立地改變本身的副本，而不會影響其它線程所對應的副本。
```
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));
}
```

思考：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();

5.Looper中用什麼存儲消息

先看一下下面得源代碼markdown

看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();
}

得出結論網絡
- Looper.prepare()方法初始話了一個Looper對象並關聯在一個MessageQueue對象，而且一個線程中只有一個Looper對象，只有一個MessageQueue對象。

6.Handler發送消息如何運做

首先看看構造方法數據結構

能夠看出在Handler的構造方法中，主要初始化了一下變量，並判斷Handler對象的初始化不該再內部類，靜態類，匿名類中，而且保存了當前線程中的Looper對象。

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.sendMessage(msg)方法

關於下面得源碼，是步步追蹤，看enqueueMessage這個方法，原來msg.target就是Handler對象自己；而這裏的queue對象就是咱們的Handler內部維護的Looper對象關聯的MessageQueue對象。

handler.sendMessage(message);

//追蹤到這一步
public final boolean sendMessage(Message msg){
    return sendMessageDelayed(msg, 0);
}


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);
}

看MessageQueue對象的enqueueMessage方法

看到這裏MessageQueue並無使用列表將全部的Message保存起來，而是使用Message.next保存下一個Message，從而按照時間將全部的Message排序

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;
}

7.Looper.loop()方法源碼分析

看看裏面得源碼，以下所示

看到Looper.loop()方法裏起了一個死循環，不斷的判斷MessageQueue中的消息是否爲空，若是爲空則直接return掉，而後執行queue.next()方法

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;
    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
        final Printer logging = me.mLogging;
        if (logging != null) {
            logging.println(">>>>> Dispatching to " + msg.target + " " +
                    msg.callback + ": " + msg.what);
        }
        final long slowDispatchThresholdMs = me.mSlowDispatchThresholdMs;
        final long traceTag = me.mTraceTag;
        if (traceTag != 0 && Trace.isTagEnabled(traceTag)) {
            Trace.traceBegin(traceTag, msg.target.getTraceName(msg));
        }
        final long start = (slowDispatchThresholdMs == 0) ? 0 : SystemClock.uptimeMillis();
        final long end;
        try {
            msg.target.dispatchMessage(msg);
            end = (slowDispatchThresholdMs == 0) ? 0 : SystemClock.uptimeMillis();
        } finally {
            if (traceTag != 0) {
                Trace.traceEnd(traceTag);
            }
        }
        if (slowDispatchThresholdMs > 0) {
            final long time = end - start;
            if (time > slowDispatchThresholdMs) {
                Slog.w(TAG, "Dispatch took " + time + "ms on "
                        + Thread.currentThread().getName() + ", h=" +
                        msg.target + " cb=" + msg.callback + " msg=" + msg.what);
            }
        }
        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();
    }
}

看queue.next()方法源碼

大概的實現邏輯就是Message的出棧操做，裏面可能對線程，併發控制作了一些限制等。獲取到棧頂的Message對象以後開始執行：msg.target.dispatchMessage(msg)

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;
    }
}

那麼msg.target是什麼呢？經過追蹤能夠知道就是定義的Handler對象，而後查看一下Handler類的dispatchMessage方法：

能夠看到，若是咱們設置了callback（Runnable對象）的話，則會直接調用handleCallback方法
在初始化Handler的時候設置了callback（Runnable）對象，則直接調用run方法。

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

private static void handleCallback(Message message) {
    message.callback.run();
}

8.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();
    }
}

9.Handler的post方法和view的post方法

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++;
    }
}

10.主線程中Looper的輪詢死循環爲什麼沒阻塞主線程

形成ANR的緣由
- 形成ANR的緣由通常有兩種：
  - 當前的事件沒有機會獲得處理（即主線程正在處理前一個事件，沒有及時的完成或者looper被某種緣由阻塞住了）
  - 當前的事件正在處理，但沒有及時完成
- 爲了不ANR異常，android使用了Handler消息處理機制。讓耗時操做在子線程運行。
問題描述
- 在處理消息的時候使用了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方法主要就是作消息循環，一旦退出消息循環，那麼你的程序也就能夠退出了。

11.得出部分結論

得出得結論以下所示
- 1.主線程中定義Handler對象，ActivityThread的main方法中會自動建立一個looper，而且與其綁定。若是是子線程中直接建立handler對象，則須要手動建立looper。不過手動建立不太友好，須要手動調用quit方法結束looper。這個後面再說
- 2.一個線程中只存在一個Looper對象，只存在一個MessageQueue對象，能夠存在N個Handler對象，Handler對象內部關聯了本線程中惟一的Looper對象，Looper對象內部關聯着惟一的一個MessageQueue對象。
- 3.MessageQueue消息隊列不是經過列表保存消息（Message）列表的，而是經過Message對象的next屬性關聯下一個Message從而實現列表的功能，同時全部的消息都是按時間排序的。