Handler做为Android中最常用的线程间通信工具，使用Handler我们可以方便得将某一段代码指定在Handler所绑定的线程运行或者通过Handler向其他线程发送消息通知。
Handler绑定线程说明
对于一个Handler对象而言，其所绑定的线程和构造函数相关：
- 如果使用默认的无参构造函数
public Handler()创建，其所绑定的线程为创建Handler对象所在的线程，比如说我们在主线程调用Handler handler = new Handler()创建的handler对象，通过其发送的消息均在主线程运行； - 如果使用
public Handler(@NonNull Looper looper)创建，则该Handler对象的绑定线程为looper对象对应的线程；
针对一个普通线程而言（除主线程外），默认没有开启消息循环，在向该线程发送消息前，需要使用Looper.prepare()创建消息循环，随后通过Looper.loop()即可开启消息循环，这样该线程的消息循环就开始正常运行了。当需要创建Handler时，我们通过Looper.myLooper()即可获取当前线程的Looper对象，使用public Handler(@NonNull Looper looper)构造handler对象即可。
线程，Looper，Handler之间的关系
结合上文，我们不难得出Thread，Looper，Handler之间的数量关系，那么Handler发生的消息又是怎么组织管理的呢？
这就要说到另一个东西了----MessageQueue，MessageQueue是管理所有Handler发出消息的一个队列，Looper通过循环来处理MessageQueue中的消息，加入MessageQueue的关系图如下所示：
Handler延时消息实现原理
延时消息入队
通常情况下，我们主要使用postDelayed和sendEmptyMessageDelayed两种形式来发送延时消息，接下来我们分别看下这两种形式的延时消息实现。
postDelayed
public final boolean postDelayed(@NonNull Runnable r, long delayMillis) {
return sendMessageDelayed(getPostMessage(r), delayMillis);
}
public final boolean postDelayed(
@NonNull Runnable r, @Nullable Object token, long delayMillis) {
return sendMessageDelayed(getPostMessage(r, token), delayMillis);
}
可以看到postDelayed最终调用的都是sendMessageDelayed。
sendEmptyMessageDelayed
public final boolean sendEmptyMessageDelayed(int what, long delayMillis) {
Message msg = Message.obtain();
msg.what = what;
return sendMessageDelayed(msg, delayMillis);
}
从源码可以看到sendEmptyMessageDelayed调用的也是sendMessageDelayed，所以我们跟踪sendMessageDelayed的实现即可。
sendMessageDelayed
public final boolean sendMessageDelayed(@NonNull Message msg, long delayMillis) {
if (delayMillis < 0) {
delayMillis = 0;
}
return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
}
public boolean sendMessageAtTime(@NonNull 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);
}
sendMessageDelayed原型如上，可以看出其调用sendMessageAtTime将当前消息添加到MessageQueue中（enqueueMessage用于执行Message入队操作），需要注意的是这里的delayMillis是基于SystemClock.uptimeMillis()计算的，而不是当前系统时间，SystemClock.uptimeMillis()是计算的是系统自开机以来的非深度休眠时间。同时我们也可以看出对于延时消息而言，其执行时间是固定计算好的，那么延时消息一定能在期望的这个时间点触发吗？答案是不能，原因很多，常见的原因如下：
- 因为队列中消息是顺序处理的，如果延时消息的前一个消息执行时间过长，超出了队列中等待的延时消息的唤醒时间，那么延时自然是不准确的
- 因为计算的是系统开机到现在的非深度休眠时间，如果延时过长，在过程中系统发生休眠，时间自然也不准
enqueueMessage
private boolean enqueueMessage(@NonNull MessageQueue queue, @NonNull Message msg,
long uptimeMillis) {
msg.target = this;
msg.workSourceUid = ThreadLocalWorkSource.getUid();
if (mAsynchronous) {
msg.setAsynchronous(true);
}
return queue.enqueueMessage(msg, uptimeMillis);
}
可以看到其将msg.target设置成当前handler对象后，最终调用MessageQueue的enqueueMessage方法将消息入队，接下来我们看下Message.enqueueMessage的实现
boolean enqueueMessage(Message msg, long when) {
if (msg.target == null) {
throw new IllegalArgumentException("Message must have a target.");
}
synchronized (this) {
if (msg.isInUse()) {
throw new IllegalStateException(msg + " This message is already in use.");
}
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;
// 如果当前队列为空，或者当前Msg的when比头节点的
// when小，则将当前消息插入队列头
if (p == null || when == 0 || when < p.when) {
// 新添加的头节点，要唤醒Looper处理
msg.next = p;
mMessages = msg;
needWake = mBlocked;
} else {
// 按照msg.when自小向大的顺序，插入当前Msg
// 到合适的位置,判断是否需要唤醒Looper
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;
}
if (needWake) {
// 唤醒Looper循环
nativeWake(mPtr);
}
}
return true;
}
至此，我们的延时消息就成功添加到消息队列中了，可以看到，当有新消息入队时，则会唤醒Looper循环处理新消息。同时我们也可以看出MessageQueue其实并不是一个Queue，其是一个以msg.when自小向大排序的头插单链表。
延时消息触发
在Thread，Looper关系一节中，我们知道Looper会循环处理MessageQueue中的消息，接下来我们来看下Looper中的实现-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.");
}
if (me.mInLoop) {
Slog.w(TAG, "Loop again would have the queued messages be executed"
+ " before this one completed.");
}
...
for (;;) {
if (!loopOnce(me, ident, thresholdOverride)) {
return;
}
}
}
可以看到调用Looper.loop后启动了一个死循环，一直调用loopOnce方法处理MessageQueue中的消息，符合我们前文结论。
@SuppressWarnings("AndroidFrameworkBinderIdentity")
private static boolean loopOnce(final Looper me,
final long ident, final int thresholdOverride) {
// 从消息队列中获取Message
Message msg = me.mQueue.next(); // might block
...
try {
// 处理msg
msg.target.dispatchMessage(msg);
if (observer != null) {
observer.messageDispatched(token, msg);
}
dispatchEnd = needEndTime ? SystemClock.uptimeMillis() : 0;
} catch (Exception exception) {
if (observer != null) {
observer.dispatchingThrewException(token, msg, exception);
}
throw exception;
} finally {
ThreadLocalWorkSource.restore(origWorkSource);
if (traceTag != 0) {
Trace.traceEnd(traceTag);
}
}
...
return true;
}
从loopOnce中可以看出我们首先通过MessageQueue.next获取到将要处理的Message，成功获取后，调用msg.target.dispatchMessage处理消息，而msg.target取值就是当初的Handler对象，从这里可以看出是怎么把消息交给发送他的Handler处理的。
从loopOnce中不能看出延时消息的触发机制，接下来我们来看下MessageQueue.next中是否有相关信息。
@UnsupportedAppUsage
Message next() {
...
int nextPollTimeoutMillis = 0;
for (;;) {
...
// 根据nextPollTimeoutMillis设置超时唤醒
// 如果是-1则阻塞Looper循环
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) {
// 同步屏障处理逻辑，当msg.target为null时
// 优先处理异步消息
do {
prevMsg = msg;
msg = msg.next;
} while (msg != null && !msg.isAsynchronous());
}
if (msg != null) {
if (now < msg.when) {
// 当前节点还没有到触发时间，计算新的
// 唤醒时间
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;
}
...
}
}
从代码可以看出，如果有消息符合条件可以处理，也就是当前时间 >= msg.when时，则将当前要处理的消息返回，如果没有消息符合处理条件，则计算当前代处理消息响应时间与当前时间的差距，将差距设置为超时唤醒时间，当超过超时时间后，会唤醒Looper循环继续处理。
Looper循环的唤醒和阻塞在Native层通过epoll机制来实现，epoll机制，是一种IO多路复用机制，可以同时监控多个描述符，当某个描述符就绪(读或写就绪)，则立刻通知相应程序进行读或写操作，本质上是监听文件fd。
总结
面试题
- msg怎么找到发送它的handler？
- sendMessageDelayed延时准确吗？可以用来执行定时任务吗？
- Handler怎么实现线程切换的？
- Handler底层的休眠和唤醒是怎么实现的？什么时候休眠？什么时候唤醒？
- 怎么在子线程使用Handler？
- Looper.quit和Looper.quitSafely有什么区别？
- 一个消息队列停止以后还能收到消息吗？
