一、Handler原理
1. Looper和消息队列机制
Handler持有了一个消息队列MessageQueue对象mQueue。这个对象是Handler实例构造的时候，通过Looper传递过来的。当使用无参构造方法时，这个Looper为Looper.myLooper()。
public Handler() {
// 。。。
mLooper = Looper.myLooper();
mQueue = mLooper.mQueue;
}
而Looper类又是通过 ThreadLocal 来实现线程和Looper对象一一对应的。Looper.myLooper()即是当前线程所对应的Looper。
也就是说，Handler中的消息队列，其实是当前线程对应的Looper的消息队列。
那么，要理解Handler的原理，就要先理解Looper和消息队列的原理。
1.1 Looper
事情又要回到ActivityThread中说起，这相当于是一个Android程序的主线程，main方法就在其中。
ActivityThread.main()
public static void main(String[] args) {
// ...
Looper.prepareMainLooper();
Looper.loop();
throw new RuntimeException("Main thread loop unexpectedly exited");
}
在这里，调用了Looper的两个方法，prepare和loop，启动了主线程的Looper。Looper的结构相对来说还是比较简单的，其中最主要的就是这两个方法了。
Looper.prepare()
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));
}
在Looper内部，有一个ThreadLocal<Looper>类型的静态变量sThreadLocal。
而prepare的过程很简单，就是将当前这个Looper对象，保存到这个sThreadLocal中。即：以sThreadLocal为媒介，建立当前线程与当前Looper对象的对应关系。
Looper.loop()
这是Android程序中最重要的机制之一，也是Android程序能够一直运行的原因。以下是Looper.loop()源码，删去了绝大部分，只保留了最关键的几行：
public static void loop() {
final Looper me = myLooper();
final MessageQueue queue = me.mQueue;
for (;;) {
Message msg = queue.next(); // might block
try {
msg.target.dispatchMessage(msg);
} // ...
}
}
可以发现，loop()函数其实是一个死循环；在这个循环中，不停地从消息队列中取下一条消息，然后分发给对应的Handler（msg.target）进行处理。
“Looper”就是循环的意思，这正对应了loop()方法中的这个死循环。在这个死循环里面，可以无限读取消息队列中的消息。使用quit()方法可以退出这个循环；如果在主线程的Looper退出，也就意味着程序的结束——将会得到 java.lang.IllegalStateException: Main thread not allowed to quit. 的报错信息。
1.2 消息队列 - MessageQueue
-
Message
Message消息是Handler传递信息的基本单位。在Handler中，不管是调用post(Runnable)还是sendMessage(Message)还是其他的什么，最终都会构建一个Message对象，并添加到消息队列mQueue中。Message中保存了消息的类型、参数、对应的Handler等一些少量的数据。
在1.1中说到，Looper.loop()会发起一个死循环，在消息队列中不停取值。那么，为什么这里不会卡死呢？
Looper#loop()：
public static void loop() {
final Looper me = myLooper();
final MessageQueue queue = me.mQueue;
for (;;) {
Message msg = queue.next(); // might block
try {
msg.target.dispatchMessage(msg);
} // ...
}
}
跳转到MessageQueue.next()，看一下消息队列是怎么取下一条消息的。这里删去了大部分代码，只剩下核心的部分，方便梳理流程：
Message next() {
int nextPollTimeoutMillis = 0;
for (;;) {
nativePollOnce(ptr, nextPollTimeoutMillis); // 会阻塞线程直到下一个消息到来
synchronized (this) {
final long now = SystemClock.uptimeMillis();
Message msg = mMessages;
if (msg != null) {
if (now < msg.when) { // 时候未到
nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
} else {
mMessages = msg.next;
msg.next = null;
msg.markInUse();
return msg;
}
}
}
}
}
nativePollOnce是一个本地方法，它会阻塞线程直到下一个有消息来临。这类似于Java中的DelayQueue，不同点是DelayQueue是通过优先队列+锁实现的。
在MessageQueue中有一个Message类型的对象mMessage，它保存着消息队列中最早的一条消息。当阻塞的线程被唤醒时，next()方法会返回mMessage，并且mMessage重新赋值为mMessage.next。
很容易发现，在消息队列中，所有未读的消息是通过链表的形式来保存的，每一个Message都是链表中的节点，Message#next指向了链表中的下一个节点。
小结
- Looper和拥有Looper的线程一一对应，通过ThreadLocal来实现。Looper和消息队列也是一一对应的。
-
Looper.loop()中是一个死循环，会无限调用对应消息队列的next()方法来获取下一个消息。 - 消息队列的
next()方法会调用native方法nativePollOnce阻塞线程，直到有新的消息来临将其返回。 - 消息队列实质上是以
Message为节点的单向链表，其头节点为mMessage。链表是按照Message的触发时间，即msg.when，从早到晚排序的。
2. Handler传递消息的过程
从发送消息开始。使用Handler的post(runnalbe)、sendMessage(msg)、sendMessageDelayed(msg, delay)、Message的sendToTarget()等等许多方法都可以发送消息。最终，这些方法都会进入Handler#enqueueMessage方法。
- Handler#enqueueMessage(MessageQueue, Message, long)
enqueueMessage方法的作用是将Message的target设置为本Handler，然后调用MessageQueue的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);
}
这个queue即是Looper.mQueue，即当前线程的消息队列。在这里，会使用msg.target = this将Message与当前Handler绑定。
这里的uptimeMillis是Message预定送达的时间，如果没有设置延迟，那么这个时间是SystemClock.uptimeMillis()。
- MessageQueue#enqueueMessage(Message, long)
顾名思义，enqueueMessage表示将新到来的消息入队。
删去了部分，只保留关键代码：
boolean enqueueMessage(Message msg, long when) {
synchronized (this) {
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;
}
这里做了两件事：
一、将这个Message按照传达时间的顺序插入到消息队列中；
二、如果消息队列当前是阻塞的，并且这个消息的传达时间成为了消息队列中最早的一个，那么就将线程唤醒。
当消息入队之后，消息发送的过程就已经完毕了，接下来就是等待取出消息了。
- MessageQueue#next()
- Looper#loop()
第1小节提到了，Looper会无限循环从MessageQueue中读取消息。
public static void loop() {
for (;;) {
Message msg = queue.next(); // might block
try {
msg.target.dispatchMessage(msg);
} // ...
}
}
当一个消息msg到达指定时间并被读取到之后，会调用msg.target.dispatchMessage()方法；而这个target对象就是上面Handler#enqueueMessage()方法中传递进去的Handler。
也就是说，消息被读取到之后，会调用对应Handler的dispatchMessage方法。
- Handler#dispatchMessage()
public void dispatchMessage(@NonNull Message msg) {
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}
这里的逻辑很简单，如果这个Handler设置了Callback的话，就调用handleCallback回调，否则就调用handleMessage回调。可以看到，如果设置了Callback的话，Handler的handleMessage就不生效了，这一点很容易证实。
此时，就完成了从消息发送到消息处理的流程。
小结
Handler消息的传递流程：
->Handler#enqueueMessage(MessageQueue, Message, long)所有发送消息最终调用该方法
->MessageQueue#enqueueMessage(Message, long)消息入队
->MessageQueue#next()等待消息到时，取出消息
->Handler#dispatchMessage(msg)发送消息到对应Handler
->Handler#handleMessage(msg)或Handler.Callback#handleCallback(msg)：处理消息Handler相当于一个前台的工具人，只做了发送消息和接收消息的工作，消息处理的主要传递和分发过程都交给了Looper和MessageQueue。
二、Handler相关问题
1. 为什么Looper中的死循环不会阻塞主线程？
回到标题中的问题。
从上面的分析中，可以看到，在Looper.loop()的死循环中，主线程的确是被阻塞了；并且如果没有消息，将会一直阻塞下去——这一点毫无疑问。所以这个问题本身就是不严谨的：得先问是不是，再问为什么。
public static void loop() {
final Looper me = myLooper();
final MessageQueue queue = me.mQueue;
for (;;) {
Message msg = queue.next(); // might block
try {
msg.target.dispatchMessage(msg);
} // ...
}
}
这个问题正确的问法是，为什么主线程Looper中的死循环不会造成ANR/卡顿？
虽然这个问题仍然没有什么逻辑性——死循环和ANR/卡顿似乎并没有什么太大的联系，并且可以说是完全没有关系。要回答这个问题，首先要分析ANR/卡顿的原因，这是一个综合性的问题。
首先要明确的是，卡顿和ANR不是一回事儿。
卡顿指手机不能在肉眼无法察觉的时间内完成一帧的绘制。对于一个60hz的屏幕，每一帧需要在16ms内完成绘制，否则就会丢帧。丢帧越多，卡顿就越严重。卡顿的主要原因是主线程干了太多的事情，导致了16ms之内无法完成一帧的绘制，可能是布局层次太深导致绘图耗费时间长，可能是进行了复杂的运算，还有可能是频繁GC引发卡顿……总之，就是主线程负担太重了。
ANR指的是Application Not Responding，也就是应用无响应。这里ANR特指输入无响应ANR，也就是应用对触摸屏幕或者按键的响应时间超过5秒。也就是说，ANR的发生的必要条件是，需要有输入，也就是用户点击了屏幕之类的，否则是不会发生ANR的。当用户点击了屏幕，InputManagerService通过epoll机制在硬件层面读取到这个事件后，会使用InputDispatcher使用InputChannel通过Socket通知对应的ViewRootImpl。而ANR是在InputDispatcher.cpp中的handleTargetsNotReadyLocked函数检测的，在这里，当一个事件分发下去之后，会设置一个超时时间，也就5秒之后；在下一个事件到来时，如果时间大于超时时间，并且上一个事件还没有处理完毕的话，就要走ANR流程了。（见《ANR是如何产生的？》）
当然，究其根本原因，造成ANR的原因很多情况下与卡顿是类似的，但是二者是完全不同性质的两个事件。
回到问题上，卡顿是因为出于某种原因导致的绘制时间过长，而ANR的原因是对用户的操作响应超时。
而Looper中的死循环是为了读取消息，要知道Android应用本质上是消息驱动的，不管是卡顿还是ANR，本质上都是对应Handler或者Handler.Callback的handleMessage()处理消息方法的执行时间太长；而Looper中的死循环是在体系之外的，不在某个Handler的handleMessage()方法体之中，自然也就不会引起卡顿和ANR了。
2. Handler只能在主线程创建吗？如果不是，那Handler可以在任意线程创建吗？
否。
Handler的作用是作为一个终端发送和处理消息，需要配套的消息队列才能发挥作用。所以，Handler只能在调用了Looper.prepare()的线程中使用，并且在最后加上Looper.loop()使其生效。如果在没有调用Looper.prepare()的线程创建Handler，会出现 "Can't create handler inside thread that has not called Looper.prepare()" 的错误。
同时，这个线程的所有代码都要写在Looper.prepare()和Looper.loop()之间，因为Looper.loop()会阻塞线程，后面的代码没法执行到。
3. View.post()方法和Handler.post()是一样的吗？
View#post()方法本质上也是调用了Handler#post()，这个Handler保存在View的mAttachInfo中，通过父容器调用View的dispatchAttachedToWindow(attachInfo, visibility)方法传递过来。
这个Handler最终是指向ViewRootImpl中的mHandler对象，类型是继承自Handler类的ViewRootHandler。这个类中定义了一系列View需要用到的消息并进行了处理，如INVALIDATE等。
4. 获取Message的方式有哪些？哪种最好？
- 直接new
- 调用
Message.obtain()或者Handler#obtain()
第二种方法好，因为使用了消息池复用。因为Message类本身就可以作为一个链表的节点，所以消息池的数据结构是一个链表，每次复用取出头节点。
5. Handler是怎样起到切换线程作用的？是怎样在子线程发送消息然后在主线程处理的？
Handler发送消息的过程仅仅只是把消息放进消息队列里，这是在子线程里完成的。
主线程的Looper是一直在主线程运行的，当发现有新消息之后，就会提取出来，然后再在主线程把消息传递给Handler进行处理；这样就完成了线程切换。
6. 消息队列的数据结构是什么？
链表。
7. Handler为什么会造成内存泄漏？如何解决？
内存泄漏的原因是类成员的生命周期大于类对象的生命周期，换句话说就是一个需要销毁的对象由于成员被外部引用而无法销毁。
比如，一个Activity中有一个Handler成员对象。如果这个Handler发送了一个延时很长的消息，那么这个Handler在很长一段时间内都不能销毁，因为发送的消息的Message引用了这个Handler（msg.target），而这个Message还在消息队列中存活。这样，即使finish了这个Activity，它仍然会在内存中存活，造成内存泄漏。
解决方式一是使用static修饰Handler。如果Handler需要引用Activity，那么使用WeakReference弱引用。二是在Activity销毁的时候，在onDestroy()回调中清除Handler的所有回调。但是注意如果发送的消息周期的确是长于本Activity的，那么就不能使用方法二了。
