每日一問：Android 消息機制，我有必要再講一次！

時間  2019-11-05
標籤 每日 一問 android 消息 機制 必要 再講 一次 欄目 Android 简体版
原文   原文鏈接

堅持原創日更，短平快的 Android 進階系列，敬請直接在微信公衆號搜索：nanchen，直接關注並設爲星標，精彩不容錯過。java

我 17 年的 面試系列，曾寫過一篇名爲：Android 面試（五）：探索 Android 的 Handler 的文章，主要講述的是 Handler 的原理相關面試題，而後簡單地給與了一些結論。沒想到兩年過去，我又開啓了 面試系列 的翻版 每日一問 專題，而這一次的捲土重來，只是爲了經過源碼來探知咱們平時可能忽略掉的細節。面試

咱們在平常開發中，老是不可避免的會用到 Handler，雖然說 Handler 機制並不等同於 Android 的消息機制，但 Handler 的消息機制在 Android 開發中早已諳熟於心，很是重要！bash

經過本文，你能夠很是容易獲得一下問題的答案：微信

  1. Handler、Looper、Message 和 MessageQueue 的原理以及它們之間的關係究竟是怎樣的？
  2. MessageQueue 存儲結構是什麼？
  3. 子線程爲啥必定要調用 Looper.prepare() 和 Looper.loop()?

Handler 的簡單使用

相信應該沒有人不會使用 Handler 吧？假設在 Activity 中處理一個耗時任務，須要更新 UI，簡單看看咱們平時是怎麼處理的。網絡

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_main3)
    // 請求網絡
    subThread.start()
}

override fun onDestroy() {
    subThread.interrupt()
    super.onDestroy()
}

private val handler by lazy(LazyThreadSafetyMode.NONE) { MyHandler() }
private val subThread by lazy(LazyThreadSafetyMode.NONE) { SubThread(handler) }

private class MyHandler : Handler() {
    override fun handleMessage(msg: Message) {
        super.handleMessage(msg)
        // 主線程處理邏輯，通常這裏須要使用弱引用持有 Activity 實例，以避免內存泄漏
    }
}

private class SubThread(val handler: Handler) : Thread() {
    override fun run() {
        super.run()
        // 耗時操做 好比作網絡請求

        // 網絡請求完畢，我們就得嘩嘩譁通知 UI 刷新了，直接直接考慮 Handler 處理，其餘方案暫時不作考慮
        // 第一種方法，通常這個 data 是請求結果解析的內容
        handler.obtainMessage(1,data).sendToTarget()
        // 第二種方法
        val message = Message.obtain() // 儘可能使用 Message.obtain() 初始化
        message.what = 1
        message.obj = data // 通常這個 data 是請求結果解析的內容
        handler.sendMessage(message)
        // 第三種方法
        handler.post(object : Thread() {
            override fun run() {
                super.run()
                // 處理更新操做
            }
        })
    }
}
複製代碼

上述代碼很是簡單，由於網絡請求是一個耗時任務，因此咱們新開了一個線程，並在網絡請求結束解析完畢後經過 Handler 來通知主線程去更新 UI，簡單採用了 3 種方式，細心的小夥伴可能會發現，其實第一種和第二種方法是同樣的。就是利用 Handler 來發送了一個攜帶了內容 Message 對象，值得一提的是：咱們應該儘量地使用 Message.obtain() 而不是 new Message() 進行 Message 的初始化，主要是 Message.obtain() 能夠減小內存的申請。數據結構

受到你們在前面文章提出的建議，咱們就儘可能地少貼一些源碼了，你們能夠直接很容易發現，上述的全部方法最終都會調用這個方法：less

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，而且最終調用了 MessageQueue#enqueueMessage 方法進行消息的入隊，咱們不得不簡單說一下 MessageQueue 的基本狀況。async

MessageQueue

顧名思義，MessageQueue 就是消息隊列，即存放多條消息 Message 的容器，它採用的是單向鏈表數據結構，而非隊列。它的 next() 指向鏈表的下一個 Message 元素。ide

boolean enqueueMessage(Message msg, long when) {
	// ... 省略一些檢查代碼
    synchronized (this) {
        // ... 省略一些檢查代碼
        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;
}
複製代碼

從入隊消息 enqueueMessage() 的實現來看，它的主要操做其實就是單鏈表的插入操做，這裏就不作過多的解釋了，咱們可能應該更多的關心它的出隊操做方法 next()：oop

Message next() {
    // ...
    int nextPollTimeoutMillis = 0;
    for (;;) {
        // ...
        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;
            }
            //...
        }
        //...
        // 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;
    }
}
複製代碼

next() 方法其實很長，不過咱們僅僅貼了極少的一部分，能夠看到，裏面不過是有一個 for (;;) 的無限循環，循環體內部調用了一個 nativePollOnce(long, int) 方法。這是一個 Native 方法，實際做用是經過 Native 層的 MessageQueue 阻塞當前調用棧線程 nextPollTimeoutMillis 毫秒的時間。

下面是 nextPollTimeoutMillis 取值的不一樣狀況的阻塞表現：

  1. 小於 0，一直阻塞，直到被喚醒；
  2. 等於 0，不會阻塞；
  3. 大於 0，最長阻塞 nextPollTimeoutMillis 毫秒，期間如被喚醒會當即返回。

能夠看到，最開始 nextPollTimeoutMillis 的初始化值是 0，因此不會阻塞，會直接去取 Message 對象，若是沒有取到 Message 對象數據，則直接會把 nextPollTimeoutMillis 置爲 -1，此時知足小於 0 的條件，會被一直阻塞，直到其餘地方調用另一個 Native 方法 nativeWake(long) 進行喚醒。若是取到值的話，會直接把獲得的 Message 對象進行返回。

