关于 Handler 的这 20 个问题，你都清楚吗？

Posted 2023-04-22

参考技术A android 11 开始，AsyncTask 正式谢幕，变成了不推荐使用的 API。官方建议采用 Kotlin 协程替代，或者自行实现。

事实上，无论是 AsyncTask 还是协程，背后都有 Handler 的功劳。无论从普及原理的角度、还是从自行实现的角度，我们都需要吃透这个 Android 系统所特有的线程间通信方式Handler 机制！

初尝 Handler 机制的时候，原以为 Handler 类发挥了很大的作用。当你深入了解它的原理之后，会发现 Handler 只是该机制的 调用入口和回调 而已，最重要的东西是 Looper 和 MessagQueue，以及不断流转的 Message。

本次针对 Handler 机制常被提及和容易困扰的  20  个问题进行整理和回答，供大家解惑和回顾~

简述下 Handler 机制的总体原理？

Looper 存在哪？如何可以保证线程独有？

如何理解 ThreadLocal 的作用？

主线程 Main Looper 和一般 Looper 的异同？

Handler 或者说 Looper 如何切换线程？

Looper 的 loop() 死循环为什么不卡死？

Looper 的等待是如何能够准确唤醒的？

Message 如何获取？为什么这么设计？

MessageQueue 如何管理 Message？

理解 Message 和 MessageQueue 的异同？

Message 的执行时刻如何管理？

Handler、Mesage 和 Runnable 的关系如何理解？

IdleHandler 空闲 Message 了解过吗？有什么用？

异步 Message 或同步屏障了解过吗？怎么用？什么原理？

Looper 和 MessageQueue、Message 及 Handler 的关系？

Native 侧的 NativeMessageQueue 和 Looper 的作用是？

Native 侧如何使用 Looper？

Handler 为什么可能导致内存泄露？如何避免？

Handler 在系统当中的应用

Android 为什么不允许并发访问 UI？

1. 简述下 Handler 机制的总体原理？

Looper 准备和开启轮循：

尚无 Message 的话，调用 Native 侧的 pollOnce() 进入 无限等待

存在 Message，但执行时间 when 尚未满足的话，调用 pollOnce() 时传入剩余时长参数进入 有限等待

Looper#prepare() 初始化线程独有的 Looper 以及 MessageQueue

Looper#loop() 开启 死循环 读取 MessageQueue 中下一个满足执行时间的 Message

Message 发送、入队和出队：

Native 侧如果处于无限等待的话：任意线程向 Handler 发送 Message 或 Runnable 后，Message 将按照 when 条件的先后，被插入 Handler 持有的 Looper 实例所对应的 MessageQueue  中 适当的位置 。MessageQueue 发现有合适的 Message 插入后将调用 Native 侧的 wake() 唤醒无限等待的线程。这将促使 MessageQueue 的读取继续 进入下一次循环 ，此刻 Queue 中已有满足条件的 Message 则出队返回给 Looper

Native 侧如果处于有限等待的话：在等待指定时长后 epoll_wait 将返回。线程继续读取 MessageQueue，此刻因为时长条件将满足将其出队

Looper 处理 Message 的实现：

Looper 得到 Message 后回调 Message 的 callback 属性即 Runnable，或依据 target 属性即 Handler，去执行 Handler 的回调。

存在 mCallback 属性的话回调 Handler$Callback

反之，回调 handleMessage()

2. Looper 存在哪？如何可以保证线程独有？

Looper 实例被管理在静态属性 sThreadLocal 中

ThreadLocal 内部通过 ThreadLocalMap 持有 Looper，key 为 ThreadLocal 实例本身，value 即为 Looper 实例

每个 Thread 都有一个自己的 ThreadLocalMap，这样可以保证每个线程对应一个独立的 Looper 实例，进而保证 myLooper() 可以获得线程独有的 Looper

彩蛋：一个 App 拥有几个 Looper 实例？几个 ThreadLocal 实例？几个 MessageQueue 实例？几个 Message 实例？几个 Handler 实例

一个线程只有一个 Looper 实例

一个 Looper 实例只对应着一个 MessageQueue 实例

一个 MessageQueue 实例可对应多个 Message 实例，其从 Message 静态池里获取，存在 50 的上限

