目录
基础了解：
相关概念解释
整体流程图：
源码解析
Looper
总结：
sendMessage
总结：
ThreadLocal
基础了解：
Handler是一套 Android 消息传递机制,主要用于线程间通信。实际上handler其实就是主线程在起了一个子线程，子线程运行并生成Message，Looper获取message并传递给Handler，Handler逐个获取子线程中的Message，在这个机制下中包括了Looper、MessageQueue，ThreadLocal等
相关概念解释
Handler、Message、Message Queue、Looper
Message ：代表一个行为what或者一串动作Runnable, 每一个消息在加入消息队列时,都有明确的目标Handler
ThreadLocal： 线程本地存储区（Thread Local Storage，简称为TLS），每个线程都有自己的私有的本地存储区域，不同线程之间彼此不能访问对方的TLS区域。ThreadLocal的作用是提供线程内的局部变量TLS,这种变量在线程的生命周期内起作用,每一个线程有他自己所属的值(线程隔离)
MessageQueue (C层与Java层都有实现) ：以队列的形式对外提供插入和删除的工作, 其内部结构是以双向链表的形式存储消息的
Looper (C层与Java层都有实现) ：Looper是循环的意思,它负责从消息队列中循环的取出消息然后把消息交给Handler处理
Handler ：消息的真正处理者, 具备获取消息、发送消息、处理消息、移除消息等功能
整体流程图：
源码解析
分析源码：API 31
Looper
首先从new Handler点进去分析
可以看到，handler的构造方法里先判断当前创建的handler是否为static的，如果不是会弹log，
The following Handler class should be static or leaks might occur: ，这块后面在解释为啥会这么设置
同时声明了需要个looper，然后这个looper是Looper.myLooper中获取的，然后如果looper如果为空的话，则会抛出异常：
Can't create handler inside thread " + Thread.currentThread()
+ " that has not called Looper.prepare()
可以看出这个looper还是挺重要的，然后发现消息队列也是在looper中声明的，那么 我们就来看这个looper是怎么获取的，点
Looper.myLooper()方法进去看
发现是sThreadLocal中获取的 ，然后全局搜这块的实现
发现是在prepare(boolean)中赋值的，这块主要是创建一个looper，然后再looper的构造方法中创建了消息队列message queue，最后添加到sThreadLocal中
同时发现这个set方法有点熟悉呀，点进去看，我们发现
主要是通过ThreadLocalMap的set值实现的，这块是只进行一次set值，从而保证了一个looper的存在。
同时回到了之前的prepare（）方法中，我们ctrl看看，发现有个方法特别熟悉
prepareMainLooper（）
点进去看发现这块已经在
ActivitThread中调用了，这块之前通过其他大佬了解到，其实当我们点击了app图标后，根据启动流程会执行到ActivityThread中,这块也是通俗意义上说的主线程，所以说如果是在主线程中使用handler的话是不需要在调用Looper.loop()方法的，因为已经创建好了。
同时，我们注意到ActivityThread中的另外一个方法
点击进去看，发现
/**
* Poll and deliver single message, return true if the outer loop should continue.
*/
@SuppressWarnings("AndroidFrameworkBinderIdentity")
private static boolean loopOnce(final Looper me,
final long ident, final int thresholdOverride) {
Message msg = me.mQueue.next(); // might block
if (msg == null) {
// No message indicates that the message queue is quitting.
return false;
}
// This must be in a local variable, in case a UI event sets the logger
final Printer logging = me.mLogging;
if (logging != null) {
logging.println(">>>>> Dispatching to " + msg.target + " "
+ msg.callback + ": " + msg.what);
}
// Make sure the observer won't change while processing a transaction.
final Observer observer = sObserver;
final long traceTag = me.mTraceTag;
long slowDispatchThresholdMs = me.mSlowDispatchThresholdMs;
long slowDeliveryThresholdMs = me.mSlowDeliveryThresholdMs;
if (thresholdOverride > 0) {
slowDispatchThresholdMs = thresholdOverride;
slowDeliveryThresholdMs = thresholdOverride;
}
final boolean logSlowDelivery = (slowDeliveryThresholdMs > 0) && (msg.when > 0);
final boolean logSlowDispatch = (slowDispatchThresholdMs > 0);
final boolean needStartTime = logSlowDelivery || logSlowDispatch;
final boolean needEndTime = logSlowDispatch;
if (traceTag != 0 && Trace.isTagEnabled(traceTag)) {
Trace.traceBegin(traceTag, msg.target.getTraceName(msg));
}
final long dispatchStart = needStartTime ? SystemClock.uptimeMillis() : 0;
final long dispatchEnd;
Object token = null;
if (observer != null) {
token = observer.messageDispatchStarting();
}
long origWorkSource = ThreadLocalWorkSource.setUid(msg.workSourceUid);
try {
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);
}
}
if (logSlowDelivery) {
if (me.mSlowDeliveryDetected) {
if ((dispatchStart - msg.when) <= 10) {
Slog.w(TAG, "Drained");
me.mSlowDeliveryDetected = false;
}
} else {
if (showSlowLog(slowDeliveryThresholdMs, msg.when, dispatchStart, "delivery",
msg)) {
// Once we write a slow delivery log, suppress until the queue drains.
me.mSlowDeliveryDetected = true;
}
}
}
if (logSlowDispatch) {
showSlowLog(slowDispatchThresholdMs, dispatchStart, dispatchEnd, "dispatch", msg);
}
if (logging != null) {
logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
}
// Make sure that during the course of dispatching the
// identity of the thread wasn't corrupted.
final long newIdent = Binder.clearCallingIdentity();
if (ident != newIdent) {
Log.wtf(TAG, "Thread identity changed from 0x"
+ Long.toHexString(ident) + " to 0x"
+ Long.toHexString(newIdent) + " while dispatching to "
+ msg.target.getClass().getName() + " "
+ msg.callback + " what=" + msg.what);
}
msg.recycleUnchecked();
return true;
}根据注释发现这个方法是在当前线程中允许一个message queue进行for死循环从消息队列中取出消息，其中next方法会在下面分析，然后分发给msg.target中的dispatchMessage方法（其中msg.target是handler发送消息的时候赋值上去的，将在下面会说到），其中msg.target对应的就是handler，然后dispatchMessage源码为：
嗯，这块代码不需要解释了吧，如果没设置callback的话，则会直接回调发送消息的handler所在线程的handlerMessage方法了
总结：
1.一个线程中只能有一个looper，这块是由ThreadLocal决定的，因为ThreadLocal中包含了一个ThreadLocalMap，在调用looper.prepare时将looper对象set进去ThreadLocal中
2.UI线程，就是主线程是不需要在调用looper.prepare跟looper.loop()的，因为这2个在ActivityThread中的main方法中已经调用过了，其中looper.prepare调用的为looper.prepareMainLooper()
3.looper.prepare方法主要做的事就是赋值looper对象到ThreadLocal中，其中looper对象实例化时，创建了消息队列message queue，Looper.loop方法主要做的事就是调用message queue.next方法循环拿消息，如果有消息的话，则将消息进行分发到msg.target上对应的handler.dispatchMessage中，其中handler.dispatchMessage就是熟悉的handlerMessage
sendMessage
其实这块我们常见的handler的那些操作，本质上都是调用sendMessage的，只是换了个说法而已，常见的handler操作handler.sendMessage(msg)、handler.sendEmptyMessage(1)
handler.postDelay()、handler.post()，下面我们一个个点进去看
1.handler.sendMessage(msg)
2、sendEmptyMessage
3.handler.postDelay(Runable,time)
4.handler.post()
。是不是觉得跟postDelay一样，Runable通过getPostMessage方法，将传入的Runable变为 message的callback方法
可以发现，这几个handler的方法，都会调用sendsendMessageDelayed，然后调用sendMessageAtTime，最后调用enqueueMessage，进行消息处理，同时我们发现sendMessageAtTime中会设定个时间SystemClock.uptimeMillis()，这块时间为手机开机后系统非深度休眠时间，而不是手机时间。所以手机上修改当前时间是不会影响Message执行的。一般我们也可以通过这个值来获取手机开机多久。
然后我们来看enqueueMessage，其他那些looper、message queue已经在handler初始化的时候获取到了，其中在handler初始化的时候，通过looper.prepare已经创建好了
这块是跳转到message queue的enqueueMessage方法中
boolean enqueueMessage(Message msg, long when) {
if (msg.target == null) {
throw new IllegalArgumentException("Message must have a target.");
}
//保证多线程入队先加锁
synchronized (this) {
//....
msg.markInUse(); //标记正在使用
msg.when = when; // when 属性
Message p = mMessages; //拿到链表头部的消息
boolean needWake;
// 满足以下3种情况之一就把msg插入到链表头部
//1.队列为null
//2.当前时间没有延迟0
//3.插入的时间比链表的头节点的when时间早
if (p == null || when == 0 || when < p.when) {
msg.next = p;
mMessages = msg;
needWake = mBlocked; //如果处于阻塞状态，需要唤醒
} else {
//唤醒标识 ，
//4.如果p != null且msg并不是最早触发的，就在链表中找一个位置把msg插进去
//5.如果处于阻塞状态，并且链表头部是一个同步屏障（target为null的Message），并且插入消息是最早的异步消息，需要唤醒（ //队列为空，或者队列头消息还未到执行时间，且当前消息待执行时间小于队列头消息，此时才需要唤醒）
needWake = mBlocked && p.target == null && msg.isAsynchronous();
Message prev;
for (;;) {
prev = p;
p = p.next;
//当遍历到队尾、或者是 msg的时间比当前时间更早
if (p == null || when < p.when) {
break;
}
//发现了异步消息的存在，不需要唤醒
if (needWake && p.isAsynchronous()) {
needWake = false;
}
}
//单链表、插入msg信息
msg.next = p; // invariant: p == prev.next
prev.next = msg;
}
// 如果looper阻塞/休眠中，则唤醒looper循环机制处理消息
if (needWake) {
nativeWake(mPtr);//唤醒
}
}
return true;
}可以看到MessageQueue queue是通过链表形式对Message 进行存储，并通过when 的大小对 Message 进行排序。
其中，遍历插入过程如图：
遍历队列，当某个数据的时间戳优先级低于插入数据时，把数据插入；否则把数据放在队列尾部。
注意
Handler可以无限插入数据，没有大小限制。
然后我们回到之前分析过的looper中的loop方法
/**
* Run the message queue in this thread. Be sure to call
* {@link #quit()} to end the loop.
*/
@SuppressWarnings("AndroidFrameworkBinderIdentity")
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.");
}
me.mInLoop = true;
// Make sure the identity of this thread is that of the local process,
// and keep track of what that identity token actually is.
Binder.clearCallingIdentity();
final long ident = Binder.clearCallingIdentity();
// Allow overriding a threshold with a system prop. e.g.
// adb shell 'setprop log.looper.1000.main.slow 1 && stop && start'
final int thresholdOverride =
SystemProperties.getInt("log.looper."
+ Process.myUid() + "."
+ Thread.currentThread().getName()
+ ".slow", 0);
me.mSlowDeliveryDetected = false;
for (;;) {
if (!loopOnce(me, ident, thresholdOverride)) {
return;
}
}
}@SuppressWarnings("AndroidFrameworkBinderIdentity")
private static boolean loopOnce(final Looper me,final long ident, final int thresholdOverride) {
// 从Looper中取出MessageQueue进行轮询获取消息msg
Message msg = me.mQueue.next();
if (msg == null) {
// No message indicates that the message queue is quitting.
return false;
}
//....
try {
// Message.target 就是对应的Handler.dispatchMessage回调消息
msg.target.dispatchMessage(msg);
}
//....
//回收消息
msg.recycleUnchecked();
return true;
}核心就是这个next方法了，这个方法主要是将存在message queue中的消息取出来的
@UnsupportedAppUsage
Message next() {
// 如果消息循环已经退出并被处理，请返回此处。
// 如果应用程序尝试退出后不支持的循环程序，则会发生这种情况。
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();
}
//就是在这里根据nextPollTimeoutMillis判断是否要阻塞
// 阻塞方法，主要是通过 native 层的 epoll 监听文件描述符的写入事件来实现的。
// 如果 nextPollTimeoutMillis = -1，一直阻塞不会超时。
// 如果 nextPollTimeoutMillis = 0，不会阻塞，立即返回。
// 如果 nextPollTimeoutMillis > 0，最长阻塞nextPollTimeoutMillis毫秒(超时)，如果期间有程序唤醒会立即返回。
nativePollOnce(ptr, nextPollTimeoutMillis);
synchronized (this) {
// 尝试检索下一条消息。 如果找到则返回。
final long now = SystemClock.uptimeMillis();
Message prevMsg = null;
Message msg = mMessages;
if (msg != null && msg.target == null) {
// 被障碍挡住了。 在队列中查找下一条异步消息。
do {
prevMsg = msg;
msg = msg.next;
} while (msg != null && !msg.isAsynchronous());
}
if (msg != null) {//队列中拿到的消息不为null
if (now < msg.when) {
// 下一条消息尚未准备好。 设置超时以使其在准备就绪时醒来。
nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
} else {
// 正常返回处理
...
} else {
// 队列中没有消息，标记阻塞looper循环进入休眠
nextPollTimeoutMillis = -1;
}
// 现在已处理所有挂起的消息，处理退出消息。
if (mQuitting) {
dispose();
return null;
}
// If first time idle, then get the number of idlers to run.
// 空闲句柄仅在队列为空或将来要处理队列中的第一条消息（可能是屏障）时才运行。
if (pendingIdleHandlerCount < 0
&& (mMessages == null || now < mMessages.when)) {
pendingIdleHandlerCount = mIdleHandlers.size();
}
...
}
...
// 将空闲处理程序计数重置为0，这样我们就不会再次运行它们。
pendingIdleHandlerCount = 0;
// 在调用空闲处理程序时，可能已经传递了一条新消息，
//因此返回并再次查找未处理消息，而无需等待。
nextPollTimeoutMillis = 0;
}
}然后找到后返回loopOnce，将message分发给msg.target就是handler，然后就是如果有消息的话，则将消息进行分发到msg.target上对应的handler.dispatchMessage中，其中handler.dispatchMessage就是熟悉的handlerMessage，然后一切做完后会调用 msg.recycleUnchecked()进行消息的回收
具体流程如下：
总结：
1.handler.sendMessage、handler.sendEmptyMessage、handler.post、handler.postDelay本质上都是调用handler.sendsendMessageDelayed，然后调用sendMessageAtTime，最后调用enqueueMessage，进行添加消息处理
2.sendMessageAtTime中会设定个时间SystemClock.uptimeMillis()，这块时间为手机开机后系统非深度休眠时间，而不是手机时间。所以手机上修改当前时间是不会影响Message执行的。一般我们也可以通过这个值来获取手机开机多久
3.MessageQueue queue是通过链表形式对Message 进行存储，并通过when 的大小对 Message 进行排序。
4.Looper属于某个线程，而MessageQueue存储在Looper中，所以MessageQueue通过Looper特定的线程上关联，而Handler在构造中又与Looper和MessageQueue相互关联，通过Handler发送消息的时候，消息就会被插入到Handler关联的MessageQueue中，而Looper会不断的轮询消息，从MessageQueue中取出消息给相应的Handler处理，所有最终通过Handler发送的消息就会被执行到Looper所在的线程上，这就是 Handler线程切换的原理，无论发送消息Handler对象处于什么线程，最终处理消息都是在Looper所在的线程。
5.handler 阻塞、唤醒
阻塞条件：
分析MessageQueue的next函数，发生阻塞只会存在以上两种情况
- 队列中消息个数为0，且没有可处理的IdleHandler,此时会一直阻塞
- 队列中消息个数不为0，但是队列头消息还未到执行时间，且没有IdleHandler要执行，此时会阻塞时间n，n表示队列头消息距离执行的时间
以上两种阻塞情况，mBlock都为true.只有这两种情况需要唤醒。
一言以蔽之，没有IdleHandle要执行，且队列中没有立即要可执行的消息时，会阻塞
唤醒条件：
-
队列为空，或者队列头消息还未到执行时间，且当前消息待执行时间小于队列头消息，此时才需要唤醒。一言以蔽之，也就是当前消息插入到队列头部时，才需要唤醒。
-
mBlocked为true，也就是没有Idle消息要处理，且当前队列头消息时同步屏障消息，且当前消息时异步消息，此时需要立即处理，因为该异步消息对响应及时性要求比较高。
其实关于这个还涉及到一个面试题：“为啥looper.loop内部消息队列死循环不会导致应用卡死？”通过这个总结就很清晰了吧，
这里涉及线程，先说说说进程/线程，进程：每个app运行时前首先创建一个进程，该进程是由Zygote fork出来的，用于承载App上运行的各种Activity/Service等组件。进程对于上层应用来说是完全透明的，这也是google有意为之，让App程序都是运行在Android Runtime。大多数情况一个App就运行在一个进程中，除非在AndroidManifest.xml中配置Android:process属性，或通过native代码fork进程。
线程：线程对应用来说非常常见，比如每次new Thread().start都会创建一个新的线程。该线程与App所在进程之间资源共享，从Linux角度来说进程与线程除了是否共享资源外，并没有本质的区别，都是一个task_struct结构体，在CPU看来进程或线程无非就是一段可执行的代码，CPU采用CFS调度算法，保证每个task都尽可能公平的享有CPU时间片。
有了这么准备，再说说死循环问题：
对于线程既然是一段可执行的代码，当可执行代码执行完成后，线程生命周期便该终止了，线程退出。而对于主线程，我们是绝不希望会被运行一段时间，自己就退出，那么如何保证能一直存活呢？简单做法就是可执行代码是能一直执行下去的，死循环便能保证不会被退出，例如，binder线程也是采用死循环的方法，通过循环方式不同与Binder驱动进行读写操作，当然并非简单地死循环，无消息时会休眠。但这里可能又引发了另一个问题，既然是死循环又如何去处理其他事务呢？通过创建新线程的方式。
真正会卡死主线程的操作是在回调方法onCreate/onStart/onResume等操作时间过长，会导致掉帧，甚至发生ANR，looper.loop本身不会导致应用卡死。
ThreadLocal
通过get和set方法不难发现，其中频繁出现了一个ThreadLocalMap对象，这个变量跟map有点类似，是按键值对的方式对数据进行存储的，其中
key:指的当前ThreadLocal变量
value：T ，当前要存储的值
然后在点getMap方法看ThreadLocalMap是如何获取的
然后我们发现原来每个线程的threadLocals就是ThreadLocalMap来着，然后这个变量存储着ThreadLocal和对应的保存对象，这样的话，在不同的线程，访问同一个ThreadLocal对象，但是获取到的值是不一样的 ，这样就相对于用一个map存储所有线程的方式，会好很多了，因为那样的话管理也很混乱，每个线程有联系的话，也容易造成内存泄露
参考文章：
Handler源码分析 - 简书
Handler源码解析_Pioneer_Chang的博客-CSDN博客
Handler源码解析_handler messagequeue_醉饮千觞不知愁的博客-CSDN博客
Handler阻塞和唤醒条件 - 掘金
