再读Handler机制

一、引言

距离上一次阅读Handler源码已经半年多过去了，当时读源码的目的更多的是忙于毕业找工作，为面试做准备，现在则是想更多地了解Android相关机制。半年多过去了，回头看当时的源码解读笔记（当时不写博客），发现有很多地方并没有很好地解释清楚，于是想趁着这2018结束之际再次根据自己的想法整理一遍，感兴趣的童鞋可以看看。

所谓Handler机制，实际是线程切换机制。在我们日常开发中用的最多的是通过Handler来更新UI视图，而Handler除了用于线程切换外，Handler、Looper、ThreadLocal、MessageQueue、Message如何融合、构成一个成熟框架的思想更值得我们学习，这也是写本文的目的：比较深入全面地理解Handler机制。

二、预热知识

通常，我们使用Handler是这样的：

private Handler mHandler1;

 mHandler1 = new Handler(new Handler.Callback() {
        @Override
        public boolean handleMessage(Message msg) {
            // 操作 UI
            textView.setText(String.valueOf(msg.obj));
            return false;
        }
    });

又如这样手动建立一个消息循环：

Handler mHandler;
Looper mLooper;
private void createHandlerLoop() {
   Thread looperThread =  new Thread(new Runnable() {
        @Override
        public void run() {
            Looper.prepare();
            mLooper = Looper.myLooper();
            mHandler = new Handler(new Handler.Callback() {
                @Override
                public boolean handleMessage(Message msg) {
                    // 操作UI时异常
                    // Looper不执行于UI线程，不能直接操作View控件
                    // textView.setText(String.valueOf(msg.obj));
                    Toast.makeText(MainActivity.this, String.valueOf(msg.obj), Toast.LENGTH_SHORT).show();
                    return true;
                }
            });
            Looper.loop();
        }
    });
    looperThread.start();
}

然后我们给两个Handler发送消息，这里我们从非主线程发送消息：

private ExecutorService mExecutorService = Executors.newCachedThreadPool();
public void sendMessage(View view) {
    mExecutorService.submit(new Runnable() {
        @Override
        public void run() {
            if (mHandler != null) 
                mHandler.obtainMessage(1, "" + Math.random()).sendToTarget(); 
            if (mHandler1 != null) 
                mHandler1.obtainMessage(1, "`from mHandler1::" + Math.random()).sendToTarget();
        }
    }); 
}

我们知道Handler运行于Looper，而Looper运行于创建它的线程中，因此可以说Handler运行于创建它的线程，这里刚好验证一下，我们给mHandler1和mHandler发消息，然后在其中更新UI，此时mHandler1正常更新，而mHandler则报非主线程更新UI的异常，可见 mHandler1的Looper运行于主线程，而mHander则运行于looperThread。

当然，这些只是表象上，我们来看看为啥它运行在创建它的线程。

首先来看看Handler的构造方法

public Handler(Callback callback, boolean async) {
    // ...
    mLooper = Looper.myLooper();
    // ...
}

这里主要关注到Looper.myLooper()，它是从ThreadLocal中获取到的，而之所以能得到，是因为在执行Looper.prepare()方法时会创建一个Looper实例存入其中，这也就是为什么我们在手动建立消息循环时必须要执行Looper.prepare()的原因了。

// 
static final ThreadLocal sThreadLocal = new ThreadLocal();

public static @Nullable Looper myLooper() {
    return sThreadLocal.get();
}

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

注意到上面sThreadLocal被static final所修饰，也就是说它以常量的形式存在于进程中，所以我们应用进程中的所有Looper实例都会独立存储在其中，无论运行在主线程还是其他线程。ThreadLocal#get()源码如下：

public T get() {
    // 1.  拿到当前线程
    Thread t = Thread.currentThread();
    // 2.  取出当前线程的独立数据
    ThreadLocalMap map = getMap(t);
    if (map != null) {
        ThreadLocalMap.Entry e = map.getEntry(this);
        if (e != null) {
            @SuppressWarnings("unchecked")
            // 3. 取出运行在当前线程的 Looper 实例
            T result = (T)e.value;
            return result;
        }
    }
    return setInitialValue();
}

可以看出，从ThreadLocal取出Looper实例时会根据当前运行的线程去取，也就是说在Handler执行于的线程决定于Looper所执行于的线程，也就是创建它的，并执行了Looper#prepare()的线程。

好了，接下来将结合源码分析Handler、Looper、ThreadLocal、MessageQueue、Message的具体运作原理。

三、 Looper 源码分析

在Looper对象创建时会创建一个消息队列，并记录当前线程信息

private Looper(boolean quitAllowed) {
    mQueue = new MessageQueue(quitAllowed);
    mThread = Thread.currentThread();
}

