每日一问：Android 消息机制，我有必要再讲一次！

时间 2019-11-05

原文原文链接

坚持原创日更，短平快的 Android 进阶系列，敬请直接在微信公众号搜索：nanchen，直接关注并设为星标，精彩不容错过。java

我 17 年的面试系列，曾写过一篇名为：Android 面试（五）：探索 Android 的 Handler 的文章，主要讲述的是 Handler 的原理相关面试题，而后简单地给与了一些结论。没想到两年过去，我又开启了面试系列的翻版每日一问专题，而这一次的卷土重来，只是为了经过源码来探知咱们平时可能忽略掉的细节。面试

咱们在平常开发中，老是不可避免的会用到 Handler，虽然说 Handler 机制并不等同于 Android 的消息机制，但 Handler 的消息机制在 Android 开发中早已谙熟于心，很是重要！bash

经过本文，你能够很是容易获得一下问题的答案：微信

Handler、Looper、Message 和 MessageQueue 的原理以及它们之间的关系究竟是怎样的？
MessageQueue 存储结构是什么？
子线程为啥必定要调用 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 取值的不一样状况的阻塞表现：

小于 0，一直阻塞，直到被唤醒；
等于 0，不会阻塞；
大于 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消息机制和应用