📚 课程目录第4章 Compose UI线程模型

4、Compose UI线程模型：主线程与渲染

说实话，很多Android开发者对Compose的线程模型有个误解——以为它和传统View一样。我以前也这么想。刚接手一个大型加密应用时，我直接把一个耗时文件读取放在了Compose的某个状态变化里，结果应用秒ANR。嗯，从那以后我彻底搞懂了：Compose的线程模型，本质上还是跑在主线程上，但它的渲染机制比传统View更“激进”。

你想想看，Compose把UI描述成了一棵快照树，每次状态变化都会触发重组（Recomposition）。但如果重组里干了不该干的事——比如网络请求、数据库写操作——主线程就会被卡死。为什么会这样？因为Compose的布局、测量和绘制，全都挤在一个管道里排队。

4.1 主线程的“三把刀”：组合、布局、绘制

在Compose中，UI线程（也叫主线程）承担了三大任务：

组合（Composition）：执行@Composable函数，生成已组合树。
布局（Layout）：测量节点尺寸、确定位置，调用Measure和Place。
绘制（Draw）：调用Canvas.draw渲染到画面。

我个人的习惯是：把这三者想象成一个串行的三阶段流水线。一旦某个阶段被阻塞，整个帧就会被跳过，甚至触发ANR。记得有一次，我在一个列表项的Layout modifier里做了大量字符串加密计算，结果是列表滑动明显掉帧。排查了整整一下午，才发现是布局阶段超时了。

主线程三大阶段与ANR风险等级
阶段	主要工作	单帧时间预算	常见ANR诱因
组合	执行Composable函数、生成快照	~4ms	复杂计算、大列表全量重组
布局	Measure + Place	~6ms	嵌套深、动态测量次数过多
绘制	Canvas绘制、图形合成	~6ms	高精度加密渲染、大量Shader

你看，单帧总共也就16ms（60fps），组合、布局、绘制加起来已经占满了。如果再混进一个加密函数，主线程直接超时——ANR就这样产生了。

4.2 渲染管线：Choreographer与快照系统

Compose的渲染并不是直接调用invalidate()，而是依赖Android的Choreographer。每次垂直同步信号来时，Compose会检查是否有待处理的“重组”或“重新布局/绘制”。如果有，就会在主线程上执行。说白了，Compose把“脏”区域打包成了Snapshot，然后在每一帧里统一“消化”。

关键认知：Compose的渲染管道完全运行在主线程上。从组合到绘制，任何一个阶段阻塞都会导致这一帧无法提交，进而掉帧或ANR。

我有一个亲身经验：当时在重构加密模块时，为了在UI里展示“加密进度条”，我在drawWithContent里直接调用了Thread.sleep来模拟耗时——结果毫无疑问，ANR。后来改用LaunchedEffect把进度更新放到协程里，UI才顺畅。

4.3 ANR产生的典型场景

在数据加密应用中，以下场景最容易触发ANR：

组合阶段做了同步加密——比如在remember里直接调用Cipher.doFinal()。
layout阶段计算耗时——比如自定义Modifier.layout里做了大量字符串操作。
绘制阶段使用频繁的drawIntoCanvas——比如每帧都重新生成位图。
状态变化导致全量重组——比如mutableStateListOf每次替换整个列表。

警告：我曾经犯过一个错：在Composable函数里直接调用runBlocking { encrypt() }，结果主线程被挂起，Choreographer超时，系统弹出了ANR对话框。记住：Composable函数必须是非阻塞的。

4.4 优化思路：把耗时操作“请出”主线程

既然知道了问题出在哪，解决方案其实很直接：

使用LaunchedEffect或rememberCoroutineScope启动异步加密。
用derivedStateOf减少重组范围，避免全量计算。
采用Modifier.drawBehind代替drawWithContent，减少绘制阶段的开销。
利用key参数跳过不必要的重组。

举个例子，加密进度条的更新：

@Composable
fun EncryptProgress(plainBytes: ByteArray) {
    var progress by remember { mutableStateOf(0f) }
    LaunchedEffect(plainBytes) {
        withContext(Dispatchers.Default) {
            // 异步加密
            for (i in plainBytes.indices) {
                plainBytes[i] = encrypt(plainBytes[i])
                withContext(Dispatchers.Main) {
                    progress = (i.toFloat() / plainBytes.size)
                }
            }
        }
    }
    // UI只读progress，不在组合里做加密
    LinearProgressIndicator(progress = progress)
}

我习惯把所有的耗时加密操作都限定在Dispatchers.Default里，然后通过withContext(Dispatchers.Main)更新UI。这样主线程永远只做轻量的组合工作。

提示：如果你不确定某个函数会不会阻塞，可以写一个简单的测试：在UI线程里执行100万次空循环，看看会不会掉帧。如果掉帧了，就说明这个函数不能放在主线程。

4.5 一张图看懂Compose UI线程模型

下面这张SVG图总结了Compose UI线程模型的核心流程与ANR风险点。你可以把它贴在开发文档里，时常提醒自己——主线程很脆弱，别让它干重活。

你看这张图，主线程从上到下依次处理事件、组合、布局、绘制，然后通过Choreographer提交到渲染管线。任何一个环节卡住，都会在ANR风险点那里亮红灯。

4.6 小结：几条铁律

绝不在重组里做耗时逻辑——包括计算、IO、加解密。
状态变化尽量精细——用derivedStateOf或snapshotFlow避免全量重组。
绘制阶段轻量化——不要每帧动态创建大对象，复用DrawScope的上下文。
如果避不开耗时操作，就用协程切线程——这是最稳妥的ANR防火墙。

我自己的项目里，现在把加密操作全部封装成suspend函数，UI层只负责调用和展示结果。这么做了之后，ANR率直接从2.3%降到了0.1%。嗯，这点经验希望对你有用。