而实际上调用Looper.prepare()时才会真正意义上的创建Looper对象，Looper对象会记录在ThreadLocal中，而ThreadLocal在这里是个static final常量，意味着会在运行时以常量形式记录在常量池，从而保证使用到Looper的线程都只对应这唯一的ThreadLocal常量，也就保证不同使用到Looper消息循环的线程中都对应着唯一的Looper，且相互之间是独立的。

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

loop()方法则是个死循环，所以执行之后，会使得创建它的线程就处于阻塞状态，此时会一直处于从MessageQueue中提取Message的状态，直到调用Looper.quit()方法退出消息队列。Looper.quit()执行后使得queue.next()返回Message为null,Looper也随即退出，线程最终执行结束。

在消息循环正常执行过程中，会将每个从消息队列中提取到的消息分发给handler#dispatchMessage(msg)处理，这里的msg.target就是Message记录下来的发送它的那个Handler。

public static void loop() {
    final Looper me = myLooper();
    final MessageQueue queue = me.mQueue; 
    // . . .
    for (;;) {
        Message msg = queue.next(); // might block
        if (msg == null) {  // 拿到的消息为null了，说明消息队列已经退出了，因而退出消息循环
            return;
        }

        try { // 分发消息给handler处理
            msg.target.dispatchMessage(msg); 
        } finally { 
            // ...
        } 
    }
}

执行mQueue.quit(false)后消息队列会删除队列内的所有消息，并把根节点Message设置为null（MessageQueue是个单向链表结构，后面会讲到）,所以上面如果queue.next()拿到的消息为null了，就说明消息队列已经退出，因而就会退出Looper#loop()，也就是退出消息循环。

public void quit() {
    mQueue.quit(false);
}
void quit(boolean safe) {
    // ...
    synchronized (this) {
        // ... 
        if (safe) {
            removeAllFutureMessagesLocked();
        } else {
            removeAllMessagesLocked();
        } 
        // We can assume mPtr != 0 because mQuitting was previously false.
        nativeWake(mPtr);
    }
}
private void removeAllMessagesLocked() {
    Message p = mMessages;
    while (p != null) {
        Message n = p.next;
        p.recycleUnchecked();
        p = n;
    }
    mMessages = null;
}

至于Handler.dispatchMessage()，源码如下，可见它首先会看看是否给Message设置了回调，如果有，那执行Message的回调方法，如果没有，则看看自己的回调，如果没有再就执行自己的方法；所以Message自身的回调是优先级最高的，其次是自身回调，最后才是自身的方法。

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

以上整个分析流程下来就可以得出如下草图，其中包含了线程切换的概念在内：

Handler机制.png

以上便是Handler机制的核心内容，也可以说是Looper的运行流程，当然这还没完，因为我们在分析过程中依然存在其他疑问，比如以单向链表结构为基础的Messagequque为啥这么设计、ThreadLocal为啥能够独立存储线程数据等。

三、MessageQueue 源码分析

消息队列顾名思义是用来存放Message的队列，但实际上它不是使用队列，而是以Message为节点的单链表结构；它提供enqueueMessage(Message msg, long when)方法用来插入消息，next()来提取消息，它是一个阻塞方法，只有当Looper.quit调用后它才会退出。

这里重点分析一下它的next()方法，它采用了线程安全设计，并且它也是阻塞式的，我们先来看看源码：

Message next() {
    final long ptr = mPtr; // 留意 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) {
            final long now = SystemClock.uptimeMillis();
            Message prevMsg = null;
            Message msg = mMessages;
            if (msg != null && msg.target == null) {
                // 1. 遍历单向链表，也就是消息队列，查找尾部节点
                do {
                    prevMsg = msg;
                    msg = msg.next;
                } while (msg != null && !msg.isAsynchronous());
            }

            if (msg != null) {
                // 2. 根据消息的执行时间判定是否要返回、处理这条消息
                if (now < msg.when) {
                    // 还没轮到它
                    nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
                } else { // 时间到，就是它了
                    mBlocked = false;
                    if (prevMsg != null) {  // 删除队尾节点
                        prevMsg.next = msg.next;
                    } else {
                        mMessages = msg.next;
                    }
                    // 3. 这条消息可以处理了，则标记为正在使用并返回
                    msg.next = null;
                    msg.markInUse();
                    return msg;
                }
            } else {
                // No more messages.
                nextPollTimeoutMillis = -1;
            }

            // 检查消息循环是否退出
            if (mQuitting) {
                dispose();
                return null;
            }
            // 其他情况，则继续循环等待
        }
        // ...
    }
}

由于是基于单向链表的设计，因而每次如果想要得到队尾节点都需要遍历整个队列，直到定位到队尾。一旦定位到了队尾，且它不为null，那么就会根据消息的执行时间判定是否要返回、处理这条消息，如果还没到点，那么继续循环（也可看成是在等待，如果是异步isAsynchronous的,那么就直接使用这个消息，而不需要定位到队尾），直到达到了执行时间，而达到执行时间后，说明这条消息可以处理了，则标记为已用，并返回给Looper进行分发。