原來，nativeWake(long) 方法在前面的 MessageQueue#enqueueMessage 方法有個調用，調用時機是在 MessageQueue 入隊消息的過程當中。

如今已經知道：Handler 發送了 Message，消息用 MessageQueue 進行存儲，使用 MessageQueue#enqueueMessage 方法進行入隊，使用 MessageQueue#next 方法進行輪訓消息。這就難免拋出了一個問題，MessageQueue#next 方法是誰調用的？沒錯，就是 Looper。

Looper

Looper 在 Android 的消息機制中扮演着消息循環的角色，具體來講就是它會不停地從 MessageQueue 經過 next() 查看是否有新消息，若是有新消息就馬上處理，不然就職由 MessageQueue 阻塞在那裏。

咱們直接看看 Looper 最重要的方法：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.");
    }
    // ...

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

        //...
        try {
        	// 分發消息給 handler 處理
            msg.target.dispatchMessage(msg);
            dispatchEnd = needEndTime ? SystemClock.uptimeMillis() : 0;
        } finally {
            // ...
        }
        // ...
    }
}
複製代碼

方法省去了大量的代碼，只保留了核心邏輯。能夠看到，首先會經過 myLooper() 方法獲得 Looper 對象，若是這個 Looper 返回爲空的話，則直接拋出異常。不然進入到一個 for (;;) 循環中，調用 MessageQueue#next() 方法進行輪訓獲取 Message 對象，若是獲取的 Message 對象爲空，則直接退出 loop() 方法。不然直接經過 msg.target 拿到 Handler 對象，並調用 Handler#dispatchMessage() 方法。

咱們先來看看Handler#dispatchMessage() 方法實現：

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();
}
複製代碼

代碼比較簡單，若是 Message 設置了 callback 則，直接調用 message.callback.run()，不然判斷是否初始化了 `m

再來看看 myLooper() 方法：

public static @Nullable Looper myLooper() {
    return sThreadLocal.get();
}
複製代碼

看看 sThreadLocal 是什麼：

static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();
複製代碼

這個 ThreadLocal 是什麼呢？

ThreadLocal

關於 ThreadLocal，咱們直接採起 嚴振杰文章 中的內容。 看到 ThreadLocal 的第一感受就是該類和線程有關，確實如此，可是要注意它不是線程，不然它就該叫 LocalThread 了。

ThreadLocal 是用來存儲指定線程的數據的，當某些數據的做用域是該指定線程而且該數據須要貫穿該線程的全部執行過程時就可使用 ThreadnLocal 存儲數據，當某線程使用 ThreadnLocal 存儲數據後，只有該線程能夠讀取到存儲的數據，除此線程以外的其餘線程是沒辦法讀取到該數據的。

一些讀者看完上面這段話應該仍是不理解 ThreadLocal 的做用，咱們舉個栗子：

ThreadLocal<Boolean> local = new ThreadLocal<>();
// 設置初始值爲true.
local.set(true);

Boolean bool = local.get();
Logger.i("MainThread讀取的值爲：" + bool);

new Thread() {
    @Override
    public void run() {
        Boolean bool = local.get();
        Logger.i("SubThread讀取的值爲：" + bool);

        // 設置值爲false.
        local.set(false);
    }
}.start():

// 主線程睡1秒，確保上方子線程執行完畢再執行下面的代碼。
Thread.sleep(1000);

Boolean newBool = local.get();
Logger.i("MainThread讀取的新值爲：" + newBool);
複製代碼

代碼沒什麼好說的吧，打印出來的日誌，你會看到是這樣的：

MainThread讀取的值爲：true
SubThread讀取的值爲：null
MainThread讀取的值爲：true
複製代碼

第一條 Log 不容置疑，由於設置了值爲 true，由於打印結果沒什麼好說的。對於第二條 Log，根據上方介紹，某線程使用 ThreadLocal 存儲的數據，只能被該線程讀取，所以第二條 Log 的結果是：null。緊接着在子線程中設置了 ThreadLocal 的值爲 false，而後第三條 Log 將被打印，原理同上，子線程中設置了 ThreadLocal 的值並不影響主線程的數據，因此打印是 true。

實驗結果證明：就算是同一個 ThreadLocal 對象，任一線程對其的 set() 和 get() 方法的操做都是相互獨立互不影響的。

Looper.myLooper()

咱們回到 Looper.myLooper()：

static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();
複製代碼

咱們看看是在哪兒對 sThreadLocal 操做的。

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));
}
複製代碼

因此知道了吧，這就是在子線程中使用 Handler 前，必需要調用 Looper.prepare() 的緣由。

可能你會疑問，我在主線程使用的時候，沒有要求 Looper.prepare() 呀。

原來，咱們在 ActivityThread 中，有去顯示調用 Looper.prepareMainLooper()：

public static void main(String[] args) {
        // ...
        Looper.prepareMainLooper();
        // ...
        if (sMainThreadHandler == null) {
            sMainThreadHandler = thread.getHandler();
        }
        //...
        Looper.loop();
        // ...
    }
複製代碼

咱們看看 Looper.prepareMainLooper()：

public static void prepareMainLooper() {
    prepare(false);
    synchronized (Looper.class) {
        if (sMainLooper != null) {
            throw new IllegalStateException("The main Looper has already been prepared.");
        }
        sMainLooper = myLooper();
    }
}
複製代碼

本文參考了： 《Android 開發藝術探索》 Android消息機制和應用

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程