一个线程可以拥有多个 Handler 实例，其Handler 只是发送和执行任务逻辑的入口和出口

ThreadLocal 实例是静态的，整个进程 共用一个实例 。每个 Looper 存放的 ThreadLocalMap 均弱引用它作为 key

3. 如何理解 ThreadLocal 的作用？

首先要明确并非不是用来切换线程的， 只是为了让每个线程方便程获取自己的 Looper 实例 ，见 Looper#myLooper()

后续可供 Handler 初始化时 指定其所属的 Looper 线程

也可用来线程判断自己是否 是主线程

4. 主线程 Main Looper 和一般 Looper 的异同？

区别：

Main Looper  不可 quit

主线程需要不断读取系统消息和用书输入，是进程的入口，只可被系统直接终止。进而其 Looper 在创建的时候设置了 不可quit的标志 ，而 其他线程的 Looper 则可以也必须手动 quit

Main Looper 实例还被 静态缓存

为了便于每个线程获得主线程 Looper 实例，见 Looper#getMainLooper()，Main Looper 实例还作为 sMainLooper 属性缓存到了 Looper 类中。

相同点：

都是通过 Looper#prepare() 间接调用 Looper 构造函数创建的实例

都被静态实例 ThreadLocal 管理，方便每个线程获取自己的 Looper 实例

彩蛋：主线程为什么不用初始化 Looper？

App 的入口并非 MainActivity，也不是 Application，而是 ActivityThread。

其为了 Application、ContentProvider、Activity 等组件的运行，必须事先启动不停接受输入的 Looper 机制，所以在 main() 执行的最后将调用 prepareMainLooper() 创建 Looper 并调用 loop() 轮循。

不需要我们调用，也不可能有我们调用。

可以说如果主线程没有创建 Looper 的话，我们的组件也不可能运行得到！

5. Handler 或者说 Looper 如何切换线程？

Handler 创建的时候指定了其所属线程的 Looper，进而持有了 Looper 独有的 MessageQueue

Looper#loop() 会持续读取 MessageQueue 中合适的 Message，没有 Message 的时候进入等待

当向 Handler 发送 Message 或 Runnable 后，会向持有的 MessageQueue 中插入 Message

Message 抵达并满足条件后会唤醒 MessageQueue 所属的线程，并将 Message 返回给 Looper

Looper 接着回调 Message 所指向的 Handler Callback 或 Runnable，达到线程切换的目的

简言之，向 Handler 发送 Message 其实是向 Handler 所属线程的独有 MessageQueue 插入 Message。而线程独有的 Looper 又会持续读取该 MessageQueue。所以向其他线程的 Handler 发送完 Message，该线程的 Looper 将自动响应。

6. Looper 的 loop() 死循环为什么不卡死？

为了让主线程持续处理用户的输入，loop() 是 死循环 ，持续调用 MessageQueue#next() 读取合适的 Message。

但当没有 Message 的时候，会调用 pollOnce() 并通过 Linux 的 epoll 机制进入等待并释放资源。同时 eventFd 会监听 Message 抵达的写入事件并进行唤醒。

这样可以 空闲时释放资源、不卡死线程，同时能持续接收输入的目的 。

彩蛋1：loop() 后的处理为什么不可执行

因为 loop() 是死循环，直到 quit 前后面的处理无法得到执行，所以避免将处理放在 loop() 的后面。

彩蛋2：Looper 等待的时候线程到底是什么状态？

调用 Linux 的 epoll 机制进入 等待 ，事实上 Java 侧打印该线程的状态，你会发现线程处于 Runnable 状态，只不过 CPU 资源被暂时释放。

7. Looper 的等待是如何能够准确唤醒的？

读取合适 Message 的 MessageQueue#next() 会因为 Message 尚无或执行条件尚未满足进行两种等的等待：

无限等待

尚无 Message（队列中没有 Message 或建立了同步屏障但尚无异步 Message）的时候，调用 Natvie 侧的 pollOnce() 会传入参数  -1 。

Linux 执行 epoll_wait() 将进入无限等待，其等待合适的 Message 插入后调用 Native 侧的 wake() 向唤醒 fd 写入事件触发唤醒 MessageQueue 读取的下一次循环

有限等待