MessageQueue#next.png

update 2021-01-17： 上面关于阻塞等待的问题只是一笔带过，感觉解释的太浅显，漏掉了关键的nativePollOnce，当时没理解透吧，现在来补充一下。

为什么这里next是死循环，却不会导致ANR呢？或者说导致导致CPU满载呢？ 相信很多小伙伴面试的时候，面试官都喜欢问这个问题，当然我也一样被问过，大概在两年前吧。当时我的回答就比较模糊了，我说是因为当消息队列为空的时候，或者消息还没有到执行时间时，也就是我们postDelayed的消息的执行时间，Looper会处于等待状态，此时不会太消耗CPU，直到有消息执行可以执行；当然这回答感觉也没啥太大毛病，但是不够细节，我之所了最终呈现的现象或结果，但是并没有给出很好的解释或依据，能表明它确实是不会耗尽CPU资源或者卡死；

OK，下面我们就来补充补充细节，我们知道 nativePollOnce 是个 native 方法 , 直接上C++源码:

static void android_os_MessageQueue_nativePollOnce(JNIEnv* env, jobject obj,
        jlong ptr, jint timeoutMillis) {
    NativeMessageQueue* nativeMessageQueue = reinterpret_cast(ptr);
    nativeMessageQueue->pollOnce(env, obj, timeoutMillis);
}

注意到ptr, 我们执行nativePollOnce(ptr, nextPollTimeoutMillis);的时候会传入一个mPtr，这个实际是NativeMessageQueue的一个指针，它是nativeInit()的返回值，创建过程如下：

    MessageQueue(boolean quitAllowed) { 
        mPtr = nativeInit(); // 
    }

static jlong android_os_MessageQueue_nativeInit(JNIEnv* env, jclass clazz) {
    NativeMessageQueue* nativeMessageQueue = new NativeMessageQueue();
    // ...
    nativeMessageQueue->incStrong(env);
    return reinterpret_cast(nativeMessageQueue);
}

所以理解android_os_MessageQueue_nativePollOnce就很简单了，就是通过mPtr指针重新找到对应的NativeMessageQueue对象，然后执行pollOnce方法，然后回到native的Looper；

void NativeMessageQueue::pollOnce(JNIEnv* env, jobject pollObj, int timeoutMillis) {
    // ...
    mLooper->pollOnce(timeoutMillis); 
}

重点看下 Looper::pollOnce，代码只保留我们所关心的：

int Looper::pollOnce(int timeoutMillis, int* outFd, int* outEvents, void** outData) {
    int result = 0;
    for (;;) {
        // ...
        if (result != 0) { 
            if (outFd != nullptr) *outFd = 0;
            if (outEvents != nullptr) *outEvents = 0;
            if (outData != nullptr) *outData = nullptr; 
            return result; // 返回状态，代表本次poll结束 
        } 
        // 产生结果状态
        result = pollInner(timeoutMillis);
    }
}

// 上面的 result 有以下几种状态，都由 Looper#pollOnce() 或者 Looper#pollAll() 产生
enum {
    // 说明本次 poll 已经在超时之前被 wake() 唤醒，没有回调被执行且没有其他就绪的 fd 
    POLL_WAKE = -1,
    // 一个或多个回调被执行
    POLL_CALLBACK = -2,
    // 超时了
    POLL_TIMEOUT = -3,
    // 出错了
    POLL_ERROR = -4,
};

通过上面的注释我们知道结果状态由 pollInner 产生，如下，看看注释即可：

Vector mMessageEnvelopes; // guarded by mLock
int Looper::pollInner(int timeoutMillis) { 
    // ...  
    int result = POLL_WAKE; 
    // ...  
    struct epoll_event eventItems[EPOLL_MAX_EVENTS];
    // (1). 重点在 epoll_wait 这里，这里等待 Kernel IO 事件 
    int eventCount = epoll_wait(mEpollFd.get(), eventItems, EPOLL_MAX_EVENTS, timeoutMillis);
    // ...  
    mLock.lock();
 
    for (int i = 0; i < eventCount; i++) {
        // 如果有epoll消息回调，这里会处理一波
        // ...
    }
    // ... 

    // 这里执行待处理的消息回调，也就是 handleMessage 
    mNextMessageUptime = LLONG_MAX;
    while (mMessageEnvelopes.size() != 0) {
        nsecs_t now = systemTime(SYSTEM_TIME_MONOTONIC);
        const MessageEnvelope& messageEnvelope = mMessageEnvelopes.itemAt(0);
        if (messageEnvelope.uptime <= now) { 
            // postDelay/postAtTime 设置消息时间到了，执行回调
            { // obtain handler
                sp handler = messageEnvelope.handler;
                Message message = messageEnvelope.message;
                mMessageEnvelopes.removeAt(0);
                mSendingMessage = true;
                mLock.unlock(); 
                handler->handleMessage(message); //（2）.接收到 epoll 事件消息可执行时执行handleMessage
            } // release handler

            mLock.lock();
            mSendingMessage = false;
            result = POLL_CALLBACK;
        } else {
            mNextMessageUptime = messageEnvelope.uptime;
            break;
        }
    }

    mLock.unlock();
    // ...
    return result;
}

