Android面试必问的 Handler 知识点

前言

• 在 Android 中，Handler 是贯穿于整个应用的消息机制，在面试中出现的概率为：100%
• 在这篇文章里，我将带你梳理 Handler 的使用攻略 & 设计原理。追求简单易懂又不失深度，如果能帮上忙，请务必点赞加关注！

延伸文章

• 关于ThreadLocal，请阅读：《Java | ThreadLocal 用法解析》
• 关于EventBus，请阅读： 《Android | 这是一份详细的 EventBus 使用教程》

---

目录

1. 概述

在 Android 中，很多地方是通过消息机制驱动的，例如线程间通信、四大组件的启动等等。消息机制中主要涉及 的类有：Handler & Looper & MessageQueue & Message，其中 Handler 可以说是消息机制提供给 Java 层的上层接口。

1.1 概念模型

问：Handler 怎么进行线程通信，原理是什么？

消息机制其实并不是 Android 系统独有的设计，在很多系统设计中都可以看到消息机制的身影，例如 IOS 的 runLoop、Web 的 Ajax 和 Spring 的消息队列等。在所有系统设计的消息机制里，都会有生产者与消费者的概念，如以下模型：

消息机制概念模型

其中消息缓冲区的具体实现可以是栈 & 队列，因为队列（特别是优先级队列）是最常见的，所以很多情况都会直接将消息缓冲区称为消息队列。

1.2 架构图

【类图】

• Looper 里组合了 MessageQueue 消息队列，创建 Looper 的同时也创建了 MessageQueue
• MessageQueue 里组合了待处理的 Message 链表
• Message 持有用于处理消息的 Handler(target)
• Handler 被创建时需要聚合 Looper 与 MessageQueue，默认使用的是当前线程的 Looper

1.3 消息的享元模式

消息机制里需要频繁创建消息对象（Message），因此消息对象需要使用享元模式来缓存，以避免重复分配 & 回收内存。具体来说，Message 使用的是有容量限制的、无头节点的单链表的对象池：

Message 的数据结构

---

2. Handler 核心源码分析

这一节我们来分析 Handler 的核心源码：

2.1 启动消息循环

• 问：Looper 如何在子线程中创建？（字节、小米）

要在哪个线程启动消息循环，就需要在该线程执行Looper.prepare() & Looper.loop()。只有调用Looper.loop()之后，消息循环才算真正运转起来了。具体来说，启动消息循环的分为两种情况：主线程消息循环 & 子线程消息循环，前者由 Framework 启动，而后者需要我们自己启动：

• 主线程消息循环

可以看到，在应用启动时，Framework 已经为主线程开启了消息循环，后续我们熟悉的startActivity & startService都是通过主线程消息循环来驱动的。

• 子线程消息循环

在子线程开启消息循环，我们需要自己调用Looper.prepare() & Looper.loop();。可以直接创建线程，或者使用 HandlerThread，后者主要考虑的多线程中获取 Looper 的同步问题，见 第 5.1 节。

小结一下：创建 Handler 的代码需要放在Looper.prepare(); & Looper.loop();中间执行，这是因为创建 Handler 对象时需要聚合 Looper 对象（默认使用的是当前线程的 Looper），而只有执行Looper.prepare();之后，才会创建该线程私有的 Looper 对象，否则创建 Handler 会抛异常。

2.2 Looper 线程唯一性

• 问：说一下 Looper、handler、线程间的关系。例如一个线程可以对应几个 Looper、几个Handler？

• 问：ThreadLocal 的原理，以及在 Looper 是如何应用的？

每个线程只允许调用一次Looper.prepare()，否则会抛异常。这样设计是因为一个 Looper 对应了一个消息循环，而一个线程进行多个消息循环是没有意义的（一个线程不可能同时进行两个死循环）。那么，Handler 是如何保证 Looper 线程唯一的呢？

答：首先，Handler 主要利用了 ThreadLocal 在每个线程单独存储副本的特性，保证了一个ThreadLocal在不同线程存取的Looper对象相互独立；其次，ThreadLocal 是 Looper 的一个static final变量，这样就保证了整个进程中 sThreadLocal对象不可变；第三，Looper.prepare()判断在一个线程里重复调用，则会抛出异常。

关于 ThreadLocal 的原理分析，在这篇文章里，我们详细讨论：《Java | ThreadLocal 用法解析》，请关注！

2.3 消息发送

• 问：Handler#post(Runnable) 是如何执行的？（字节、小米）

• 问：Handler#sendMessage() 和 Handler#postDelay() 的区别？（字节）

• 问：多个 Handler 发消息时，消息队列如何保证线程安全？

• 问：为什么 MessageQueue 不设置消息上限？

消息发送的 API 非常多，最终它们都会调用到Handler#sendMessageAtTime(Message msg, long uptimeMillis)，内部会交给MessageQueue#enqueueMessage(Message msg, long when)处理，梳理如下：

消息发送调用链

 

消息入队关键源码

小结一下：