有限等待的场合将下一个 Message  剩余时长作为参数 交给 epoll_wait()，epoll 将等待一段时间之后 自动返回 ，接着回到 MessageQueue 读取的下一次循环

8. Message 如何获取？为什么这么设计？

享元设计模式：通过 Message 的静态方法 obatin() 获取，因为该方法不是无脑地 new，而是 从单链表池子里获取实例 ，并在 recycle() 后将其放回池子

好处在于复用 Message 实例，满足频繁使用 Message 的场景，更加高效

当然，缓存池存在上限  50 ，因为没必要无限制地缓存，这本身也是一种浪费

需要留意缓存池是静态的，也就是整个进程共用一个缓存池

9. MessageQueue 如何管理 Message？

MessageQueue 通过单链表管理 Message，不同于进程共用的 Message Pool，其是线程独有的

通过 Message 的执行时刻 when 对 Message 进行排队和出队

MessageQueue 除了管理 Message，还要管理空闲 Handler 和 同步屏障

10. 理解 Message 和 MessageQueue 的异同？

相同点：都是通过 单链表来管理  Message 实例；

Message 通过  obtain() 和 recycle()  向单链表获取插入节点

MessageQueue 通过  enqueueMessage() 和 next()  向单链表获取和插入节点

区别：

Message 单链表是 静态的，供进程使用的缓存池

MessageQueue 单链表 非静态，只供 Looper 线程使用

11. Message 的执行时刻如何管理？

发送的 Message 都是按照执行时刻 when 属性的先后管理在 MessageQueue 里

延时 Message 的 when 等于调用的当前时刻和 delay 之和

非延时 Message 的 when 等于当前时刻（delay 为 0）

插队 Message 的 when 固定为 0，便于插入队列的 head

之后 MessageQueue 会根据 读取的时刻和 when 进行比较

将 when 已抵达的出队，

尚未抵达的计算出 当前时刻和目标 when 的插值 ，交由 Native 等待对应的时长，时间到了自动唤醒继续进行 Message 的读取

事实上，无论上述哪种 Message 都不能保证在其对应的 when 时刻执行，往往都会延迟一些！因为必须等当前执行的 Message 处理完了才有机会读取队列的下一个 Message。

比如发送了非延时 Message，when 即为发送的时刻，可它们不会立即执行。都要等主线程现有的任务（Message）走完才能有机会出队，而当这些任务执行完 when 的时刻已经过了。假使队列的前面还有其他 Message 的话，延迟会更加明显！

彩蛋：. onCreate() 里向 Handler 发送大量 Message 会导致主线程卡顿吗？

不会，发送的大量 Message 并非立即执行，只是先放到队列当中而已。

onCreate() 以及之后同步调用的 onStart() 和 onResume() 处理，本质上也是 Message。等这个 Message 执行完之后，才会进行读取 Message 的下一次循环，这时候才能回调 onCreate 里发送的 Message。

需要说明的是，如果发送的是 FrontOfQueue 将 Message 插入队首也不会立即先执行，因为 onStart 和 onResume 是 onCreate 之后同步调用的，本质上是同一个 Message 的作业周期

12. Handler、Mesage 和 Runnable 的关系如何理解？

作为使用 Handler 机制的入口， Handler 是发送 Message 或 Runnable 的起点

发送的  Runnable 本质上也是 Message ，只不过作为 callback 属性被持有

Handler 作为 target 属性被持有在 Mesage 中 ，在 Message 执行条件满足的时候供 Looper 回调

事实上，Handler 只是供 App 使用 Handler 机制的 API，实质来说，Message 是更为重要的载体。

13. IdleHandler 空闲 Message 了解过吗？有什么用？

适用于期望 空闲时候执行，但不影响主线程操作 的任务

系统应用：

Activity destroy 回调就放在了 IdleHandler 中

ActivityThread 中 GCHandler 使用了 IdleHandler，在空闲的时候执行  GC  操作

App 应用：

发送一个返回 true 的 IdleHandler，在里面让某个 View 不停闪烁，这样当用户发呆时就可以诱导用户点击这个 View

将某部分初始化放在 IdleHandler 里不影响 Activity 的启动

14. 异步 Message 或同步屏障了解过吗？怎么用？什么原理？

异步 Message：设置了 isAsync 属性的 Message 实例

可以用异步 Handler 发送

