做Android开发几乎没有人能绕开线程这个话题。我记得第一次在子线程里改TextView就崩了一个CalledFromWrongThreadException直接把我打懵后来把网络请求直接写进onCreate又亲眼看着系统弹ANR对话框。这两个错误几乎是新人必踩的坑根源其实是同一个问题线程间的通信方式不对。这篇我打算把Android线程间通信完整梳理一遍从底层的Looper/Handler机制到日常项目里的几种通信路径再到这些年踩过的内存泄漏、消息积压和死锁之类的坑希望能给出一条可以照着走的路线。1. 为什么Android的线程通信绕不开Handler1.1 主线程的“特权”从哪来UI线程模型与ThreadLocalAndroid应用从启动开始就有一个专门的主线程也叫UI线程。几乎所有UI刷新、输入事件分发、生命周期回调都在这个线程上执行。很多人以为“子线程不能更新UI”只是官方建议其实它是硬性检查底层的ViewRootImpl在执行requestLayout()、invalidate()时会调用checkThread()一旦发现当前线程不是创建ViewRootImpl的线程立刻抛异常。这个机制保证了UI操作不会被多个线程同时修改从设计上避开了一大批加锁同步的复杂度。主线程凭什么能一直处理消息靠的是Looper。应用启动时ActivityThread.main()里会调用Looper.prepareMainLooper()再调用Looper.loop()进入消息循环。这里有个关键点每个线程的Looper互相独立系统用ThreadLocal存储Looper实例保证“一个线程一个Looper”。Handler在创建时会通过Looper.myLooper()绑定当前线程的Looper所以“Handler跟哪个线程绑定”在new出来的那一刻就已经确定了之后你把这个Handler传到任何线程使用消息最终都会回到创建它的那个线程。这个机制初看有点绕但它解释了大量日常现象为什么在主线程new Handler()后在子线程里handler.post(...)就能回到主线程执行因为Handler内部持有的是主线程的Looper和MessageQueue子线程只是把消息丢进队列真正执行还是在主线程的消息循环里。1.2 什么时候必须把线程切来切去主线程要处理绘制和输入任何耗时操作都等于抢占了整个UI的“CPU时间”。典型的必须切线程的场景包括网络请求、大文件读写、图片压缩、复杂JSON解析、批量数据库操作以及任何可能需要几十毫秒以上的计算。Android甚至对部分违规操作做了强制限制网络请求放在主线程会直接抛NetworkOnMainThreadException主线程超过一定时间没有处理输入事件系统会弹ANR对话框。所以真实项目的标准做法很固定耗时操作放工作线程结果回到主线程刷新界面。这个“工作线程计算主线程展示”的需求就是线程间通信最核心的动机。需要注意的是线程间通信并不只是子线程往主线程发消息。有时候主线程也需要往子线程发任务比如让一个后台线程串行处理一批任务避免主线程排队。这种场景通常用HandlerThread配合Handler实现。所以理解Handler体系等于同时掌握了两个方向的通信通道。2. Handler家族三件套Looper、MessageQueue、Message的工作原理2.1 sendMessage之后一条消息究竟走了多远Handler的API看起来很简单sendMessage()或者post()。但底层链路值得拆开看一遍因为很多诡异问题就藏在这条链路上。当你调用handler.sendMessage(msg)时内部其实经过了sendMessage-sendMessageDelayed-sendMessageAtTime-enqueueMessage。enqueueMessage会做两件事把当前Handler设为msg.target然后把消息插入MessageQueue。MessageQueue不是简单队列它内部是一个按触发时间when排序的链表结构越靠前的消息越早被执行。消息入队之后Looper就登场了。Looper.loop()是一个无限循环持续调用queue.next()取消息取到之后调用dispatchMessage(msg)。在dispatchMessage里有个优先级如果消息设置了Callback接口优先执行Callback否则回调Handler的handleMessage。所以post(Runnable)的底层实现其实就是把Runnable包装成带Callback的消息。实际写代码时最常见的正确写法是这样的private val uiHandler object : Handler(Looper.getMainLooper()) { override fun handleMessage(msg: Message) { when (msg.what) { MSG_LOAD_DONE - textView.text msg.obj as String } } } Thread { val result loadFromNetwork() val message uiHandler.obtainMessage(MSG_LOAD_DONE, result) uiHandler.sendMessage(message) }.start()但如果你只是想在子线程跑完任务后更新一下界面用post更省事Thread { val result loadFromNetwork() uiHandler.post { textView.text result } }.start()post看起来不像消息但底层的Runnable一样会被包装成Message走完上面整条链路。2.2 Looper.loop()的死循环为什么不会卡死应用很多人第一次翻开Handler源码时都会困惑主线程不是一直在loop()这个死循环里吗为什么应用还能正常响应为什么不会ANR答案是这个循环大部分时间是“阻塞”的而不是“空转”。MessageQueue.next()在没有下一批到期消息时会调用nativePollOnce()进入native层的等待通过Linux的epoll机制让线程休眠不消耗CPU。这时候线程既不执行代码也不占用资源只是挂在那里等。一旦有新的消息入队或者延迟消息的时间到了native层会唤醒线程继续取消息、分派消息。打个比方餐厅前台服务员坐在柜台前没有客人的时候闭眼打盹听到叫号声才睁眼处理。他确实一直“坐在那里”但不是每秒钟都在忙反而很省力。ANR的真正原因是某一条消息在handleMessage里执行时间太长比如主线程直接做了一次网络请求耗时5秒导致后续所有输入事件、绘制消息全都排着队处理不了系统等不及了才弹ANR。理解这一点对排查问题很重要你看到主线程卡顿不要怀疑Looper循环本身要去查哪条消息的处理函数拖慢了队列。2.3 同步屏障与异步消息UI绘制为什么能插队Handler体系里还有个很多人不知道的机制同步屏障和异步消息。普通消息都是同步消息按时间顺序排队执行但如果此时插入了同步屏障MessageQueue就会跳过这些同步消息只让“异步消息”通过。这个机制被ViewRootImpl用来保证帧绘制优先在每一帧渲染前插入同步屏障拦截所有普通业务消息优先处理Vsync回调等异步消息渲染完成后再移除屏障。所以哪怕主线程消息队列里堆了一堆业务逻辑绘制优先级依然被保护着。日常业务开发里我们几乎不需要手动使用同步屏障但理解它之后你会更清楚“为什么主线程很忙的时候UI可能仍然不卡只是业务消息延迟”这种现象背后的原理。2.4 Message.obtain()与对象池一个容易忽略的性能细节Message对象是可以复用的。每次sendMessage之后消息被处理完系统会调用recycleUnchecked()把它放回对象池下次obtain()时优先从池里取从而减少对象创建和GC压力。所以规范写法是val msg uiHandler.obtainMessage(MSG_LOAD_DONE, result) uiHandler.sendMessage(msg)这比直接new Message()更友好尤其是心跳、进度刷新这类高频率发消息的场景。高频创建Message是一件“看不见但很实在”的浪费积少成多会带来明显的GC抖动。另外还有一个细节handleMessage之后不要把这个Message对象保存下来异步使用。因为消息处理完可能立刻被回收复用里面的字段会被覆盖。如果你要保留内容把需要的字段复制到自己的对象里。2.5 HandlerThread让子线程也拥有消息队列有些场景需要专门的后台线程来处理一连串的任务比如图片批量上传、日志写入。如果每次都新开线程线程开销大还要自己处理排队。HandlerThread的用法就是为子线程初始化Looperval worker HandlerThread(worker) worker.start() val workerHandler Handler(worker.looper) workerHandler.post { doHeavyWork() } workerHandler.post { doAnotherWork() }由于这些任务都进入同一个HandlerThread的消息队列天然就是串行执行的省去了自己维护队列的麻烦。任务都结束后要退出时调用worker.quitSafely()它会等已有消息处理完再停止quit()则会清空队列立即退出按实际需求选择。3. Handler之外的通信姿势四条常见路径的取舍3.1 runOnUiThread和View.post藏在UI框架里的快捷方式runOnUiThread是Activity提供的方法内部其实持有一个主线程Handler。它会先判断当前线程是不是主线程如果是就直接执行否则把Runnable通过Handler投递到主线程队列。所以你在任意工作线程里都能这样写Thread { val data fetchData() runOnUiThread { textView.text data } }.start()View.post也是类似的快捷方式但它有一个额外特性如果View已经attach到窗口Runnable会被投递到View所在的Handler如果还没attachRunnable会先放进一个RunQueue等View attach之后统一执行。这个特性有个很实用的价值你可以在onCreate里对还没完成布局的View执行post等layout完成后再读取宽高得到的尺寸才是有效的。很多人用它来替代ViewTreeObserver的部分场景。这两个方案的好处是轻量、直接适合一次性回调更新UI。缺点是没有任何生命周期管理页面销毁后如果Runnable还是被投递出去了回调依然会执行到时候访问已经销毁的View实例轻则空指针重则内存泄漏。所以只适合简单的临时任务。3.2 AsyncTask曾经的主流现在的反面教材AsyncTask当年火过一阵原因是它把线程池和Handler封装成了一个简洁的“后台任务进度回调”组件。但它的缺点在现代工程实践中被放得很大。问题集中在几个点上。第一AsyncTask不感知Activity或Fragment的生命周期屏幕旋转导致Activity重建时旧实例的回调依然可能执行拿到的是已经废弃的View第二cancel()只是标记状态并不真正中断doInBackground()里的耗时操作取消形同虚设第三执行器的串行/并行策略在历史上反复调整不同版本行为不一致容易踩坑。Android 11之后官方直接标记废弃新项目没有任何理由再去引入它。老项目里遇到AsyncTask我的建议是配合业务重构成协程虽然短期有改动量但长期收益明显。3.3 LiveData数据驱动下的自动切线程LiveData在Android Architecture Components里扮演“可观察数据容器”的角色底层将回调分发和生命周期绑定做掉了。它的线程模型很明确setValue()只能在主线程调用postValue()可以在任意线程调用内部会通过一个主线程Executor把值设置到主线程去分发。典型的配合是“ViewModel LiveData”后台任务更新数据界面观察数据变化// ViewModel层 private val _result MutableLiveDataString() val result: LiveDataString _result // 后台线程里计算完毕 _result.postValue(data) // Activity层观察 viewModel.result.observe(this) { textView.text it }observe()传入的是LifecycleOwner这样当页面不在STARTED状态时LiveData不会分发更新页面销毁后观察自动移除天然规避了“回调到已销毁页面”的问题。这比纯Handler优雅得多。但LiveData也不是没有坑。postValue()在连续快速调用时只保留最新值中间的更新可能被合并掉如果你用它展示进度条的每一帧进度会跳变。另外LiveData有“粘性事件”的特性注册观察者时会立刻收到之前保存的旧值用来做一次性提示时很别扭。这些都需要在设计事件流时考虑清楚。3.4 协程现代项目里更从容的通信姿势协程在Android开发里的核心价值不是“快”而是“结构清晰”。一个常见的写法是lifecycleScope.launch { val data withContext(Dispatchers.IO) { fetchData() } textView.text data }withContext(Dispatchers.IO)让耗时逻辑切到IO线程执行执行完自动回到原来的调度器这里是主线程然后继续更新UI。整个过程代码是顺序写的没有回调嵌套也没有手动切换线程的Handler样板代码。协程更厉害的是结构化并发lifecycleScope会在当前页面销毁时自动取消所有子协程网络请求和回调不再越过页面生命周期。相比在onDestroy里手动移除Handler消息、手动解除观察者协程把这些清理操作内置了。需要并行处理时又可以用async/await避免把线程池调度写成面条代码。要说明的是协程在主线程的调度底层本质还是依赖Handler或Choreographer它并不是凭空砍掉了消息队列而是用更高层的编程模型把“线程切换”变成了上下文自动处理让开发者更专注于业务本身。4. 真实项目里的选型对照与踩坑复盘4.1 按场景选方案的速查表下面这张表是我在项目里实际用下来的选型原则不是理论上的“谁更好”而是“什么场景用什么更不容易出错”。业务场景推荐方案不推荐方案原因子线程计算完刷新单个控件runOnUiThread/View.postAsyncTask轻量、临时无需引入额外机制后台串行任务队列HandlerThread Handler裸Thread 自行维护队列HandlerThread自带消息队列和串行保证页面状态数据观察和分发LiveData / StateFlowHandler手动维护观察者列表生命周期感知自动清理复杂并发任务、依赖关系协程async/awaitHandler硬编码多个消息状态结构化并发、取消、异常处理都更完整维护老项目Handler / runOnUiThread大规模重写减少回归风险逐步替换任何新代码协程 / LiveDataAsyncTask已废弃生命周期问题无解选型的关键不是“哪个更高级”而是“哪个让你在三个月后还能看懂并维护”。我个人现在的组合是底层后台任务优先协程页面状态用LiveData或Flow少量老代码继续用Handler不动。4.2 内存泄漏Handler持有Activity的经典事故Handler相关内存泄漏大概是线程通信里出现频率最高的问题。它的链路是这样的主线程Looper持有MessageQueueMessageQueue里延迟消息持有target即Handler这个Handler如果是匿名内部类就会隐式持有外部Activity。于是页面退出后只要延迟消息还没被处理整条引用链就不会断Activity无法被回收。模拟项目X里我处理过一个典型的轮询页面它每3秒通过postDelayed刷新一次价格退出页面时只取消了网络请求没移除消息。反复进出之后内存检测工具上报了Activity泄漏定位时看的正是这条引用链。修复方式也很常规改成静态内部类Handler配合WeakReference持有Activity并在onDestroy里加一行override fun onDestroy() { handler.removeCallbacksAndMessages(null) super.onDestroy() }如果页面里同时有多个消息可以精确点用removeMessages(what)避免误删其他消息。如果用的是lifecycleScope则连清理这一步都省了协程会在销毁时自动取消。4.3 消息积压、postDelayed不准与removeCallbacks时机Handler的消息虽然是按触发时间排序的但排序只决定“顺序”不保证“准时”。如果主线程正被一条耗时消息占着排在后面的消息即使已经到点也只能等。所以postDelayed绝不能用来做倒计时或者要求精确定时的动画补偿它只是“大概在这个时间之后执行”。要精确计时用协程的delay()加上取消或直接用系统自带的Chronometer。另一个常见问题是轮询任务清理时机放错。我见过有人把removeCallbacks放在onPause里结果页面被对话框遮挡时轮询也被停了恢复后忘了重启数据就一直不刷新。如果你确实需要在不可见时停掉轮询建议把移除放在onStop再在onStart里重新post这样和页面可见性对齐不容易出现“看不见了还在轮询”或者“回来了却不轮询”的错位。线程通信用多了还会遇到一个隐蔽的坑同一个Runnable对象重复post多次。Runnable被包装成Message时会被直接放进队列如果同一个Runnable同时存在多个消息引用后面的处理顺序会变得难预测。遇到需要“先取消再启动”的轮询任务正确姿势是先removeCallbacks(runnable)然后再postDelayed(runnable, delay)。4.4 主线程等待子线程导致的死锁与ANR这种问题比内存泄漏更隐蔽。经典场景是主线程用一个CountDownLatch等待子线程完成而子线程执行完后又通过Handler把结果投回主线程。看起来没什么问题但仔细推演就发现主线程阻塞在await()上根本没有机会处理消息队列里的回调消息而子线程又在等主线程处理完这个消息之后才放行两边互相等直接ANR。类似的情况还有主线程调用Thread.join()等待某个线程结束而该线程又依赖主线程执行某段代码。只要出现“主线程阻塞等待 子线程间接依赖主线程”的组合就基本是死锁。规避方法只有一个任何情况下都不要在主线程里阻塞等待其他线程的结果。需要结果就直接用回调或协程挂起让主线程继续运转等结果出来再回来处理。举例来说错误写法是这样// 错误示例主线程死等子线程结果 val latch CountDownLatch(1) Thread { result fetchData(); latch.countDown() }.start() latch.await() textView.text result一旦fetchData()本身需要回主线程处理这个等待就会卡死。协程的正确写法则是// 正确示例用协程挂起替代阻塞等待 lifecycleScope.launch { val result withContext(Dispatchers.IO) { fetchData() } textView.text result }主线程没有被阻塞子协程在IO线程执行完成之后自动回到主线程更新UI整个过程没有任何互相等待。4.5 每次写线程通信前我会先问自己几个问题写多了之后我形成了一个习惯每次要在一段代码里做线程切换之前先过一遍这几个问题。第一这个回调真的需要切到主线程吗如果只是修改内存中的某个状态不涉及View完全可以在后台线程直接做。第二这个回调跟生命周期绑定吗页面销毁后它会不会继续执行如果会就该用协程或LiveData这类能自动取消的方案而不是裸Handler。第三消息频率高不高高频率场景优先合并最新值或者用协程的Flow做防抖不要一条条往主线程塞。第四排查延迟问题时先看主线程哪条消息耗时长再考虑队里消息多不多不要把锅直接扣到Handler头上。排查线程通信问题我还会打开Android Studio的Profiler看主线程消息耗时通常能直观看到卡顿前有某条消息执行了数百毫秒。这时候再去翻代码定位是哪个具体操作堵住了队列比漫无目的地加日志有效得多。线程通信本身不难真正难的是在真实项目里保持克制和清晰让每条消息都有明确的目的地也让每个回调都有确定的生命周期。
坑你了)
