为什么不能在子线程中直接更新 UI？Handler 是如何解决这个问题的？
解读
国内面试场景里，这道题几乎必问，因为它同时考察“线程模型”与“消息机制”两大核心。面试官想确认三点：
- 你是否真的遇到过 ANR 或 crash，而不是背八股；
- 你能否把“线程安全”“视图刷新”“VSYNC 信号”串成一条线；
- 你能否把 Handler、Looper、MessageQueue、Choreographer 说成一个闭环，而不是只背“Handler 用来发消息”。
答得太浅（只说“Android 规定”）会被追问源码；答得太深（直接锁 ViewRootImpl 的 WMS 调用）又容易把面试官绕晕。因此，给出“现象→根因→机制→落地”四段式最合适。
知识点
- UI 单线程模型：ViewRootImpl 在创建时把 mThread 设为所在线程，checkThread() 强制后续操作在同一线程。
- 屏幕刷新依赖 VSYNC 信号，Choreographer 接收后必须在主线程回调，否则帧节拍错乱。
- View 层级状态（layout、measure、draw）不是线程安全设计，并发读写会产生 Race Condition。
- 子线程直接 setText 或 invalidate 会触发 ViewRootImpl#checkThread() 抛出 CalledFromWrongThreadException。
- Handler-Looper-MessageQueue 构成主线程消息泵；子线程通过 Handler.post/ sendMessage 把 Runnable/Message 插入主线程 MQ，主线程空闲时取出执行，从而把刷新任务序列化到主线程。
- 衍生方案：View.post()、Activity.runOnUiThread()、AsyncTask（已废弃）、HandlerThread、Kotlin Coroutine with Dispatchers.Main，本质都是往主线程 MQ 塞任务。
答案
“不能在子线程直接更新 UI”是 Android 自 1.0 就定下的线程安全红线。
核心原因是：
- View 层级无锁保护，measure、layout、draw 三步状态机不是并发安全设计；
- 屏幕刷新节拍由 Choreographer 接收 VSYNC 信号，必须在主线程串行执行，否则帧节拍错乱，出现掉帧甚至花屏；
- ViewRootImpl 在 addView 时把 mThread 绑定到创建线程（即主线程），每次 requestLayout/invalidate 都调用 checkThread()，若线程不一致立即抛出 CalledFromWrongThreadException，防止潜在崩溃。
Handler 解决思路是“任务序列化”：
子线程持有主线程 Looper 创建的 Handler，通过 post(Runnable) 或 sendMessage() 把刷新任务封装成 Message，插入主线程的 MessageQueue；主线程在 Looper.loop() 中循环取出消息，在 VSYNC 到来时统一执行，既保证线程安全，又保持 16 ms 帧率。
落地时我们常用 Activity.runOnUiThread() 或 view.post()，它们内部同样是向主线程 Handler 发消息，属于语法糖。
拓展思考
- 如果在子线程先拿到 View 的锁再更新是否可行？——不可行，ViewRootImpl 的 checkThread() 在 Java 层提前拦截，根本走不到 native 锁。
- SurfaceView 与 TextureView 为什么可以在子线程绘制？——二者拥有独立的 Surface，绕过 View 层级，直接由生产者——消费者队列把图形缓冲区送 SurfaceFlinger，不经过主线程 Choreographer，因此是官方认可的“子线程刷新”特例。
- Kotlin Coroutine 的 Dispatchers.Main 是否比 Handler 更高效？——底层仍依赖 Handler，只是用队列合并 + 事件批处理减少一次 post，性能差异在百微秒级，但代码可读性大幅提升。
- 主线程 Looper 被阻塞时，子线程 post 的任务还能执行吗？——不能，会一起卡住，所以主线程任何同步 I/O、死锁、密集循环都会直接导致 ANR，监控工具如 ANR-WatchDog、BlockCanary 就是通过子线程定时 post 心跳来检测。