也可以调用 Message#setAsynchronous() 直接设置为异步 Message

同步屏障：在 MessageQueue 的 某个位置放一个 target 属性为 null 的 Message ，确保此后的非异步 Message 无法执行，只能执行异步 Message

原理：当 MessageQueue 轮循 Message 时候 发现建立了同步屏障的时候，会去跳过其他 Message，读取下个 async 的 Message 并执行，屏障移除之前同步 Message 都会被阻塞

应用：比如 屏幕刷新 Choreographer 就使用到了同步屏障 ，确保屏幕刷新事件不会因为队列负荷影响屏幕及时刷新。

注意： 同步屏障的添加或移除 API 并未对外公开，App 需要使用的话需要依赖反射机制

15. Looper 和 MessageQueue、Message 及 Handler 的关系？

Message 是承载任务的载体，在 Handler 机制中贯穿始终

Handler 则是对外公开的 API，负责发送 Message 和处理任务的回调，是  Message 的生产者

MessagQueue 负责管理待处理 Message 的入队和出队，是  Message 的容器

Looper 负责轮循 MessageQueue，保持线程持续运行任务，是  Message 的消费者

彩蛋：如何保证 MessageQueue 并发访问安全？

任何线程都可以通过 Handler 生产 Message 并放入 MessageQueue 中，可 Queue 所属的 Looper 在持续地读取并尝试消费 Message。如何保证两者不产生死锁？

Looper 在消费 Message 之前要先拿到 MessageQueue  的锁， 只不过没有 Message 或 Message 尚未满足条件的进行等待前会事先释放锁 ，具体在于 nativePollOnce() 的调用在 synchronized 方法块的外侧。

Message 入队前也需先拿到 MessageQueue  的锁，而这时 Looper 线程正在等待且不持有锁，可以确保 Message 的成功入队。入队后执行唤醒后释放锁，Native 收到 event 写入后恢复 MessagQueue 的读取并可以拿到锁，成功出队。

这样一种在没有 Message 可以消费时执行等待同时不占着锁的机制，避免了生产和消费的死锁。

16. Native 侧的 NativeMessageQueue 和 Looper 的作用是？

NativeMessageQueue 负责连接 Java 侧的 MessageQueue，进行后续的 wait 和 wake，后续将创建 wake 的FD，并通过 epoll 机制等待或唤醒。 但并不参与管理 Java 的 Message

Native 侧也需要 Looper 机制，等待和唤醒的需求是同样的，所以将这部分实现都封装到了 JNI 的NativeMessageQueue  和  Native 的 Looper 中， 供 Java 和 Native 一起使用

17. Native 侧如何使用 Looper？

Looper Native 部分承担了 Java 侧 Looper 的等待和唤醒，除此之外其还提供了 Message、MessageHandler 或 WeakMessageHandler、LooperCallback 或 SimpleLooperCallback 等 API

这些部分可供 Looper 被 Native 侧直接调用，比如 InputFlinger 广泛使用了 Looper

主要方法是调用 Looper 构造函数或 prepare 创建 Looper，然后通过 poll 开始轮询，接着 sendMessage 或 addEventFd，等待 Looper 的唤醒。 使用过程和 Java 的调用思路类似

18. Handler 为什么可能导致内存泄露？如何避免？

持有 Activity 实例的内名内部类或内部类的 生命周期 应当和 Activity 保持一致，否则产生内存泄露的风险。

如果 Handler 使用不当，将造成不一致，表现为：匿名内部类或内部类写法的 Handler、Handler$Callback、Runnable，或者Activity 结束时仍有活跃的 Thread 线程或 Looper 子线程

具体在于：异步任务仍然活跃或通过发送的 Message 尚未处理完毕，将使得内部类实例的 生命周期被错误地延长 。造成本该回收的 Activity 实例 被别的 Thread 或 Main Looper 占据而无法及时回收 （活跃的 Thread 或 静态属性 sMainLooper 是 GC Root 对象）

建议的做法：

无论是 Handler、Handler$Callback 还是 Runnable，尽量采用 静态内部类 + 弱引用 的写法，确保尽管发生不当引用的时候也可以因为弱引用能清楚持有关系

