Android Handler 机制是 Android 多线程通信的核心，负责线程切换与消息分发。通过 27 个关键问题深入解析 Handler 设计原理，涵盖 MessageQueue 链表结构、同步屏障与异步消息处理、ThreadLocal 绑定 Looper 机制、IdleHandler 空闲任务执行以及 Handler 内存泄漏成因等核心知识点。同时探讨了 HandlerThread、IntentService 的使用场景及 BlockCanary 卡顿检测原理，旨在帮助开发者全面掌握 Android 消息循环体系，优化应用性能并避免常见陷阱。
Handler 是 Android 消息机制的核心组件，主要用于跨线程通信。本文将通过 27 个常见问题，深入剖析其内部实现原理与最佳实践。
一种东西被设计出来肯定就有它存在的意义，而 Handler 的意义就是切换线程。
作为 Android 消息机制的主要成员，它管理着所有与界面有关的消息事件，常见的使用场景有：
比如 Activity 的启动，就是 AMS 在进行进程间通信的时候，通过 Binder 线程将消息发送给 ApplicationThread 的消息处理者 Handler，然后再将消息分发给主线程中去执行。
当子线程网络操作之后，需要切换到主线程进行 UI 更新。
总之一句话，Handler 的存在就是为了解决在子线程中无法访问 UI 的问题。
因为 Android 中的 UI 控件不是线程安全的，如果多线程访问 UI 控件那还不乱套了。
那为什么不加锁呢？
所以，Android 设计出了单线程模型来处理 UI 操作，再搭配上 Handler，是一个比较合适的解决方案。
崩溃发生在 ViewRootImpl 类的 checkThread 方法中：
void checkThread() {
if (mThread != Thread.currentThread()) {
throw new CalledFromWrongThreadException(
"Only the original thread that created a view hierarchy can touch its views.");
}
}
其实就是判断了当前线程是否是 ViewRootImpl 创建时候的线程，如果不是，就会崩溃。
而 ViewRootImpl 创建的时机就是界面被绘制的时候，也就是 onResume 之后，所以如果在子线程进行 UI 更新，就会发现当前线程（子线程）和 View 创建的线程（主线程）不是同一个线程，发生崩溃。
解决办法有三种：
看名字应该是个队列结构，队列的特点是什么？先进先出，一般在队尾增加数据，在队首进行取数据或者删除数据。
那 Handler 中的消息似乎也满足这样的特点，先发的消息肯定就会先被处理。但是，Handler 中还有比较特殊的情况，比如延时消息。
延时消息的存在就让这个队列有些特殊性了，并不能完全保证先进先出，而是需要根据时间来判断，所以 Android 中采用了链表的形式来实现这个队列，也方便了数据的插入。
来一起看看消息的发送过程，无论是哪种方法发送消息，都会走到 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;
return enqueueMessage(queue, msg, uptimeMillis);
}
sendMessageDelayed 方法主要计算了消息需要被处理的时间，如果 delayMillis 为 0，那么消息的处理时间就是当前时间。
然后就是关键方法 enqueueMessage。
boolean enqueueMessage(Message msg, long when) {
synchronized (this) {
msg.markInUse();
msg.when = when;
Message p = mMessages;
boolean needWake;
if (p == null || when == 0 || when < p.when) {
msg.next = p;
mMessages = msg;
needWake = mBlocked;
} else {
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;
prev.next = msg;
}
if (needWake) {
nativeWake(mPtr);
}
}
return true;
}
不懂得地方先不看，只看我们想看的：
好了，其他内容暂且不看，总之，插入消息就是通过消息的执行时间，也就是 when 字段，来找到合适的位置插入链表。
具体方法就是通过死循环，使用快慢指针 p 和 prev，每次向后移动一格，直到找到某个节点 p 的 when 大于我们要插入消息的 when 字段，则插入到 p 和 prev 之间。或者遍历到链表结束，插入到链表结尾。
所以，MessageQueue 就是一个用于存储消息、用链表实现的特殊队列结构。
总结上述内容，延迟消息的实现主要跟消息的统一存储方法有关，也就是上文说过的 enqueueMessage 方法。
无论是即时消息还是延迟消息，都是计算出具体的时间，然后作为消息的 when 字段进程赋值。
然后在 MessageQueue 中找到合适的位置（安排 when 小到大排列），并将消息插入到 MessageQueue 中。
这样，MessageQueue 就是一个按照消息时间排列的一个链表结构。
刚才说过了消息的存储，接下来看看消息的取出，也就是 queue.next 方法。
Message next() {
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) {
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;
msg.markInUse();
return msg;
}
} {
nextPollTimeoutMillis = -;
}
}
}
}
奇怪，为什么取消息也是用的死循环呢？
其实死循环就是为了保证一定要返回一条消息，如果没有可用消息，那么就阻塞在这里，一直到有新消息的到来。
其中，nativePollOnce 方法就是阻塞方法，nextPollTimeoutMillis 参数就是阻塞的时间。
那什么时候会阻塞呢？两种情况：
if (now < msg.when) {
nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
}
这时候阻塞时间就是消息时间减去当前时间，然后进入下一次循环，阻塞。
if (msg != null) {}
else {
// No more messages.
nextPollTimeoutMillis = -1;
}
-1 就代表一直阻塞。
接着上文的逻辑，当消息不可用或者没有消息的时候就会阻塞在 next 方法，而阻塞的办法是通过 pipe/epoll 机制
epoll 机制是一种 IO 多路复用的机制，具体逻辑就是一个进程可以监视多个描述符，当某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作，这个读写操作是阻塞的。在 Android 中，会创建一个 Linux 管道（Pipe）来处理阻塞和唤醒。
那什么时候会怎么唤醒消息队列线程呢？
还记得刚才插入消息的 enqueueMessage 方法中有个 needWake 字段吗，很明显，这个就是表示是否唤醒的字段。
其中还有个字段是 mBlocked，看字面意思是阻塞的意思，去代码里面找找：
Message next() {
for (;;) {
synchronized (this) {
if (msg != null) {
if (now < msg.when) {
nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
} else {
// Got a message.
mBlocked = false;
return msg;
}
}
if (pendingIdleHandlerCount <= 0) {
// No idle handlers to run. Loop and wait some more.
mBlocked = true;
continue;
}
}
}
}
在获取消息的方法 next 中，有两个地方对 mBlocked 赋值：
好了，确实这个字段就表示是否阻塞的意思，再去看看 enqueueMessage 方法中，唤醒机制：
boolean enqueueMessage(Message msg, long when) {
synchronized (this) {
boolean needWake;
if (p == null || when == 0 || when < p.when) {
msg.next = p;
mMessages = msg;
needWake = mBlocked;
} else {
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;
prev.next = msg;
}
if (needWake) {
nativeWake(mPtr);
}
}
return true;
}
再结合上述的例子，也就是当有新消息要插入表头了，这时候如果之前是阻塞状态（mBlocked=true），那么就要唤醒线程了。
也就是在插入消息之前，需要判断是否阻塞，并且表头是不是屏障消息，并且当前消息是不是异步消息。也就是如果现在是同步屏障模式下，那么要插入的消息又刚好是异步消息，那就不用管插入消息问题了，直接唤醒线程，因为异步消息需要先执行。
意思就是，如果之前有异步消息了，那肯定之前就唤醒过了，这时候就不需要再次唤醒了。
最后根据 needWake 的值，决定是否调用 nativeWake 方法唤醒 next() 方法。
其实在 Handler 机制中，有三种消息类型：
这三者之间的关系如何呢？
Message msg = mMessages;
if (msg != null && msg.target == null) {
do {
prevMsg = msg;
msg = msg.next;
} while (msg != null && !msg.isAsynchronous());
}
也就是说同步屏障消息不会被返回，他只是一个标志，一个工具，遇到它就代表要去先行处理异步消息了。
所以同步屏障和异步消息的存在的意义就在于有些消息需要'加急处理'。
使用场景就很多了，比如绘制方法 scheduleTraversals。
void scheduleTraversals() {
if (!mTraversalScheduled) {
mTraversalScheduled = true;
// 同步屏障，阻塞所有的同步消息
mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
// 通过 Choreographer 发送绘制任务
mChoreographer.postCallback(
Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
}
}
Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_CALLBACK, action);
msg.arg1 = callbackType;
msg.setAsynchronous(true);
mHandler.sendMessageAtTime(msg, dueTime);
在该方法中加入了同步屏障，后续加入一个异步消息 MSG_DO_SCHEDULE_CALLBACK，最后会执行到 FrameDisplayEventReceiver，用于申请 VSYNC 信号。
再看看 loop 方法，在消息被分发之后，也就是执行了 dispatchMessage 方法之后，还偷偷做了一个操作——recycleUnchecked。
public static void loop() {
for (;;) {
Message msg = queue.next(); // might block
try {
msg.target.dispatchMessage(msg);
}
msg.recycleUnchecked();
}
}
//Message.java
private static Message sPool;
private static final int MAX_POOL_SIZE = 50;
void recycleUnchecked() {
flags = FLAG_IN_USE;
what = 0;
arg1 = 0;
arg2 = 0;
obj = null;
replyTo = null;
sendingUid = UID_NONE;
workSourceUid = UID_NONE;
when = 0;
target = null;
callback = null;
data = null;
synchronized (sPoolSync) {
if (sPoolSize < MAX_POOL_SIZE) {
next = sPool;
sPool = this;
sPoolSize++;
}
}
}
在 recycleUnchecked 方法中，释放了所有资源，然后将当前的空消息插入到 sPool 表头。
这里的 sPool 就是一个消息对象池，它也是一个链表结构的消息，最大长度为 50。
那么 Message 又是怎么复用的呢？在 Message 的实例化方法 obtain 中：
public static Message obtain() {
synchronized (sPoolSync) {
if (sPool != null) {
Message m = sPool;
sPool = m.next;
m.next = null;
m.flags = 0; // clear in-use flag
sPoolSize--;
return m;
}
}
return new Message();
}
直接复用消息池 sPool 中的第一条消息，然后 sPool 指向下一个节点，消息池数量减一。
在 Handler 发送消息之后，消息就被存储到 MessageQueue 中，而 Looper 就是一个管理消息队列的角色。Looper 会从 MessageQueue 中不断的查找消息，也就是 loop 方法，并将消息交回给 Handler 进行处理。
而 Looper 的获取就是通过 ThreadLocal 机制:
static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<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));
}
public static @Nullable Looper myLooper() {
return sThreadLocal.get();
}
通过 prepare 方法创建 Looper 并且加入到 sThreadLocal 中，通过 myLooper 方法从 sThreadLocal 中获取 Looper。
下面就具体说说 ThreadLocal 运行机制。
//ThreadLocal.java
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();
}
public void set(T value) {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null)
map.set(this, value);
else
createMap(t, value);
}
从 ThreadLocal 类中的 get 和 set 方法可以大致看出来，有一个 ThreadLocalMap 变量，这个变量存储着键值对形式的数据。
然后继续看看 ThreadLocalMap 哪来的，也就是 getMap 方法：
//ThreadLocal.java
ThreadLocalMap getMap(Thread t) {
return t.threadLocals;
}
//Thread.java
ThreadLocal.ThreadLocalMap threadLocals = null;
原来这个 ThreadLocalMap 变量是存储在线程类 Thread 中的。
所以 ThreadLocal 的基本机制就搞清楚了：
在每个线程中都有一个 threadLocals 变量，这个变量存储着 ThreadLocal 和对应的需要保存的对象。
这样带来的好处就是，在不同的线程，访问同一个 ThreadLocal 对象，但是能获取到的值却不一样。
挺神奇的是不是，其实就是其内部获取到的 Map 不同，Map 和 Thread 绑定，所以虽然访问的是同一个 ThreadLocal 对象，但是访问的 Map 却不是同一个，所以取得值也不一样。
这样做有什么好处呢？为什么不直接用 Map 存储线程和对象呢？
打个比方：
现在老师买了一批铅笔，然后想把这些铅笔发给同学们，怎么发呢？两种办法：
这种做法就是 Map 里面存储的是同学和铅笔，然后用的时候通过同学来从这个 Map 里找铅笔。
这种做法就有点像使用一个 Map，存储所有的线程和对象，不好的地方就在于会很混乱，每个线程之间有了联系，也容易造成内存泄漏。
这种做法就是 Map 里面存储的是老师和铅笔，然后用的时候老师说一声，同学只需要从口袋里拿出来就行了。
很明显这种做法更科学，这也就是 ThreadLocal 的做法，因为铅笔本身就是同学自己在用，所以一开始就把铅笔交给同学自己保管是最好的，每个同学之间进行隔离。
比如：Choreographer。
public final class Choreographer {
// Thread local storage for the choreographer.
private static final ThreadLocal<Choreographer> sThreadInstance =
new ThreadLocal<Choreographer>() {
@Override
protected Choreographer initialValue() {
Looper looper = Looper.myLooper();
if (looper == null) {
throw new IllegalStateException("The current thread must have a looper!");
}
Choreographer choreographer = new Choreographer(looper, VSYNC_SOURCE_APP);
if (looper == Looper.getMainLooper()) {
mMainInstance = choreographer;
}
return choreographer;
}
};
private static volatile Choreographer mMainInstance;
Choreographer 主要是主线程用的，用于配合 VSYNC 中断信号。
所以这里使用 ThreadLocal 更多的意义在于完成线程单例的功能。
Looper 的创建是通过 Looper.prepare 方法实现的，而在 prepare 方法中就判断了，当前线程是否存在 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));
}
private Looper(boolean quitAllowed) {
mQueue = new MessageQueue(quitAllowed);
mThread = Thread.currentThread();
}
所以同一个线程，只能创建一个 Looper，多次创建会报错。
按照字面意思就是是否允许退出，我们看看他都在哪些地方用到了：
void quit(boolean safe) {
if (!mQuitAllowed) {
throw new IllegalStateException("Main thread not allowed to quit.");
}
synchronized (this) {
if (mQuitting) {
return;
}
mQuitting = true;
if (safe) {
removeAllFutureMessagesLocked();
} else {
removeAllMessagesLocked();
}
}
}
哦，就是这个 quit 方法用到了，如果这个字段为 false，代表不允许退出，就会报错。
但是这个 quit 方法又是干嘛的呢？从来没用过呢。还有这个 safe 又是啥呢？
其实看名字就差不多能了解了，quit 方法就是退出消息队列，终止消息循环。
然后看看当调用 quit 方法之后，消息的发送和处理：
//消息发送
boolean enqueueMessage(Message msg, long when) {
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;
}
}
当调用了 quit 方法之后，mQuitting 为 true，消息就发不出去了，会报错。
再看看消息的处理，loop 和 next 方法：
Message next() {
for (;;) {
synchronized (this) {
if (mQuitting) {
dispose();
return null;
}
}
}
}
public static void loop() {
for (;;) {
Message msg = queue.next();
if (msg == null) {
// No message indicates that the message queue is quitting.
return;
}
}
}
很明显，当 mQuitting 为 true 的时候，next 方法返回 null，那么 loop 方法中就会退出死循环。
那么这个 quit 方法一般是什么时候使用呢？
我大致总结下：
在 loop 方法中，找到要处理的 Message，然后调用了这么一句代码处理消息：
msg.target.dispatchMessage(msg);
所以是将消息交给了 msg.target 来处理，那么这个 target 是啥呢？
找找它的来头：
//Handler
private boolean enqueueMessage(MessageQueue queue,Message msg,long uptimeMillis) {
msg.target = this;
return queue.enqueueMessage(queue, msg, uptimeMillis);
}
在使用 Hanlder 发送消息的时候，会设置 msg.target = this，所以 target 就是当初把消息加到消息队列的那个 Handler。
Hanlder 中主要的发送消息可以分为两种：
public final boolean post(@NonNull Runnable r) {
return sendMessageDelayed(getPostMessage(r), 0);
}
private static Message getPostMessage(Runnable r) {
Message m = Message.obtain();
m.callback = r;
return m;
}
通过 post 的源码可知，其实 post 和 sendMessage 的区别就在于：
post 方法给 Message 设置了一个 callback。
那么这个 callback 有什么用呢？我们再转到消息处理的方法 dispatchMessage 中看看：
public void dispatchMessage(@NonNull Message msg) {
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}
private static void handleCallback(Message message) {
message.callback.run();
}
这段代码可以分为三部分看：
所以 post(Runnable) 与 sendMessage 的区别就在于后续消息的处理方式，是交给 msg.callback 还是 Handler.Callback 或者 Handler.handleMessage。
接着上面的代码说，这两个处理方法的区别在于 Handler.Callback.handleMessage 方法是否返回 true：
那么什么时候有 Callback，什么时候没有呢？这涉及到两种 Handler 的 创建方式：
val handler1= object : Handler(){
override fun handleMessage(msg: Message) {
super.handleMessage(msg)
}
}
val handler2 = Handler(object : Handler.Callback {
override fun handleMessage(msg: Message): Boolean {
return true
}
})
常用的方法就是第 1 种，派生一个 Handler 的子类并重写 handleMessage 方法。而第 2 种就是系统给我们提供了一种不需要派生子类的使用方法，只需要传入一个 Callback 即可。
总结：Looper、MessageQueue、线程是一一对应关系，而他们与 Handler 是可以一对多的。
主要做了两件事：
public static void main(String[] args) {
Looper.prepareMainLooper();
if (sMainThreadHandler == null) {
sMainThreadHandler = thread.getHandler();
}
Looper.loop();
throw new RuntimeException("Main thread loop unexpectedly exited");
}
final H mH = new H();
class H extends Handler {
public static final int BIND_APPLICATION = 110;
public static final int EXIT_APPLICATION = 111;
public static final int RECEIVER = 113;
public static final int CREATE_SERVICE = 114;
public static final int STOP_SERVICE = 116;
public static final int BIND_SERVICE = 121;
之前说过，当 MessageQueue 没有消息的时候，就会阻塞在 next 方法中，其实在阻塞之前，MessageQueue 还会做一件事，就是检查是否存在 IdleHandler，如果有，就会去执行它的 queueIdle 方法。
private IdleHandler[] mPendingIdleHandlers;
Message next() {
int pendingIdleHandlerCount = -1;
for (;;) {
synchronized (this) {
//当消息执行完毕，就设置 pendingIdleHandlerCount
if (pendingIdleHandlerCount < 0
&& (mMessages == null || now < mMessages.when)) {
pendingIdleHandlerCount = mIdleHandlers.size();
}
//初始化 mPendingIdleHandlers
if (mPendingIdleHandlers == null) {
mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
}
//mIdleHandlers 转为数组
mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
}
// 遍历数组，处理每个 IdleHandler
for (int i = 0; i < pendingIdleHandlerCount; i++) {
final IdleHandler idler = mPendingIdleHandlers[i];
mPendingIdleHandlers[i] = null; // release the reference to the handler
boolean keep = false;
try {
keep = idler.queueIdle();
} catch (Throwable t) {
Log.wtf(TAG, "IdleHandler threw exception", t);
}
(!keep) {
() {
mIdleHandlers.remove(idler);
}
}
}
pendingIdleHandlerCount = ;
}
}
当没有消息处理的时候，就会去处理这个 mIdleHandlers 集合里面的每个 IdleHandler 对象，并调用其 queueIdle 方法。最后根据 queueIdle 返回值判断是否用完删除当前的 IdleHandler。
然后看看 IdleHandler 是怎么加进去的：
Looper.myQueue().addIdleHandler(new IdleHandler() {
@Override
public boolean queueIdle() {
//做事情
return false;
}
});
public void addIdleHandler(@NonNull IdleHandler handler) {
if (handler == null) {
throw new NullPointerException("Can't add a null IdleHandler");
}
synchronized (this) {
mIdleHandlers.add(handler);
}
}
ok，综上所述，IdleHandler 就是当消息队列里面没有当前要处理的消息了，需要堵塞之前，可以做一些空闲任务的处理。
常见的使用场景有：启动优化。
我们一般会把一些事件（比如界面 view 的绘制、赋值）放到 onCreate 方法或者 onResume 方法中。但是这两个方法其实都是在界面绘制之前调用的，也就是说一定程度上这两个方法的耗时会影响到启动时间。
所以我们可以把一些操作放到 IdleHandler 中，也就是界面绘制完成之后才去调用，这样就能减少启动时间了。
但是，这里需要注意下可能会有坑。
如果使用不当，IdleHandler 会一直不执行，比如在 View 的 onDraw 方法里面无限制的直接或者间接调用 View 的 invalidate 方法。
其原因就在于 onDraw 方法中执行 invalidate，会添加一个同步屏障消息，在等到异步消息之前，会阻塞在 next 方法，而等到 FrameDisplayEventReceiver 异步任务之后又会执行 onDraw 方法，从而无限循环。
直接看源码：
public class HandlerThread extends Thread {
@Override
public void run() {
Looper.prepare();
synchronized (this) {
mLooper = Looper.myLooper();
notifyAll();
}
Process.setThreadPriority(mPriority);
onLooperPrepared();
Looper.loop();
}
哦，原来如此。HandlerThread 就是一个封装了 Looper 的 Thread 类。
就是为了让我们在子线程里面更方便的使用 Handler。
这里的加锁就是为了保证线程安全，获取当前线程的 Looper 对象，获取成功之后再通过 notifyAll 方法唤醒其他线程，那哪里调用了 wait 方法呢？
public Looper getLooper() {
if (!isAlive()) {
return null;
}
// If the thread has been started, wait until the looper has been created.
synchronized (this) {
while (isAlive() && mLooper == null) {
try {
wait();
} catch (InterruptedException e) {
}
}
}
return mLooper;
}
就是 getLooper 方法，所以 wait 的意思就是等待 Looper 创建好，那边创建好之后再通知这边正确返回 Looper。
老规矩，直接看源码：
public abstract class IntentService extends Service {
private final class ServiceHandler extends Handler {
public ServiceHandler(Looper looper) {
super(looper);
}
@Override
public void handleMessage(Message msg) {
onHandleIntent((Intent)msg.obj);
stopSelf(msg.arg1);
}
}
@Override
public void onCreate() {
super.onCreate();
HandlerThread thread = new HandlerThread("IntentService[" + mName + "]");
thread.start();
mServiceLooper = thread.getLooper();
mServiceHandler = new ServiceHandler(mServiceLooper);
}
@Override
public void onStart(@Nullable Intent intent, int startId) {
Message msg = mServiceHandler.obtainMessage();
msg.arg1 = startId;
msg.obj = intent;
mServiceHandler.sendMessage(msg);
}
理一下这个源码：
所以，这就是一个可以在子线程进行耗时任务，并且在任务执行后自动停止的 Service。
BlockCanary 是一个用来检测应用卡顿耗时的三方库。
上文说过，View 的绘制也是通过 Handler 来执行的，所以如果能知道每次 Handler 处理消息的时间，就能知道每次绘制的耗时了？那 Handler 消息的处理时间怎么获取呢？
再去 loop 方法中找找细节：
public static void loop() {
for (;;) {
// This must be in a local variable, in case a UI event sets the logger
Printer logging = me.mLogging;
if (logging != null) {
logging.println(">>>>> Dispatching to " + msg.target + " " +
msg.callback + ": " + msg.what);
}
msg.target.dispatchMessage(msg);
if (logging != null) {
logging.println("<<<<<<< Finished to " + msg.target + " " + msg.callback);
}
}
}
可以发现，loop 方法内有一个 Printer 类，在 dispatchMessage 处理消息的前后分别打印了两次日志。
那我们把这个日志类 Printer 替换成我们自己的 Printer，然后统计两次打印日志的时间不就相当于处理消息的时间了？
Looper.getMainLooper().setMessageLogging(mainLooperPrinter);
public void setMessageLogging(@Nullable Printer printer) {
mLogging = printer;
}
这就是 BlockCanary 的原理。
这也是常常被问的一个问题，Handler 内存泄露的原因是什么？
"内部类持有了外部类的引用，也就是 Handler 持有了 Activity 的引用，从而导致无法被回收呗。"
其实这样回答是错误的，或者说没回答到点子上。
我们必须找到那个最终的引用者，不会被回收的引用者，其实就是主线程，这条完整引用链应该是这样：
主线程 —> threadlocal —> Looper —> MessageQueue —> Message —> Handler —> Activity
主线程崩溃，其实都是发生在消息的处理内，包括生命周期、界面绘制。
所以如果我们能控制这个过程，并且在发生崩溃后重新开启消息循环，那么主线程就能继续运行。
Handler(Looper.getMainLooper()).post {
while (true) {
//主线程异常拦截
try {
Looper.loop()
} catch (e: Throwable) {
}
}
}
大家应该可以发现，有一个问题常被问，但是全篇都没有提，那就是：
Handler 机制的运行原理。
之所以不提这个问题，是因为要回答好这个问题需要大量知识储备，希望屏幕前的你在读完这篇之后，再结合自己的知识库，形成自己的完美答案。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
查找任何按下的键的javascript键代码、代码、位置和修饰符。 在线工具，Keycode 信息在线工具，online
JavaScript 字符串转义/反转义；Java 风格 \uXXXX（Native2Ascii）编码与解码。 在线工具，Escape 与 Native 编解码在线工具，online
使用 Prettier 在浏览器内格式化 JavaScript 或 HTML 片段。 在线工具，JavaScript / HTML 格式化在线工具，online
Terser 压缩、变量名混淆，或 javascript-obfuscator 高强度混淆（体积会增大）。 在线工具，JavaScript 压缩与混淆在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online