OK，通过源码可以看出实际上不管是没消息时执行nativePollOnce，还是postDelay/postAtTime执行定时任务，都会在epoll_wait这里等待epoll事件，然后更新任务状态，执行定时任务的handlerMessage回调；也就是说，之所以不会ANR，其实是因为epoll_wait它本身不会太占CPU（PS：说不占CPU的话感觉不严谨），为啥嘞，我们下面继续聊聊；

关于 Epoll

epoll_wait源自Epoll，而Epoll是Linux中的一套多路复用I/O接口，能提高程序在并发场景下的CPU利用率，它基于事件驱动，因此等待I/O事件的过程中CPU占用会很低；暂且我们知道这个就可以了，如果有小伙伴想对进行深入研究或其源码感兴趣也可以多找点其他资料或pull一份源码康康，这里就不展开了；

这个可能很多人之前压根没听过，包括我自己（捂脸）；我们熟悉wait，因为Object也有wait方法，我们知道当我们执行Object#wait()方法时，当前线程会让出CPU资源，感觉有点像啊对吧，不过两者底层实现方式可是相差甚远，Object#wait() 底层是通过自旋锁来实现的，源码可以查找 ObjectMonitor::wait(jlong millis, bool interruptible, TRAPS) ，直戳这里一键直达

四、ThreadLocal 源码分析

特点： 当多个线程使用同一个ThreadLocal时，它可以独立地记录各个线程的数据。

ThreadLocal#set(...)源码如下，可见每当执行ThreadLocal#set(...)保存线程数据时，会先查看当前线程是否已经绑定了ThreadLocalMap数据集合，如果不存在则创建一个绑定在这个线程。

public void set(T value) {
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t);
    if (map != null)
        map.set(this, value);
    else
        createMap(t, value);
}

ThreadLocalMap getMap(Thread t) {
    return t.threadLocals;
}

void createMap(Thread t, T firstValue) {
    t.threadLocals = new ThreadLocalMap(this, firstValue);
}

再来看看ThreadLocalMap的主要构成，看到这样的构成是不是可以联想到HashTable和HashMap呢？当然，不过不同之处在于，它并没有像HashTable那样采用数组+单向链表的设计，也没有像HashMap那样采用数组+单向链表+红黑树的设计，而仅仅是一个数组，不过原理都是类似的。

也就是说，实际上ThreadLocal本身并不存储数据，而ThreadLocal之所以能够实现单独记录每个使用到它的线程的数据，是因为它为每一个线程都建立了一个独立的ThreadLocalMap数据存储对象，并把这个数据存储对象绑定在对应的线程上，当我们需要设置或者获取某一个线程的数据时，那么只需要从这个线程中取出这个数据存储对象，然后写/读数据即可，你看这是不是既简便又能保证数据的独立性。

static class ThreadLocalMap { 
    // 真正线程存储数据的地方
    static class Entry extends WeakReference> {
        /** The value associated with this ThreadLocal. */
        Object value; 
        Entry(ThreadLocal k, Object v) {
            super(k);
            value = v;
        }
    } 
    private Entry[] table;  
    private int size = 0; 
    private int threshold; // Default to 0
    // ...
}

ThreadLocal#get()源码如下:

public T get() {
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t); //1. 取出当前线程所绑定的的ThreadLocalMap
    if (map != null) {
        ThreadLocalMap.Entry e = map.getEntry(this); //2. 取出 ThreadLocalMap.Entry
        if (e != null) {
            @SuppressWarnings("unchecked")
            T result = (T)e.value;   //3. 取出值
            return result;
        }
    }
    return setInitialValue();
}

五、设计思想

至此，我们已经结合源码分析了Handler机制中所有核心类，可能有的童鞋会有所怀疑，Handler机制的核心居然不是Handler？确实不是，Handler只是作为整个框架的入口和最终功能逻辑代码执行地，要说这套框架核心，那非Looper莫属啦。

纵观整个机制的执行过程及协作关系，不难发现它实际是基于生产者-消费者模型的设计：

生产者-消费者.png

为了方便对比，我把前面的Handler机制那张图粘过来这里：