另外在 Activity 销毁的时候及时地 终止 Thread、停止子线程的 Looper 或清空 Message ，确保彻底切断 Activity 经由 Message 抵达 GC Root 的引用源头（Message 清空后会其与 Handler 的引用关系，Thread 的终止将结束其 GC Root 的源头）

注意：静态的 sThreadLocal 实例不持有存放 Looper 实例的 ThreadLocalMap，而是由 Thread 持有。从这个角度上来讲，Looper 会被活跃的 GC Root Thread 持有，进而也可能导致内存泄露。

彩蛋：网传的 Handler$Callback 方案能否解决内存泄露？

不能。

Callback 采用内部类或匿名内部类写法的话，默认持有 Activity 的引用，而 Callback 被 Handler 持有。这最终将导致 Message -> Handler -> Callback -> Activity 的链条仍然存在。

19. Handler 在系统当中的应用

特别广泛，比如：

Activity 生命周期的管理

屏幕刷新

HandlerThread、IntentService

AsyncTask 等。

主要利用 Handler 的切换线程、主线程异步 Message 的重要特性。注意：Binder 线程非主线程，但很多操作比如生命周期的管理都要回到主线程，所以很多 Binder 调用过来后都要通过 Handler 切换回主线程执行后续任务，比如 ActviityThread$H 就是 extends Handler。

20. Android 为什么不允许并发访问 UI？

Android 中 UI 非线程安全，并发访问的话会造成数据和显示错乱。

但此限制的检查始于ViewRootImpl#checkThread()，其会在刷新等多个访问 UI 的时机被调用，去检查当前线程，非主线程的话抛出异常。

而 ViewRootImpl 的创建在 onResume() 之后，也就是说如果在 onResume() 执行前启动线程访问 UI 的话是不会报错的，这点需要留意！

彩蛋：onCreate() 里子线程更新 UI 有问题吗？为什么？

不会。

因为异常的检测处理在 ViewRootImpl 中，该实例的创建和检测在 onResume() 之后进行。

Maven 的这 7 个问题你思考过没有？

你关注的就是我关心的！

在如今的互联网项目开发当中，特别是Java领域，可以说Maven随处可见。Maven的仓库管理、依赖管理、继承和聚合等特性为项目的构建提供了一整套完善的解决方案，可以说如果你搞不懂Maven，那么一个多模块的项目足以让你头疼，依赖冲突就会让你不知所措，甚至搞不清楚项目是如何运行起来的.....OK，博主就曾经被Maven“伤害”过，那么该专题的目的就是：彻底搞定Maven！

上面描述了我们对Maven的一些使用方式，下面我们进行一些思考：

1、本地仓库？Maven到底有哪些仓库？它们什么关系？

Maven仓库：

本地仓库路径配置：

你要jar包，不可能每次都要联网去下载吧，多费劲，所以本地仓库就是相当于加了一层jar包缓存，先到这里来查。如果这里查不到，那么就去私服上找，如果私服也找不到，那么去中央仓库去找，找到jar后，会把jar的信息同步到私服和本地仓库中。

私服，就是公司内部局域网的一台服务器而已，你想一下，当你的工程Project-A依赖别人的Project-B的接口，怎么做呢？没有Maven的时候，当然是copy Project-B jar到你的本地lib中引入，那么Maven的方式，很显然需要其他人把Project-B deploy到私服仓库中供你使用。因此私服中存储了本公司的内部专用的jar！不仅如此，私服还充当了中央仓库的镜像，说白了就是一个代理！

2、关于<dependency>的使用

依赖管理：

其实这个标签揭示了jar的查找坐标：groupId、artifactId、version。

一般而言，我们可以到私服上输入artifactId进行搜索，或者到http://search.maven.org/、http://mvnrepository.com/上进行查找确定坐标。

version分为开发版本（Snapshot）和发布版本（Release），那么为什么要分呢？

在实际开发中，我们经常遇到这样的场景，比如A服务依赖于B服务，A和B同时开发，B在开发中发现了BUG，修改后，将版本由1.0升级为2.0，那么A必须也跟着在POM.XML中进行版本升级。过了几天后，B又发现了问题，进行修改后升级版本发布，然后通知A进行升级...可以说这是开发过程中的版本不稳定导致了这样的问题。

