一、Handler 的循环为何不烧满 CPU Looper.loop 中确实存在一个没有退出次数限制的 for (;;)。但“循环一直存在”和“CPU 一直执行循环体”是两回事。只要当前没有可立即处理的消息，Java 层就会把等待时间交给 nativePollOnce，native 层最终进入 epoll_wait。线程此时处于阻塞等待状态，不会反复读取队列。 这条等待链可以总结为3点： 延迟

本文整理自享学团队直播课《Android 插件化(二)：Activity加载》。 上一讲解决的是"插件的类能被加载进来"，这一讲解决的是"插件的 Activity 能真正被启动"。前者靠类加载器，后者靠 Hook——在 Android 启动 Activity 的链路中间安插一个钩子，把"要启动哪个 Activity"这个信息偷偷换一遍，让一个已注册的占坑 Activity 去骗过 AMS 的校验，

主线程最终进入 Looper.loop ，正常运行时这个方法不会返回。既然线程一直停留在循环中，Activity 生命周期、点击事件和界面刷新为什么还能执行？ 关键在于：这些工作本来就由事件循环驱动。 主线程不需要先退出 loop 才能执行回调；回调就在循环处理事件的过程中被调用。空闲时，循环又会进入可唤醒的阻塞等待，避免持续空转。 一、先区分无限循环、忙等、死锁和 ANR 几个词经常被混用

本文内容整理自技术讲解视频《Handler 中的 Message 如何创建？》。 创建 Handler 消息时，new Message 可以工作，但通常应使用 Message.obtain 或 handler.obtainMessage 。它们会优先复用已经回收的 Message，池为空时才分配新对象。 一、先把创建方式用对 如果消息要发送给一个已知 Handler，可以直接从它取得消息

本文内容基于艾文老师（小米）的《06-MessageQueue如何保持各线程添加消息的线程安全？》讲解视频整理 多个线程可以同时向一个 Handler 发消息，也可以通过不同 Handler 向同一个 Looper 投递任务。发送方各自运行，最终却要修改同一个 MessageQueue：谁负责防止消息丢失、链表断开或队列状态混乱？ 答案是队列。在本文分析的实现中，MessageQueue 使用自身

本文根据视频《子线程中维护的 Looper 在无消息的时候应该怎么处理减少性能问题》整理。 子线程调用 Looper.loop 后，即使没有消息，方法也不会自动返回。看到这里的无限循环，很容易产生两个疑问：它会不会一直占用 CPU？如果不再使用这条线程，又该怎样让它结束？ 这两个问题需要分开回答：暂时没有消息时，Looper 会阻塞等待，不需要额外加休眠；业务不再需要这条消息线程时，应主动调用

本文根据视频《为何主线程可以new Handler，子线程中如何new Handler》整理。 一、为什么换一个线程，new Handler 就报错？ 在主线程的 Activity.onCreate 中，下面这行代码通常可以正常执行： 把它放到一个普通子线程里，就可能得到这样的异常： 关键在于无参构造会查找当前线程的 Looper。Android 框架已经为应用主线程准备好了 Looper，而

本文内容整理自享学团队直播课《Handler 运行流程源码解析（三）》 一、先说结论：Handler 本身不会自动导致内存泄漏 “Handler 为什么会导致内存泄漏？”这个问题，常见回答是“生命周期不一致”或“内部类持有外部类”。这两句话都触及了现象，却没有解释完整。 真正决定对象能否被回收的，是它是否仍能从 GC Root 到达。以 Activity 中的非静态内部类 Handler 为例，只