做Android研发的同学不管是面试还是平时的工作中一定会遇到各种Handler相关的问题，这一篇我们就通过源代码一起探讨一下Android的Handler机制。本文的分析基于Android8.0源码。
1、一个小问题，有代码如下。一个函数延迟2秒执行，另一个函数延迟3秒执行，其中第一个函数执行了3秒，请问第二个函数会在什么时候执行。
Handler handler = new Handler() {
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
switch (msg.what) {
case 1:
methodOne();
break;
case 2:
methodTwo();
break;
default:
break;
}
}
};
handler.sendEmptyMessageDelayed(1, 2000);
handler.sendEmptyMessageDelayed(2, 3000);
private void methodTwo() {
System.out.println("methodTwo");
}
private void methodOne() {
System.out.println("methodOne");
try {
Thread.sleep(3000);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("methodOneFinish");
}
带着这个问题，开始本文分析。
先看构造函数
public Handler() {
this(null, false);
}
public Handler(Looper looper) {
this(looper, null, false);
}
public Handler(Looper looper, Callback callback) {
this(looper, callback, false);
}
public Handler(boolean async) {
this(null, async);
}
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;
}
public Handler(Looper looper, Callback callback, boolean async) {
mLooper = looper;
mQueue = looper.mQueue;
mCallback = callback;
mAsynchronous = async;
}
默认构造函数callback为null，async为false，async如果为true，则处理程序将调用Message＃setAsynchronous，looper就是Looper.myLooper()的返回值，是从ThreadLocal中get到的一个值，也就是如下代码
public static @Nullable Looper myLooper() {
return sThreadLocal.get();
}
跟踪到ThreadLocal的get函数
public T get() {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null) {
ThreadLocalMap.Entry e = map.getEntry(this);
if (e != null) {
@SuppressWarnings("unchecked")
T result = (T)e.value;
return result;
}
}
return setInitialValue();
}
第一行，获取当前线程；第二行，通过当前线程获取ThreadLocalMap实例。我们跟踪进去看一下
ThreadLocalMap getMap(Thread t) {
return t.threadLocals;
}
进入Thread类，发现t.threadLocals指的是ThreadLocal.ThreadLocalMap，初始值为null。
所以会调用setInitialValue函数
private T setInitialValue() {
T value = initialValue();
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null)
map.set(this, value);
else
createMap(t, value);
return value;
}
value返回为null，map初始值也为null，所以会进createMap
void createMap(Thread t, T firstValue) {
t.threadLocals = new ThreadLocalMap(this, firstValue);
}
这里的泛型T是ThreadLocal包裹的泛型对象，在Looper类中，ThreadLocal包裹的泛型对象就是Looper。那这段代码的意思就是实例化了一个ThreadLocalMap，key为ThreadLocal类，value为Looper对象。ThreadLocalMap类在此不做详细说明，就理解为一个类似于键值对存储的数据结构就行。根据上面的代码分析，这里的value为null，所以最后return的也是null。
显而易见，如果myLooper返回值是这样的话Handler就无法工作了。所以我们要提到另外一个重要的函数，Looper.prepare
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.get() 不能有值，因此，每个线程只能调用一次Looper.prepare函数。下面一行是ThreadLocal的set的过程
public void set(T value) {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null)
map.set(this, value);
else
createMap(t, value);
}
这时候value就是new的一个Looper对象了，这样就做到了以ThreadLocal为key，Looper为value的键值对存进了ThreadLocalMap，ThreadLocalMap与当前线程进行了绑定。这样就做到了从当前线程中获取Looper。
所以在使用Handler之前，必须执行Looper.prepare，之所以我们平时在主线程中new Handler不需要执行，是因为在ActivityThread中已经帮我们执行了。参看ActivityThread第6525行。
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();
}
}
到此为止，构造函数中Looper的分析过程已完成，下面我们需要看另一个重要类的分析，也就是 mQueue = mLooper.mQueue这行代码的分析。mQuene是Handler类中的一个成员变量，类名为MessageQueue，根据英文翻译，可以理解为消息队列，但内部的数据结构并不是队列，内部存储的都是Message，从代码层面来讲其实是单链表的结构。mQuene来源于mLooper的成员变量，初始化的过程在
private Looper(boolean quitAllowed) {
mQueue = new MessageQueue(quitAllowed);
mThread = Thread.currentThread();
}
Message类有几个重要的属性，在这里先大概列出来
public int what;
public int arg1;
public int arg2;
public Object obj;
long when;
Bundle data;
Handler target;
Message next;
前面打好了基础，接下来，我们就可以开始看整个Handler的运行机制了。以文章开头的问题为例，我们来看下代码的执行过程。首先是new Handler，这个上文已经分析过了，然后里面有一个handleMessage的覆盖，我们看下这里是怎么回调过来的。
首先来到ActivityThread的第6541行
Looper.loop();
这个loop函数有50多行，我们从头分析。前几行是这样的
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;
通过throw的异常可以看出，在线程中执行loop之前必须先prepare。
然后拿到了MessageQuene实例。
再下面几行，启动了一个无限for循环
for (;;) {
Message msg = queue.next(); // might block
if (msg == null) {
// No message indicates that the message queue is quitting.
return;
}
目的就是不断的从quene中取message，message为null的时候退出循环。那我们需要看下next函数的具体实现。
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) {
可以看到，它也有一个无限for循环。然后有一个nativePollOnce函数的调用，这是一个native的函数，也就是c++的实现。主要功能是等待，直到有下一条消息为止。至于为什么死循环不会导致应用卡死（也就是ANR），这个我们稍后再讨论，先继续往下看。可以看到synchronized关键字修饰了this，可以看到取消息的过程是线程安全的。定义了两个参数prevMsg表示之前那条消息，msg表示下一条消息。
// 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 {
下面一个do while循环，从链表中尾部取出消息。当now小于msg.when，也就是当消息的执行之间大于现在的时间（这个when是开发者设定的消息执行时间点，后面也会解释），下一条message还没准备好，所以需要计算出还需要多久去唤醒这条消息，也就是nextPollTimeoutMillis 这个参数。如果当前时间大于next消息的执行时间，则执行如下代码
// 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;
}
这就是获取消息的过程。首先mBlocked设置为false，阻塞的tag先关闭。如果当前一条消息不为null，则把链表的最后一条消息赋值给到prevMsg的next消息，否则把链表的最后一条消息赋值给mMessages这个成员变量。最后把链表的最后一条消息删除并且把当前取到的msg置为正在使用，把msg给return给调用者。再往后的源码就是IdelHandler的相关使用了，我们后面再具体分析。分析到这，就有几个结论了，我分别列举出来
1、MessageQuene是单链表。
2、每次取出的是链表尾部的消息，当这条消息未到执行时间，会计算出唤醒时间进入nativePollOnce等待唤醒，否则直接取出msg返回并从链表中删除这条msg。
3、当链表中没有msg的时候，nextPollTimeoutMillis为-1，持续nativePollOnce等待唤醒。
分析完了取消息的过程，继续回到之前的loop函数。
try {
msg.target.dispatchMessage(msg);
} finally {
if (traceTag != 0) {
Trace.traceEnd(traceTag);
}
}
msg.target指的是handler对象，也就是说looper从MessageQuene取到消息之后会进入到handler的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);
}
}
我们假定不设置callBack，则最终进入到了handleMessage，这就是new Handler里面handleMessage函数的执行过程。
接下去是sendMessage的过程分析。通过跟踪sendMessage相关的源代码，可以发现不管是sendMessage还是sendEmptyMessage都最终会进入到如下函数
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);
}
其中SystemClock.uptimeMillis() 是表示系统开机到当前的时间总数，单位是毫秒，但是，当系统进入深度睡眠（CPU休眠、屏幕休眠、设备等待外部输入）时间就会停止，但是不会受到时钟缩放、空闲或者其他节能机制的影响。官方解释如下
/**
* Returns milliseconds since boot, not counting time spent in deep sleep.
*
* @return milliseconds of non-sleep uptime since boot.
*/
@CriticalNative
native public static long uptimeMillis();
下面的enqueueMessage函数就是MessageQuene中Message的添加过程。
先截取一些代码看一下
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 {
又看到了synchronized关键字，所以enqueueMessage也是线程安全的。通过精读上方代码，我们可以得出如下结论
1、p==null表示第一次sendMessage，则链表中只有这个消息。
2、when==0表示handler执行了sendMessageAtFrontOfQueue这个函数，官方文档标注的是说把消息放在消息队列的最前方，在单链表中指的是放到链表的尾部。
3、when<p.when指的是执行时间小于链表尾部消息的执行时间，则把这条消息置于链表尾部。
当p!=null&&when>0&&when>p.when的时候的执行流程如下
// 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;
启动一个死循环，直到p==null或者when<p.when的时候退出，目的是为了找到链表中when值大于当前when的消息。然后把p赋值给msg.next，msg赋值给pre.next。很显然，这就是往链表中插入了一个元素。when值越小，越接近链表尾部。分析至此，我们又可以得出结论了。
1、结论前提：p!=null&&when>0&&when>p.when
2、MessageQuene中每次进入新消息，都需要根据msg.when进行排序，msg.when越小，越接近链表尾部。
至此为止，源码层面的Handler机制全部分析完毕。
接下来，我们解答文出现的几个问题：
1、为什么要有looper死循环。
因为Java的Main函数执行完就退出了。对于Android这样的GUI程序，肯定不能执行完就退出，所以引入了死循环，让线程一直执行下去。
1、Looper.loop是一个死循环，为什么不会卡死Android UI，为什么不会导致ANR。
Android 所有的 UI 刷新和生命周期的回调都是由 Handler消息机制完成的，就是说 UI 刷新和生命周期的回调都是依赖 Looper 里面的死循环完成的。其中，在UI的渲染过程中，会调用到如下代码
void scheduleTraversals() {
if (!mTraversalScheduled) {
mTraversalScheduled = true;
mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
mChoreographer.postCallback(
Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
if (!mUnbufferedInputDispatch) {
scheduleConsumeBatchedInput();
}
notifyRendererOfFramePending();
pokeDrawLockIfNeeded();
}
}
其中有这么一行mHandler.getLooper().getQueue().postSyncBarrier();这就是说渲染view的过程也用到了handler机制，并且渲染message的优先级高于普通message。在Android各大组件的生命周期中，利用了ActivityThread类中的H类来处理，也是Handler机制。
2、nativePollOnce是什么。
参考linux epoll
3、文章开头的问题答案是什么。
第二个函数会等待第一个函数执行完了再执行。根据以上分析，dispatchMessage发生在loop for循环中，消息是一条条取出的，msg.when小的排在链表尾部，会优先被取出然后dispatch。handleMessage执行完了之后，才会取下一条消息执行。
下一篇预告：ConcurrentHashMap源码分析