Maven，已经替我们想好了解决方案，就是使用Snapshot版本，在开发过程中B发布的版本标志为Snapshot版本，A进行依赖的时候选择Snapshot版本，那么每次B发布的话，会在私服仓库中，形成带有时间戳的Snapshot版本，而A构建的时候会自动下载B最新时间戳的Snapshot版本！

3、既然Maven进行了依赖管理，为什么还会出现依赖冲突？处理依赖冲突的手段是？

依赖的版本？

首先来说，对于Maven而言，同一个groupId同一个artifactId下，只能使用一个version！

根据上图的依赖顺序，将使用1.2版本的jar。

现在，我们可以思考下了，比如工程中需要引入A、B，而A依赖1.0版本的C，B依赖2.0版本的C，那么问题来了，C使用的版本将由引入A、B的顺序而定？这显然不靠谱！如果A的依赖写在B的依赖后面，将意味着最后引入的是1.0版本的C，很可能在运行阶段出现类（ClassNotFoundException）、方法（NoSuchMethodError）找不到的错误（因为B使用的是高版本的C）！

这里其实涉及到了2个概念：依赖传递（transitive）、Maven的最近依赖策略。

依赖传递：如果A依赖B，B依赖C，那么引入A，意味着B和C都会被引入。

Maven的最近依赖策略：如果一个项目依赖相同的groupId、artifactId的多个版本，那么在依赖树（mvn dependency:tree）中离项目最近的那个版本将会被使用。（从这里可以看出Maven是不是有点小问题呢？能不能选择高版本的进行依赖么？据了解，Gradle就是version+策略）

现在，我们可以想想如何处理依赖冲突呢？

想法1：要使用哪个版本，我们是清楚的，那么能不能不管如何依赖传递，都可以进行版本锁定呢？

使用<dependencyManagement>  [这种主要用于子模块的版本一致性中]

想法2：在依赖传递中，能不能去掉我们不想依赖的？

使用<exclusions> [在实际中我们可以在IDEA中直接利用插件帮助我们生成]

想法3：既然是最近依赖策略，那么我们就直接使用显式依赖指定版本，那不就是最靠近项目的么？

使用<dependency>

4、引入依赖的最佳实践，提前发现问题！

在工程中，我们避免不了需要加一些依赖，也许加了依赖后运行时才发现存在依赖冲突在去解决，似乎有点晚！那么能不能提前发现问题呢？

如果我们新加入一个依赖的话，那么先通过mvn dependency:tree命令形成依赖树，看看我们新加入的依赖，是否存在传递依赖，传递依赖中是否和依赖树中的版本存在冲突，如果存在多个版本冲突，利用上文的方式进行解决！

5、Maven规范化目录结构

这里需要注意2点：

第一：src/main下内容最终会打包到Jar/War中，而src/test下是测试内容，并不会打包进去。

第二：src/main/resources中的资源文件会COPY至目标目录，这是Maven的默认生命周期中的一个规定动作。（想一想，hibernate/mybatis的映射XML需要放入resources下，而不能在放在其他地方了）

6、Maven的生命周期

Maven生命周期：

我们只需要注意一点：执行后面的命令时，前面的命令自动得到执行。

实际上，我们最常用的就是这么几个：

clean：有问题，多清理！

package：打成Jar or War包，会自动进行clean+compile

install：将本地工程Jar上传到本地仓库

deploy：上传到私服

7、关于scope依赖范围

既然，Maven的生命周期存在编译、测试、运行这些过程，那么显然有些依赖只用于测试，比如junit；有些依赖编译用不到，只有运行的时候才能用到，比如mysql的驱动包在编译期就用不到（编译期用的是JDBC接口），而是在运行时用到的；还有些依赖，编译期要用到，而运行期不需要提供，因为有些容器已经提供了，比如servlet-api在tomcat中已经提供了，我们只需要的是编译期提供而已。

总结来说：

compile：默认的scope，运行期有效，需要打入包中。

provided：编译期有效，运行期不需要提供，不会打入包中。

runtime：编译不需要，在运行期有效，需要导入包中。（接口与实现分离）

test：测试需要，不会打入包中。

system：非本地仓库引入、存在系统的某个路径下的jar。（一般不使用）

原文链接：

https://www.jianshu.com/p/20b39ab6a88c

来都来了，不点个“在看”？

- End -

点击阅读原文，领取2000G视频资源&&千份电子书