我印象最深的一次线上事故发生在一个版本迭代之后。用户在快速滑动列表页时偶现闪退后台监控里堆出大批相同堆栈全部指向某个按钮的点击回调。查了大半天最初的怀疑对象是网络库、图片加载最后才发现问题出在新手同学在子线程拿到结果之后直接调用了textView.setText()。那一刻我意识到Handler用起来简单但为什么必须用它它背后到底做了什么很多人其实没有真正理解。这篇我打算从那次事故讲起把Handler机制底层的Looper、MessageQueue、Message、Handler四个角色完整拆开再结合我多年项目里踩过的坑聊清楚内存泄漏、延迟消息、主线程死循环这些高频问题的根源最后给出选型建议。适合刚入行的同学建立整体认知也适合准备面试、或者想把手头各种postDelayed用得更加稳妥的老开发。1. 一次线上崩溃事故Handler存在的全部理由1.1 崩溃现场还原先还原一下当时的代码。这个场景在今天的新项目里依然普遍存在网络请求放到子线程里执行拿到结果后直接往TextView上更新然后等一个不确定的概率崩溃。很多人第一次遇到这个异常时都会一脸懵写法大概是这样的new Thread(new Runnable() { Override public void run() { String result requestServer(); textView.setText(result); // 直接更新UI } }).start();这段代码在低概率场景下会直接崩报错信息是android.view.ViewRootImpl$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.看到这个异常很多人的第一反应是知道了子线程不能更新UI但很少继续追问Android为什么要这么设计子线程更新个TextView文本到底会出什么大事1.2 View不是线程安全的加锁的代价太大真正的原因是TextView、ImageView这些控件内部维护着大量状态从文本内容到测量结果、布局位置再到绘制缓存。如果多个线程同时在修改同一个View的状态轻则界面显示错乱、绘制撕裂重则触发内存读写异常、直接崩溃。Android官方没有选择给每个View加一把大锁来保住线程安全原因也很简单UI操作集中在主线程加锁的成本高得离谱。一次setText就要去抢一次全局锁所有绘制、触摸事件都会跟着竞争性能会肉眼可见地变差。所以Android做了一个简单粗暴却极其有效的约定谁创建了View树谁才有资格更新它。这个持有者就是主线程。1.3 把更新UI打包成消息交给主线程既然只有主线程能碰UI子线程想把结果告诉主线程就需要一种跨线程投递的机制。Handler就是干这个的private final Handler mainHandler new Handler(Looper.getMainLooper()); new Thread(new Runnable() { Override public void run() { String result requestServer(); mainHandler.post(new Runnable() { Override public void run() { textView.setText(result); } }); } }).start();注意这里的关键点子线程只是把Runnable塞进了一个队列真正执行textView.setText()的人是主线程。所以Handler的本质不是在另一个线程执行代码而是把一段代码切换到指定线程的消息循环里去执行。搞清楚这一点后面所有机制就都好理解了。Handler也不只是UI更新的专用工具任何线程间需要安全地传递一个任务的场合它都是最基础、最通用的方案。2. 四大角色的分工Looper、MessageQueue、Message与Handler要理解Handler绕不开它的四个核心组成部分。很多人看源码时迷失在细节里就是因为没把这几个角色在系统里的职责边界看清楚。2.1 ThreadLocal与Looper一个线程只配一个消息循环Looper是消息循环的执行者负责不断从消息队列里取消息、分发消息。一个线程最多只能有一个Looper这个唯一性靠ThreadLocal保证。ThreadLocal可以简单理解成线程私有的存储空间。同一个ThreadLocal对象在不同的线程里读到的值互不相干。Looper在创建时就保存在ThreadLocal里所以无论代码走到哪只要当前线程有Looper随时都能通过Looper.myLooper()取出来。主线程的Looper是系统在ActivityThread.main()里调用Looper.prepareMainLooper()初始化好的所以我们在主线程里直接new Handler()不会报错。但在子线程里直接new Handler()十有八九会看到这个异常java.lang.RuntimeException: Cant create handler inside thread that has not called Looper.prepare()原因很简单Handler创建时要取当前线程的Looper取不到就只能罢工。想让子线程能收发消息必须先调用Looper.prepare()给这个线程装一个Looper再调用Looper.loop()启动循环。这正是HandlerThread存在的意义后面我会专门讲。2.2 MessageQueue不是队列是一根按时间排序的单链表MessageQueue是存放消息的地方名字里有Queue但底层实现并不是常规意义上的队列而是通过Message.next字段串起来的单链表。为什么用链表而不是数组因为消息的入队是有优先级的——根据期望执行时间when排序。插入一条新消息时需要从头部开始遍历找到第一个when比它晚的节点然后插到它前面。用链表做这种插入非常顺手不需要像数组那样搬移元素。Message本身除了携带用户数据what、arg1、arg2、obj还有两个非常重要的内部字段when表示期望执行时间target指向发送它的Handler。当Looper把消息取出来分发时就是靠target找到对应的Handler再回调到它的handleMessage方法。另外Message还有一个容易被忽略的点它自带消息对象池。标准做法是Message.obtain()而不是new Message()obtain会从sPool里取已经回收的Message复用减少对象创建和GC压力。使用完的消息会通过recycle()回到池子里。这个习惯在消息量大、频率高的场景比如动画回调里效果非常明显。2.3 Handler的双重身份既是投递员也是处理入口Handler在整个机制里承担两类工作对外发送消息对内接收消息回调。发送消息时sendMessage、sendEmptyMessage、post、postDelayed这些方法最终都会走同一条路把Message放进MessageQueue。接收消息时Looper从队列里取出消息调用msg.target.dispatchMessage(msg)再由dispatchMessage决定最终回调到哪里——可能是消息自带的Runnable callback也可能是Handler.Callback当然也可能是我们最熟悉的handleMessage。一张表把这四个角色的职责理清楚角色职责关键点Looper驱动整个消息循环prepare()初始化loop()开始取消息MessageQueue按时间排序存储消息底层是单链表next()会阻塞等待Message携带任务与数据有对象池obtain()复用Handler发送消息 处理消息target字段指向它决定回调归属很多人面试被问Handler、Looper、MessageQueue三者关系答不好其实只要抓住一句话Handler把Message按时间塞进MessageQueueLooper无限循环地从MessageQueue里取消息再交还给Handler自己处理。3. 一条消息的完整旅程从sendMessage到handleMessage前面把角色说清楚了现在沿着源码走一遍看看一条消息从投递到执行中间到底经历了什么。这个过程是理解所有Handler高级问题的钥匙。3.1 sendMessage只是做了排队动作调用handler.sendMessage(msg)后实际的调用链是这样的sendMessage(msg) - sendMessageDelayed(msg, 0) - sendMessageAtTime(msg, SystemClock.uptimeMillis() delayMillis) - enqueueMessage(msg, uptimeMillis)sendMessageAtTime里有个很容易被忽略的细节它取的时间基准是SystemClock.uptimeMillis()也就是系统开机时间减去休眠时间单调递增不受系统改时间影响。这种时间基准保证了延时任务不会被用户调整系统时钟干扰。enqueueMessage里有一行关键代码private boolean enqueueMessage(Message msg, long when) { msg.when when; msg.target this; return msg.target this msg.queue.enqueueMessage(msg, when); }注意msg.target this这一步就是把消息和Handler绑定在一起。这里没有任何业务逻辑的执行sendMessage只是把消息按时间排进队列真正的执行要等Looper把它取出来。很多新手以为sendMessage之后handleMessage立刻就会被调用其实中间隔着一次甚至多次消息循环。3.2 enqueueMessage的插入规则MessageQueue.enqueueMessage()里所有消息按when字段从小到大排序。新消息入队时在synchronized块里从链表头开始找直到找到一条when比新消息大的消息把新消息插到它的前面。这个设计让消息队列天然支持优先级先到期的总是排在前面Looper每次只取头部。即使调用方乱序地sendMessage最终执行顺序依然按时间线严格排列。这里顺带解释一个经典面试题postDelayed和sleep的区别。postDelayed不是让当前线程睡眠而是把任务标记为在某个时间点之后执行到时间之前队列可以先去处理其他消息。而sleep会直接占住线程不让干任何事。理解了when排序规则这个概念就非常自然了。3.3 Looper.loop()的分发动作主线程在ActivityThread.main()里调用Looper.loop()之后就进入一个无限循环public static void loop() { final Looper me myLooper(); final MessageQueue queue me.mQueue; for (;;) { Message msg queue.next(); // 可能阻塞 msg.target.dispatchMessage(msg); msg.recycleUnchecked(); } }queue.next()在没有符合条件消息时会阻塞等待一旦有消息到期就返回队头消息。拿到消息后调用的不是Handler的handleMessage而是msg.target.dispatchMessage(msg)dispatchMessage内部再分三种情况处理如果msg.callback不为空执行这个Runnable这是post系列方法的路径如果Handler构造时设置了mCallback执行mCallback.handleMessage如果都不是执行Handler子类重写的handleMessage。整个过程都在Looper所在的线程里跑。子线程sendMessage主线程handleMessage依赖的正是子线程往队列塞消息 主线程消息循环从队列取消息这条协作链路中间不需要额外的锁去同步业务状态。3.4 post(Runnable)和sendMessage完全是一家人很多开发者觉得post和sendMessage是两套机制其实不是。看Handler.post的源码public final boolean post(Runnable r) { return sendMessageDelayed(getPostMessage(r), 0); } private static Message getPostMessage(Runnable r) { Message m Message.obtain(); m.callback r; return m; }post一个Runnable内部就是创建一条Message把Runnable塞进callback字段再走sendMessageDelayed这条链路。所以post、postDelayed、sendMessage、sendMessageDelayed全部是同一个机制的不同包装。这也是为什么面试里问为什么post可以更新UI本质上回答因为post的消息被主线程Looper取出在UI线程执行了Runnable就够了。4. 主线程的死循环不卡死真正原因是epollHandler相关话题里被问得最多的一个问题是Looper.loop()是个死循环主线程难道不会因此卡死、占满CPU吗这个问题问得很好因为它背后藏着一整套关于阻塞唤醒的机制。4.1 死循环不等于忙等先做个对比。如果循环体是while(true) { int x 1; }CPU会被占满因为每一轮都在做无意义的计算。但Looper.loop()里的循环不一样大部分时间它阻塞在queue.next()这一步——没有消息时就挂起等待不消耗CPU。打个比方你点完外卖坐在家里不是站在猫眼后面死盯着门外一直看那是忙等而是躺在沙发上休息手机响了再起身开门这是阻塞唤醒。Looper只是提供了一个时刻准备接收任务的循环框架真正的等待成本低到可以忽略。4.2 nativePollOnce与epoll让线程进入深度休眠MessageQueue.next()在没有到期消息时会计算一个阻塞超时时间然后调用nativePollOnce(ptr, nextPollTimeoutMillis)。这是一个native方法底层借助Linux的epoll事件机制让当前线程进入休眠状态。等到超时时间到或者有新的消息入队通过nativeWake唤醒它线程才继续工作。这套机制保证了主线程在空闲时是真正在休息CPU占用几乎为零。Android系统几乎所有核心能力——触摸事件、绘制请求、消息分发——都依赖这个epoll模型对外部事件进行统一监听和唤醒。理解了nativePollOnce很多衍生问题也顺了为什么Handler.postDelayed一个任务线程不是一觉睡到时间到而是被提前叫醒判断时间没到又睡回去因为线程需要响应其他消息比如用户突然触摸屏幕。每次被唤醒next()都会重新计算剩余超时时间再继续睡。延时任务的实现本质就是反复比对消息队列的when字段。4.3 真正的ANR并不是死循环造成的这也牵扯出另一个高频面试点既然主线程是死循环为什么还会ANR答案其实不在循环本身而在某个消息的处理时长。系统要求主线程在特定时间内响应关键事件比如触摸事件、绘制、广播。如果某个handleMessage或onClick里做了耗时操作——比如在主线程读数据库、做加密、对大数据排序导致后续事件迟迟得不到处理才会触发ANR。说句实在话Handler切换的是执行线程和任务时序不是并发能力。你往主线程Handler里post一个耗时10秒的任务它照样会卡住主线程。所以正确处理方式是耗时操作仍然放在子线程Handler只负责把结果传回主线程更新UI。5. Handler内存泄漏的根源与三种改造方案如果说原理层面的坑属于面试题那内存泄漏就是实打实的线上事故了。Handler用不好Activity被延迟消息牵住无法回收是Android内存问题里最经典也最容易复现的一类。5.1 泄漏链路Message.target持有HandlerHandler持有ActivityAndroid Studio的Memory Profiler经常能看到这样的堆栈MessageQueue持有MessageMessage持有HandlerHandler非静态内部类持有Activity。对象引用链一旦形成GC就无法回收Activity。最常见的触发场景是postDelayed。比如进入一个页面时postDelayed了一个10秒的延迟任务用户第3秒就退出了。这条消息还安静地躺在MessageQueue的链表里它的target指向HandlerHandler又牢牢拽着Activity的引用。只要消息没被移除Activity就一直处于被持有状态内存泄漏就这么产生了。我之前在一个数据上报模块里踩过这个坑每次页面展示都会post一个延时统计任务用户高频进出页面内存占用肉眼可见地往上走最后靠LeakCanary定位到Handler。排查过程其实不难难的是意识到原来postDelayed未移除也会泄漏。5.2 改造方案一静态内部类加弱引用最通用的修复办法是把Handler定义成静态内部类不隐式持有外部Activity再通过WeakReference去取Activityprivate static class SafeHandler extends Handler { private final WeakReferenceMainActivity activityRef; SafeHandler(MainActivity activity) { activityRef new WeakReference(activity); } Override public void handleMessage(Message msg) { MainActivity activity activityRef.get(); if (activity null || activity.isDestroyed()) { return; } String result (String) msg.obj; activity.textView.setText(result); } }弱引用只是让Activity可以被回收不等于万事大吉。如果延迟消息本身还要在回调里更新UI而Activity已经在后台被回收了回调里的操作就要做好判空处理。否则引用是拿到了却可能触发空指针或无效操作。5.3 改造方案二生命周期终止时及时移除消息不管用不用弱引用我都建议在onDestroy里清掉该Handler的所有消息Override protected void onDestroy() { handler.removeCallbacksAndMessages(null); super.onDestroy(); }removeCallbacksAndMessages(null)会把该Handler关联的所有消息从MessageQueue中移除如果想更精确可以用removeMessages(what)按消息类型移除或者removeCallbacks(runnable)移除指定Runnable。参数传null是不过滤token的意思表示全部清空。有一点要注意onDestroy之后如果Looper已经不在执行移除消息并不会触发任何回调可以放心调用。移除动作本身只是把链表节点摘掉开销很小。5.4 改造方案三让生命周期组件替我们管理现代Android项目如果用了AndroidX Lifecycle还可以借助Lifecycle来统一收尾。例如实现LifecycleEventObserver在ON_DESTROY事件里自动removeCallbacksAndMessages或者干脆把异步结果放到ViewModel里Activity只负责订阅LiveData或Flow。ViewModel会在页面销毁时自动清空从根本上避开Handler持有Activity的问题。我个人在项目里的习惯是简单页面用静态类弱引用 onDestroy移除双保险复杂业务尽量不让Handler直接回调Activity层而是回调到ViewModel或数据层把Handler当成纯调度工具而非业务载体。这样不仅没有泄漏问题代码分层也更干净。6. 从HandlerThread到协程什么时候该换赛道理解了Handler机制之后还有一个实际问题需要回答现在的项目到底该用Handler还是用更新的技术我的看法是Handler作为基础设施远没有过时但要分场景使用。6.1 HandlerThread给子线程一个专用消息循环普通子线程没有Looper无法直接new HandlerHandlerThread正是为这个场景设计的。它是一个自带Looper的Thread适合执行串行的后台任务。典型用法HandlerThread handlerThread new HandlerThread(worker); handlerThread.start(); Handler workerHandler new Handler(handlerThread.getLooper()); workerHandler.post(new Runnable() { Override public void run() { // 在这里执行串行IO、数据库写入等任务 } });HandlerThread最典型的价值在于串行。多个任务post到同一个HandlerThread上会按顺序在后台线程逐个执行天然避免并发争抢。比如批量写数据库、保存日志、处理图片等场景用HandlerThread串行排队非常合适。退出时要特别注意调用的是quitSafely()而不是interrupt()。quitSafely会把队列里所有消息处理完再退出如果调quit()尚未处理的消息会被直接丢弃。我曾经因为在onDestroy里调用quit()导致一个写日志的任务被丢掉排查了好一阵。多线程编程里优雅退出和强制退出的差别在HandlerThread上体现得很真实。6.2 选型对比Handler、线程池、协程到底怎么选方案线程模型适合场景注意事项Handler绑定指定线程的消息循环跨线程投递、延时任务、主线程调度注意移除消息防泄漏HandlerThread单个后台线程 消息循环串行IO、顺序任务队列quitSafely优雅退出Executor / 线程池多线程池化复用并发任务、批量计算线程数要按业务评估Kotlin协程结构化并发异步代码简化、取消协作新项目主流选择如果你的项目已经全面使用Kotlin协程网络请求、数据库操作、业务异步链路都用挂起函数搞定那Handler在业务层的出场机会确实不多。但有两个地方Handler还是绕不开一是任何需要精确切到主线程并排队的场景coroutine的Dispatchers.Main底层也是靠Handler与主线程Looper协作的二是系统层、SDK层、旧代码维护时Handler依然是事实标准。所以它不是被淘汰了而是退到了更底层的基础设施位置。6.3 几个容易被忽视的Handler高级技巧聊到最后分享几个我花了不少时间才搞明白的小技巧在很多源码和项目里都会碰到。第一个是IdleHandler。MessageQueue允许注册一个IdleHandler当消息队列空闲时执行。它非常适合在主线程空闲时做懒加载、预取数据等非紧急操作避免抢占关键任务。用法如下Looper.myQueue().addIdleHandler(new MessageQueue.IdleHandler() { Override public boolean queueIdle() { // 返回true表示继续保留false表示只执行一次 doLazyInit(); return false; } });第二个是同步屏障。MessageQueue里有postSyncBarrier和removeSyncBarrier这对方法设置了同步屏障后队列里的同步消息会被暂时拦住只放行异步消息。Android的Choreographer在收到VSYNC信号渲染下一帧时正是利用同步屏障来保证帧绘制优先于其他普通消息确保界面不掉帧。日常业务代码不建议手动碰同步屏障但理解它有助于解释为什么有时候我post的消息比预期晚或早执行。第三个是Looper.setMessageLogging调试阶段的宝贝。通过给主线程Looper挂一个Printer可以打印每条消息分发前后的时间戳再结合具体的方法耗时快速定位到底哪个handleMessage耗了最多时间这是定位主线程卡顿最直接的手段之一。最后再分享一个我个人的检验方法如果一段代码里同时出现了多个Handler、多个what值我通常会先抽象成一个后台Looper和一个主线程Handler并把消息类型抽成常量或枚举一旦what超过三五个就该考虑用协程或状态机重构了。保持Handler只做调度、不写业务代码会清爽很多。拿不准的时候去源码里把enqueueMessage和dispatchMessage再读一遍比背任何面试八股文都有用。 
长河君 · 2026/10/10 6:17:14 · 阅读 1.2k 从线上崩溃到原理：Handler消息机制与内存泄漏深度解析
我印象最深的一次线上事故发生在一个版本迭代之后。用户在快速滑动列表页时偶现闪退后台监控里堆出大批相同堆栈全部指向某个按钮的点击回调。查了大半天最初的怀疑对象是网络库、图片加载最后才发现问题出在新手同学在子线程拿到结果之后直接调用了textView.setText()。那一刻我意识到Handler用起来简单但为什么必须用它它背后到底做了什么很多人其实没有真正理解。这篇我打算从那次事故讲起把Handler机制底层的Looper、MessageQueue、Message、Handler四个角色完整拆开再结合我多年项目里踩过的坑聊清楚内存泄漏、延迟消息、主线程死循环这些高频问题的根源最后给出选型建议。适合刚入行的同学建立整体认知也适合准备面试、或者想把手头各种postDelayed用得更加稳妥的老开发。1. 一次线上崩溃事故Handler存在的全部理由1.1 崩溃现场还原先还原一下当时的代码。这个场景在今天的新项目里依然普遍存在网络请求放到子线程里执行拿到结果后直接往TextView上更新然后等一个不确定的概率崩溃。很多人第一次遇到这个异常时都会一脸懵写法大概是这样的new Thread(new Runnable() { Override public void run() { String result requestServer(); textView.setText(result); // 直接更新UI } }).start();这段代码在低概率场景下会直接崩报错信息是android.view.ViewRootImpl$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.看到这个异常很多人的第一反应是知道了子线程不能更新UI但很少继续追问Android为什么要这么设计子线程更新个TextView文本到底会出什么大事1.2 View不是线程安全的加锁的代价太大真正的原因是TextView、ImageView这些控件内部维护着大量状态从文本内容到测量结果、布局位置再到绘制缓存。如果多个线程同时在修改同一个View的状态轻则界面显示错乱、绘制撕裂重则触发内存读写异常、直接崩溃。Android官方没有选择给每个View加一把大锁来保住线程安全原因也很简单UI操作集中在主线程加锁的成本高得离谱。一次setText就要去抢一次全局锁所有绘制、触摸事件都会跟着竞争性能会肉眼可见地变差。所以Android做了一个简单粗暴却极其有效的约定谁创建了View树谁才有资格更新它。这个持有者就是主线程。1.3 把更新UI打包成消息交给主线程既然只有主线程能碰UI子线程想把结果告诉主线程就需要一种跨线程投递的机制。Handler就是干这个的private final Handler mainHandler new Handler(Looper.getMainLooper()); new Thread(new Runnable() { Override public void run() { String result requestServer(); mainHandler.post(new Runnable() { Override public void run() { textView.setText(result); } }); } }).start();注意这里的关键点子线程只是把Runnable塞进了一个队列真正执行textView.setText()的人是主线程。所以Handler的本质不是在另一个线程执行代码而是把一段代码切换到指定线程的消息循环里去执行。搞清楚这一点后面所有机制就都好理解了。Handler也不只是UI更新的专用工具任何线程间需要安全地传递一个任务的场合它都是最基础、最通用的方案。2. 四大角色的分工Looper、MessageQueue、Message与Handler要理解Handler绕不开它的四个核心组成部分。很多人看源码时迷失在细节里就是因为没把这几个角色在系统里的职责边界看清楚。2.1 ThreadLocal与Looper一个线程只配一个消息循环Looper是消息循环的执行者负责不断从消息队列里取消息、分发消息。一个线程最多只能有一个Looper这个唯一性靠ThreadLocal保证。ThreadLocal可以简单理解成线程私有的存储空间。同一个ThreadLocal对象在不同的线程里读到的值互不相干。Looper在创建时就保存在ThreadLocal里所以无论代码走到哪只要当前线程有Looper随时都能通过Looper.myLooper()取出来。主线程的Looper是系统在ActivityThread.main()里调用Looper.prepareMainLooper()初始化好的所以我们在主线程里直接new Handler()不会报错。但在子线程里直接new Handler()十有八九会看到这个异常java.lang.RuntimeException: Cant create handler inside thread that has not called Looper.prepare()原因很简单Handler创建时要取当前线程的Looper取不到就只能罢工。想让子线程能收发消息必须先调用Looper.prepare()给这个线程装一个Looper再调用Looper.loop()启动循环。这正是HandlerThread存在的意义后面我会专门讲。2.2 MessageQueue不是队列是一根按时间排序的单链表MessageQueue是存放消息的地方名字里有Queue但底层实现并不是常规意义上的队列而是通过Message.next字段串起来的单链表。为什么用链表而不是数组因为消息的入队是有优先级的——根据期望执行时间when排序。插入一条新消息时需要从头部开始遍历找到第一个when比它晚的节点然后插到它前面。用链表做这种插入非常顺手不需要像数组那样搬移元素。Message本身除了携带用户数据what、arg1、arg2、obj还有两个非常重要的内部字段when表示期望执行时间target指向发送它的Handler。当Looper把消息取出来分发时就是靠target找到对应的Handler再回调到它的handleMessage方法。另外Message还有一个容易被忽略的点它自带消息对象池。标准做法是Message.obtain()而不是new Message()obtain会从sPool里取已经回收的Message复用减少对象创建和GC压力。使用完的消息会通过recycle()回到池子里。这个习惯在消息量大、频率高的场景比如动画回调里效果非常明显。2.3 Handler的双重身份既是投递员也是处理入口Handler在整个机制里承担两类工作对外发送消息对内接收消息回调。发送消息时sendMessage、sendEmptyMessage、post、postDelayed这些方法最终都会走同一条路把Message放进MessageQueue。接收消息时Looper从队列里取出消息调用msg.target.dispatchMessage(msg)再由dispatchMessage决定最终回调到哪里——可能是消息自带的Runnable callback也可能是Handler.Callback当然也可能是我们最熟悉的handleMessage。一张表把这四个角色的职责理清楚角色职责关键点Looper驱动整个消息循环prepare()初始化loop()开始取消息MessageQueue按时间排序存储消息底层是单链表next()会阻塞等待Message携带任务与数据有对象池obtain()复用Handler发送消息 处理消息target字段指向它决定回调归属很多人面试被问Handler、Looper、MessageQueue三者关系答不好其实只要抓住一句话Handler把Message按时间塞进MessageQueueLooper无限循环地从MessageQueue里取消息再交还给Handler自己处理。3. 一条消息的完整旅程从sendMessage到handleMessage前面把角色说清楚了现在沿着源码走一遍看看一条消息从投递到执行中间到底经历了什么。这个过程是理解所有Handler高级问题的钥匙。3.1 sendMessage只是做了排队动作调用handler.sendMessage(msg)后实际的调用链是这样的sendMessage(msg) - sendMessageDelayed(msg, 0) - sendMessageAtTime(msg, SystemClock.uptimeMillis() delayMillis) - enqueueMessage(msg, uptimeMillis)sendMessageAtTime里有个很容易被忽略的细节它取的时间基准是SystemClock.uptimeMillis()也就是系统开机时间减去休眠时间单调递增不受系统改时间影响。这种时间基准保证了延时任务不会被用户调整系统时钟干扰。enqueueMessage里有一行关键代码private boolean enqueueMessage(Message msg, long when) { msg.when when; msg.target this; return msg.target this msg.queue.enqueueMessage(msg, when); }注意msg.target this这一步就是把消息和Handler绑定在一起。这里没有任何业务逻辑的执行sendMessage只是把消息按时间排进队列真正的执行要等Looper把它取出来。很多新手以为sendMessage之后handleMessage立刻就会被调用其实中间隔着一次甚至多次消息循环。3.2 enqueueMessage的插入规则MessageQueue.enqueueMessage()里所有消息按when字段从小到大排序。新消息入队时在synchronized块里从链表头开始找直到找到一条when比新消息大的消息把新消息插到它的前面。这个设计让消息队列天然支持优先级先到期的总是排在前面Looper每次只取头部。即使调用方乱序地sendMessage最终执行顺序依然按时间线严格排列。这里顺带解释一个经典面试题postDelayed和sleep的区别。postDelayed不是让当前线程睡眠而是把任务标记为在某个时间点之后执行到时间之前队列可以先去处理其他消息。而sleep会直接占住线程不让干任何事。理解了when排序规则这个概念就非常自然了。3.3 Looper.loop()的分发动作主线程在ActivityThread.main()里调用Looper.loop()之后就进入一个无限循环public static void loop() { final Looper me myLooper(); final MessageQueue queue me.mQueue; for (;;) { Message msg queue.next(); // 可能阻塞 msg.target.dispatchMessage(msg); msg.recycleUnchecked(); } }queue.next()在没有符合条件消息时会阻塞等待一旦有消息到期就返回队头消息。拿到消息后调用的不是Handler的handleMessage而是msg.target.dispatchMessage(msg)dispatchMessage内部再分三种情况处理如果msg.callback不为空执行这个Runnable这是post系列方法的路径如果Handler构造时设置了mCallback执行mCallback.handleMessage如果都不是执行Handler子类重写的handleMessage。整个过程都在Looper所在的线程里跑。子线程sendMessage主线程handleMessage依赖的正是子线程往队列塞消息 主线程消息循环从队列取消息这条协作链路中间不需要额外的锁去同步业务状态。3.4 post(Runnable)和sendMessage完全是一家人很多开发者觉得post和sendMessage是两套机制其实不是。看Handler.post的源码public final boolean post(Runnable r) { return sendMessageDelayed(getPostMessage(r), 0); } private static Message getPostMessage(Runnable r) { Message m Message.obtain(); m.callback r; return m; }post一个Runnable内部就是创建一条Message把Runnable塞进callback字段再走sendMessageDelayed这条链路。所以post、postDelayed、sendMessage、sendMessageDelayed全部是同一个机制的不同包装。这也是为什么面试里问为什么post可以更新UI本质上回答因为post的消息被主线程Looper取出在UI线程执行了Runnable就够了。4. 主线程的死循环不卡死真正原因是epollHandler相关话题里被问得最多的一个问题是Looper.loop()是个死循环主线程难道不会因此卡死、占满CPU吗这个问题问得很好因为它背后藏着一整套关于阻塞唤醒的机制。4.1 死循环不等于忙等先做个对比。如果循环体是while(true) { int x 1; }CPU会被占满因为每一轮都在做无意义的计算。但Looper.loop()里的循环不一样大部分时间它阻塞在queue.next()这一步——没有消息时就挂起等待不消耗CPU。打个比方你点完外卖坐在家里不是站在猫眼后面死盯着门外一直看那是忙等而是躺在沙发上休息手机响了再起身开门这是阻塞唤醒。Looper只是提供了一个时刻准备接收任务的循环框架真正的等待成本低到可以忽略。4.2 nativePollOnce与epoll让线程进入深度休眠MessageQueue.next()在没有到期消息时会计算一个阻塞超时时间然后调用nativePollOnce(ptr, nextPollTimeoutMillis)。这是一个native方法底层借助Linux的epoll事件机制让当前线程进入休眠状态。等到超时时间到或者有新的消息入队通过nativeWake唤醒它线程才继续工作。这套机制保证了主线程在空闲时是真正在休息CPU占用几乎为零。Android系统几乎所有核心能力——触摸事件、绘制请求、消息分发——都依赖这个epoll模型对外部事件进行统一监听和唤醒。理解了nativePollOnce很多衍生问题也顺了为什么Handler.postDelayed一个任务线程不是一觉睡到时间到而是被提前叫醒判断时间没到又睡回去因为线程需要响应其他消息比如用户突然触摸屏幕。每次被唤醒next()都会重新计算剩余超时时间再继续睡。延时任务的实现本质就是反复比对消息队列的when字段。4.3 真正的ANR并不是死循环造成的这也牵扯出另一个高频面试点既然主线程是死循环为什么还会ANR答案其实不在循环本身而在某个消息的处理时长。系统要求主线程在特定时间内响应关键事件比如触摸事件、绘制、广播。如果某个handleMessage或onClick里做了耗时操作——比如在主线程读数据库、做加密、对大数据排序导致后续事件迟迟得不到处理才会触发ANR。说句实在话Handler切换的是执行线程和任务时序不是并发能力。你往主线程Handler里post一个耗时10秒的任务它照样会卡住主线程。所以正确处理方式是耗时操作仍然放在子线程Handler只负责把结果传回主线程更新UI。5. Handler内存泄漏的根源与三种改造方案如果说原理层面的坑属于面试题那内存泄漏就是实打实的线上事故了。Handler用不好Activity被延迟消息牵住无法回收是Android内存问题里最经典也最容易复现的一类。5.1 泄漏链路Message.target持有HandlerHandler持有ActivityAndroid Studio的Memory Profiler经常能看到这样的堆栈MessageQueue持有MessageMessage持有HandlerHandler非静态内部类持有Activity。对象引用链一旦形成GC就无法回收Activity。最常见的触发场景是postDelayed。比如进入一个页面时postDelayed了一个10秒的延迟任务用户第3秒就退出了。这条消息还安静地躺在MessageQueue的链表里它的target指向HandlerHandler又牢牢拽着Activity的引用。只要消息没被移除Activity就一直处于被持有状态内存泄漏就这么产生了。我之前在一个数据上报模块里踩过这个坑每次页面展示都会post一个延时统计任务用户高频进出页面内存占用肉眼可见地往上走最后靠LeakCanary定位到Handler。排查过程其实不难难的是意识到原来postDelayed未移除也会泄漏。5.2 改造方案一静态内部类加弱引用最通用的修复办法是把Handler定义成静态内部类不隐式持有外部Activity再通过WeakReference去取Activityprivate static class SafeHandler extends Handler { private final WeakReferenceMainActivity activityRef; SafeHandler(MainActivity activity) { activityRef new WeakReference(activity); } Override public void handleMessage(Message msg) { MainActivity activity activityRef.get(); if (activity null || activity.isDestroyed()) { return; } String result (String) msg.obj; activity.textView.setText(result); } }弱引用只是让Activity可以被回收不等于万事大吉。如果延迟消息本身还要在回调里更新UI而Activity已经在后台被回收了回调里的操作就要做好判空处理。否则引用是拿到了却可能触发空指针或无效操作。5.3 改造方案二生命周期终止时及时移除消息不管用不用弱引用我都建议在onDestroy里清掉该Handler的所有消息Override protected void onDestroy() { handler.removeCallbacksAndMessages(null); super.onDestroy(); }removeCallbacksAndMessages(null)会把该Handler关联的所有消息从MessageQueue中移除如果想更精确可以用removeMessages(what)按消息类型移除或者removeCallbacks(runnable)移除指定Runnable。参数传null是不过滤token的意思表示全部清空。有一点要注意onDestroy之后如果Looper已经不在执行移除消息并不会触发任何回调可以放心调用。移除动作本身只是把链表节点摘掉开销很小。5.4 改造方案三让生命周期组件替我们管理现代Android项目如果用了AndroidX Lifecycle还可以借助Lifecycle来统一收尾。例如实现LifecycleEventObserver在ON_DESTROY事件里自动removeCallbacksAndMessages或者干脆把异步结果放到ViewModel里Activity只负责订阅LiveData或Flow。ViewModel会在页面销毁时自动清空从根本上避开Handler持有Activity的问题。我个人在项目里的习惯是简单页面用静态类弱引用 onDestroy移除双保险复杂业务尽量不让Handler直接回调Activity层而是回调到ViewModel或数据层把Handler当成纯调度工具而非业务载体。这样不仅没有泄漏问题代码分层也更干净。6. 从HandlerThread到协程什么时候该换赛道理解了Handler机制之后还有一个实际问题需要回答现在的项目到底该用Handler还是用更新的技术我的看法是Handler作为基础设施远没有过时但要分场景使用。6.1 HandlerThread给子线程一个专用消息循环普通子线程没有Looper无法直接new HandlerHandlerThread正是为这个场景设计的。它是一个自带Looper的Thread适合执行串行的后台任务。典型用法HandlerThread handlerThread new HandlerThread(worker); handlerThread.start(); Handler workerHandler new Handler(handlerThread.getLooper()); workerHandler.post(new Runnable() { Override public void run() { // 在这里执行串行IO、数据库写入等任务 } });HandlerThread最典型的价值在于串行。多个任务post到同一个HandlerThread上会按顺序在后台线程逐个执行天然避免并发争抢。比如批量写数据库、保存日志、处理图片等场景用HandlerThread串行排队非常合适。退出时要特别注意调用的是quitSafely()而不是interrupt()。quitSafely会把队列里所有消息处理完再退出如果调quit()尚未处理的消息会被直接丢弃。我曾经因为在onDestroy里调用quit()导致一个写日志的任务被丢掉排查了好一阵。多线程编程里优雅退出和强制退出的差别在HandlerThread上体现得很真实。6.2 选型对比Handler、线程池、协程到底怎么选方案线程模型适合场景注意事项Handler绑定指定线程的消息循环跨线程投递、延时任务、主线程调度注意移除消息防泄漏HandlerThread单个后台线程 消息循环串行IO、顺序任务队列quitSafely优雅退出Executor / 线程池多线程池化复用并发任务、批量计算线程数要按业务评估Kotlin协程结构化并发异步代码简化、取消协作新项目主流选择如果你的项目已经全面使用Kotlin协程网络请求、数据库操作、业务异步链路都用挂起函数搞定那Handler在业务层的出场机会确实不多。但有两个地方Handler还是绕不开一是任何需要精确切到主线程并排队的场景coroutine的Dispatchers.Main底层也是靠Handler与主线程Looper协作的二是系统层、SDK层、旧代码维护时Handler依然是事实标准。所以它不是被淘汰了而是退到了更底层的基础设施位置。6.3 几个容易被忽视的Handler高级技巧聊到最后分享几个我花了不少时间才搞明白的小技巧在很多源码和项目里都会碰到。第一个是IdleHandler。MessageQueue允许注册一个IdleHandler当消息队列空闲时执行。它非常适合在主线程空闲时做懒加载、预取数据等非紧急操作避免抢占关键任务。用法如下Looper.myQueue().addIdleHandler(new MessageQueue.IdleHandler() { Override public boolean queueIdle() { // 返回true表示继续保留false表示只执行一次 doLazyInit(); return false; } });第二个是同步屏障。MessageQueue里有postSyncBarrier和removeSyncBarrier这对方法设置了同步屏障后队列里的同步消息会被暂时拦住只放行异步消息。Android的Choreographer在收到VSYNC信号渲染下一帧时正是利用同步屏障来保证帧绘制优先于其他普通消息确保界面不掉帧。日常业务代码不建议手动碰同步屏障但理解它有助于解释为什么有时候我post的消息比预期晚或早执行。第三个是Looper.setMessageLogging调试阶段的宝贝。通过给主线程Looper挂一个Printer可以打印每条消息分发前后的时间戳再结合具体的方法耗时快速定位到底哪个handleMessage耗了最多时间这是定位主线程卡顿最直接的手段之一。最后再分享一个我个人的检验方法如果一段代码里同时出现了多个Handler、多个what值我通常会先抽象成一个后台Looper和一个主线程Handler并把消息类型抽成常量或枚举一旦what超过三五个就该考虑用协程或状态机重构了。保持Handler只做调度、不写业务代码会清爽很多。拿不准的时候去源码里把enqueueMessage和dispatchMessage再读一遍比背任何面试八股文都有用。