• 每个消息的处理时间（when）不一样（SystemClock.uptimeMillis() + delayMill）
• 消息入队时，根据消息的处理时间（when）做插入排序，队头的消息就是最需要执行的消息
• 当消息队列为空时（无消息时线程会阻塞），消息入队需要唤醒线程
• 当消息队列不为空时（一般不需要唤醒），只有当开启同步屏障后第一个异步消息需要唤醒（开启同步屏障时会在队首插入一个占位消息，此时消息队列不为空，但是线程可能是阻塞的），关于同步屏障的内容见第 3 节

2.4 消息获取

• 问：消息队列无消息会怎么样？为什么 block 不会 ANR？

• 问：Looper 死循环为什么不会 ANR?（B站）

• 问：Looper 死循环为什么不阻塞主线程？

• 问：Handler内存泄漏的原因？

上一节我们说到，消息入队后 Looper 所在线程就会被唤醒（如果被阻塞），以继续消息循环。在消息循环中，Looper.loop()会死循环从 MessageQueue 获取队首的消息，因为消息已经按照处理时间（when）排序，所以每次获取的都是when最小的消息：

【图】 loop next

至于 Looper 死循环为什么不会 ANR?

 

消息队列中无消息怎么处理 block
nativePollOnce值为-1表示无限等待，让出cpu时间片给其线程，本线程等待
0表示无须等待直接返回
nativePollOnce -> epoll(linux) ->linux层的messagequeue

 

msg -> 5s -> ANRmsg

ANR：
5秒内没有响应输入事件，比如按键、屏幕触摸
10秒内没有处理广播
本质：消息队列中其他消息耗时，按键或广播消息没有及时处理

根本原因不是线程在睡眠，而是消息队列被其他耗时消息阻塞，导致按键或广播消息没有及时处理

 

Handler内存泄漏的原因
MessageQueue持有Message，Message持有activity
delay多久，message就会持有activity多久
方法：静态内部类、弱引用

取到一个消息时，如果when还不到，则有限等待（nextPollTimeoutMills）nativePoll()
如果消息队列没有消息，则无限等待nativePoll(-1,)，而消息入队时，会执行nativeWake()

quit也会nativeWake，唤醒Looper所在线程 => messagequeue返回null => Looper退出

2.5 消息分发

• 问：Message.callback 与 Handler.callback 哪个优先？

• 问：Handler.callback 和 handlemessage() 都存在，但 callback 返回 true，handleMessage() 还会执行么？（字节、小米）

获取需要执行的消息之后，将调用msg.target.dispatchMessage(msg);处理消息，具体如下：

【图】

 

public void dispatchMessage(Message msg) {
    if (msg.callback != null) {
        // 1. 设置了Message.Callback（Runnable）
        handleCallback(msg);
    } else {
        if (mCallback != null) {
            // 2. 设置了 Handler.Callback（Callback ）
            if (mCallback.handleMessage(msg)) {
                return;
            }
        }
        // 3. 未设置 Handler.Callback 或 返回 false
        handleMessage(msg);
    }
}
public interface Callback {
    public boolean handleMessage(Message msg);
}

可以看到，除了在Handler#handleMessage(...)中处理消息外，Handler 机制还提供了两个 Callback 来增加消息处理的灵活性。具体来说，若设置了Message.Callback则优先执行，否则判断Handler.Callback的返回结果，如果返回false，则最后分发到Handler.handleMessage(...)

2.6 终止消息循环

 

quit：
mQuitting = true
removeAllMessage()
nativeWake() 唤醒，程序从nativePollOnce(-1)开始执行

主线程Looper不允许退出 quit() 抛异常 mQuitAllowed = false
ActivityThead#main looper.loop() 之后抛异常 
原因：是handler驱动的机制，所有的事件都需要Handler处理，例如LAUNCH_ACTIVITY等

---

3. Handler 同步屏障机制

同步屏障（SyncBarrier）是 Handler 用来筛选高低优先级消息的机制，即：当开启同步屏障时，高优先级的异步消息优先处理。

3.1 开启同步屏障

3.2 关闭同步屏障

3.3 同步屏障下的消息循环

了解更多同步屏障： https://blog.csdn.net/jdsjlzx/article/details/110563162

---

4. IdleHandler 机制

• 问：IdleHandler 是什么？怎么使用，能解决什么问题？

详见：https://blog.csdn.net/jdsjlzx/article/details/110532500

---

5. Handler 应用场景

4.1 HandlerThread

Handler 都是在 Looper 所在线程创建的，但是有时候我们需要在其他线程中创建 Looper 所在线程的 Handler，就需要考虑同步问题，使用 HandlerThread 可以简化这种同步处理：

既然涉及多个线程的通信，会有同步的问题，Android为了简化Handler的创建过程，提供了HandlerThread类

wait - notifyAll - 避免prepare之前调用getLooper()

【重点 锁的机制】

4.2 IntentService

处理完 service 自动停止 内存释放

4.3 Fragment 生命周期管理

attach -> commit
Glide生命周期管理 RequestManagerFragment 双重检查（避免连续两次with()重复创建Fragment，因为commit会发到Handle消息队列的）

Handler是贯穿于Android的消息管理机制

所有的代码都是在Handler上运行的（loop()死循环）