Jetpack Compose重组优化指南：原理、问题与实操

做了几年 Jetpack Compose 开发我对这门 UI 框架的评价一直在“真香”和“头大”之间反复横跳。真香的是写界面确实爽状态一变界面自动跟着更新再也不用写一堆 findViewById 和 setText头大的是一旦页面出现性能问题尤其是滚动列表掉帧、局部 UI 频繁闪烁你面对的往往是一个叫“重组”Recomposition的黑盒看不清摸不透调试起来全靠猜。这篇文章想聊的正是 Compose 基础里的核心课题重组优化。它解决什么问题简单说Compose 声明式框架在状态更新时会重新执行部分 Composable 函数来生成新 UI但有时候这个“重新执行”的范围和频率远超你的预期导致大量无谓计算卡顿随之而来。重组优化就是让你在理解框架更新机制的基础上用最合理的方式把重组范围约束到最小、把重复计算压缩到最低。无论你是刚开始接触 Compose 的 Kotlin 新手还是已经在生产环境里踩过坑后来想搞清楚“为什么这么卡”的进阶选手这篇文章都值得你从头读完。后面我不会只给结论而是会从原理讲到实操把最容易踩坑的几个场景和对应的优化手段一次说透。1. 重组是怎么发生的先搞懂 Compose 的更新机制1.1 从“改控件”到“描述状态”的思维切换传统 View 体系里我们要更新界面得手动拿到控件引用再操作它比如 textView.text newValue或者 listView.notifyDataSetChanged()。这是命令式你一步一步告诉系统“干什么”。Compose 反过来是声明式你只需要写出“UI 长什么样”然后告诉它“当前状态是什么”剩下的事交给框架。这个转变听起来简单但实际写代码时很多人的脑子还没转过来。写 Compose 时我们写的不是控件而是一个个可组合函数比如Composable fun Counter() { var count by remember { mutableStateOf(0) } Text(text 当前计数: $count) Button(onClick { count }) { Text(加一) } }这段代码里count 是一个被 Compose 观察的 State。当 count 变化时Compose 不会重新创建整个 Activity也不会重新执行所有函数而是找到哪些地方读取了 count只把那些地方标记为“需要重新执行”。在示例里读取 count 的是 Text 函数所以 Text 会重组Button 大概率不会跟着动。这就是声明式框架的聪明之处状态驱动 UI更新范围自动收缩到“读了这个状态”的最小单元。但这个“最小单元”到底有多小很多时候取决于你的代码结构而这正是重组的第一个关键知识点。1.2 组合、重组与“跳过”到底是怎么工作的说重组之前先得说组合Composition。组合是 Compose 在首次执行 Composable 函数时构建的一棵 UI 树Compose 编译器会为每个函数插入专门的 group 标记运行时把这些信息记录在 Slot Table 里。当某个 State 变化Compose 会在 Slot Table 中找到读取该 State 的 group把它标记为 invalid。然后在下一帧的 recomposer 驱动下只重新执行这些被标记的 group 对应的函数体。但这里有个容易被忽略的机制重组不是直接判断“这个函数上一步的输出和下一步是否一样”而是先检查这个函数的参数有没有变化。如果参数没有变化并且编译器认为这个函数是“可跳过”的skippableCompose 就会直接跳过对整个函数体的执行。这就是“跳过”Skip机制。可跳过的条件有三个函数参数稳定、参数值没有变化、编译器允许它生成跳过逻辑。如果任何一个条件不满足哪怕你只修改了一个跟这个函数毫无关系的状态只要父级重组了这个函数也会老老实实重新执行一遍。所以理解重组的关键不只是知道“哪些函数会被重新执行”更要理解“哪些函数本来可以跳过却被硬生生拉了进来”。1.3 重组不等于重绘但也不是免费的午餐很多新手会有个误解认为重组就是重绘没事。重组确实不是重新走一遍测量和绘制流程它只是重新执行函数代码生成新的 UI 描述然后由 Compose 的 diff 逻辑找出差异并更新真实布局。但这不代表重组没有成本。重组要付的代价至少有三块函数体本身的计算时间、Slot Table 的更新和 diff 时间、以及新产生对象对垃圾回收的压力。如果函数体里只是拼几个 Text那问题不大但如果函数体里做了集合排序、字符串拼接、从数据库查数据、甚至是创建 Bitmap 之类的重活即使最终 UI 结果和上一帧一模一样这些计算也全部白付了。一个很典型的例子Composable fun ArticleList(articles: ListArticle) { Column { articles.sortedBy { it.publishTime }.forEach { article - ArticleItem(article) } } }每次父组件重组即使 articles 引用没变只要这个函数被重新执行sortBy 就会重新跑一遍。碰到列表很大的时候性能直接肉眼可见地崩。所以要优化重组不只是减少重组次数还要把函数体里的“重活”搬走、缓存起来。判断一个重组好不好要看它“干了多少活”而不只是它“被调用了多少次”。2. 哪类代码最容易引发无谓重组高频踩坑现场2.1 不稳定参数让跳过机制直接失效前面说了跳过的前提是参数稳定且值没变。那什么算稳定Compose 编译器有一套自己的判断规则基本类型Int、Long、Float 等和 String 是稳定类型带 val 且没自定义等于方法的类如果编译器能证明所有属性不会变化才会被判定为稳定。反过来var 类型的类、interface 类型、没有生成 equals 的普通 class都极有可能被判定为不稳定。不稳定的含义是编译器不敢保证“两次传入的对象在内容上是否相等”于是稳妥起见每次父级重组都当子级参数变了子级无法跳过。比如class User(var name: String)这种类编译器几乎必然是 unstable。哪怕你把同一个 user 对象传进子组件父组件每次重组子组件都会老老实实重新执行一遍。列表里放一百个这样的 item父级一刷新一百个 item 全部重组卡顿就是这么来的。解决思路有两个要么把 var 改成 val让类的属性不可变要么给类加上 Immutable 或 Stable 注解手动告诉编译器“这个类型的实例只要引用没变内容就不会变”。但注意加注解是承诺不是魔法如果注解的类内部实际是可变的导致跳过后 UI 没更新那是比卡顿更严重的 bug。2.2 lambda 的“每次新建”陷阱Compose 里特别喜欢传 lambda比如 onClick { ... }onValueChange { ... }。lambda 本身是对象每次代码执行到 lambda 表达式的位置都会创建一个新的 lambda 实例。对普通 Kotlin 代码这顶多算一点分配开销但在 Compose 重组优化里这个问题会被放大。看这个例子Composable fun Screen() { Box { Child(onClick { doSomething() }) } }Box 重组时onClick 的 lambda 是重新创建的也就是说传给 Child 的参数在上一次和这一次之间永远不相等Child 永远不满足跳过条件。哪怕 doSomething 的逻辑根本没变Child 也会每次都重组。解决办法是把 lambda 缓存到 remember 里val onClick by remember { mutableStateOf { doSomething() } }或者更简单如果你不需要捕获会变化的值直接在外面定义成函数引用。如果 lambda 需要读取最新状态可以用 rememberUpdatedState 来包装。这个后面详细讲。2.3 状态放得太靠上改一个字段整个页面跟着动状态提升是 Compose 的推荐做法但“提升到哪里”很有讲究。很多人习惯把所有状态都放到顶层 Composable 里然后一层层往下传。这样做代码是简单了但状态一旦变更所有读取了该状态的下游组件都会被标记为无效一个输入框敲一个字页面所有区域全部重组。举个例子一个页面有搜索框、筛选栏、结果列表。如果你把 keyword 和 filter 两个状态都放在 Page 层那么打字时 keyword 变化筛选栏和结果列表虽然没用 keyword但它们传参里可能包含同一个 Data 类而 Data 类包含 keyword 字段筛选栏也读了这个 Data于是也跟着重组。优化方向是状态下沉。能放到子组件的状态就放到子组件内部只有真正需要多个组件共享的状态才提升到公共父级。而且尽量让状态按“用途”拆分别搞一个超级大状态包罗万象。写代码的时候多问一句这个状态被修改时有多少组件其实根本不需要知道2.4 集合与可变数据的引用变化陷阱Compose 跳过机制判断参数是否变化用的是 equals 或依赖稳定性。如果你传进去的是接口类型 List 而实现类是一个 MutableList那么编译器会认为这是不稳定的因为接口无法证明实现是不可变的每次父级重组子级都无法跳过。另一个更隐蔽的问题是用 mutableStateList 或者复制集合时产生的引用变化。比如var items by remember { mutableStateOf(listOf(1, 2, 3)) } fun addItem() { items items 4 // 新 list 引用 }这是正确的写法因为 items 是 State必须赋新的不可变 List 才能驱动重组。但有人会图省事用 MutableListval items remember { mutableStateOf(mutableListOf(1, 2, 3)) } items.value.add(4) // 改了内部内容但引用没变这个时候依赖 items.value 的组件不会收到重组通知因为 Compose 观察的是 State 的 value 引用变化而不是 List 内部结构变化。轻则认为“怎么界面不刷新”重则在列表场景出现数据错乱。所以集合类的正确姿势是用不可变集合 新引用赋值或者用 SnapshotStateList 并只把它直接传给可观察的宿主函数。2.5 动画和高频状态更新时的“连锁反应”动画是重组的重灾区。每帧动画都会更新某个 State如果这个 State 被读在父级组件里那么父级和它下面的所有没有跳过的子组件都会一帧一帧地重组。很多人写动画时习惯把动画值传到很深层的组件里或者在动画回调里做一些额外操作导致本来只需要变化几个像素的透明度重算了整个页面。我的经验是动画值尽量只读取在真正需要变化的那个最小组件里千万别在顶层把动画值拿来拼字符串或者做计算也不要让动画回调里直接 update 一个高层级状态除非这个状态本身就是动画的目标。3. 优化实操五个性价比最高的手段3.1 remember把昂贵计算和对象缓存起来remember 是 Compose 里最基础的缓存工具。它的作用是在组合期间记住某个值下次重组时如果 key 没有变化直接返回上一次的计算结果不再重新执行计算逻辑。基础用法Composable fun HeavyScreen() { val sortedList remember(articles) { articles.sortedBy { it.publishTime } } // 后续直接使用 sortedList }上面这段只有当 articles 引用变化时sortBy 才会重新执行。如果 articles 没变就算这个组件因为其他原因重组了sortedList 直接用缓存compute 成本变成零。还有更进阶的用法remember 里不只是缓存计算结果还可以缓存任何对象包括 lambda、集合、甚至是某个业务类的实例。对于 lambda 的优化最常见的就是val onClick remember { { name: String - viewModel.loadUser(name) } }这样点击事件 lambda 实例只创建一次子组件收到的参数稳定跳过机制可以正常工作。3.2 derivedStateOf把高频状态的推导结果合并成低频derivedStateOf 专门用来处理“一个高频变化的状态推导出一个低频使用的值”的场景。典型例子是列表滚动onScroll 每帧触发但页面顶部的标题可能只需要在列表滚动到某个临界点时改变。Composable fun MyList() { val listState rememberLazyListState() val showTitle by remember { derivedStateOf { listState.firstVisibleItemIndex 0 } } if (showTitle) { Text(顶部标题) } }这里的原理是derivedStateOf 会做一次“降频合并”它会重新计算你给的 lambda只有当计算结果和上一次不一致时才会触发依赖它的组件重组。而计算时会读取 listState所以当 firstVisibleItemIndex 从 0 变成 1 时showTitle 从 false 变 trueText 才加入组合。但如果 firstVisibleItemIndex 一直变化比如从 1 滚到 100showTitle 始终保持 true就不会触发不必要的重组。有个容易踩的坑derivedStateOf 的计算 lambda 里不要读过多的状态也不要在这个 lambda 里做重计算。它本质上还是会在每次源头状态变化时重新执行 lambda只是不触发重组并不是完全免费。3.3 key主动给子组件一个身份标签有时候我们就是想让某个子组件在特定条件变化时“从头开始”比如用户切换 Tab 后重置列表位置或者搜索关键词变化后重写结果。用 key 就能实现Composable fun SearchResult(keyword: String) { key(keyword) { // 这块内容在 keyword 变化时会被强制重新组合 ResultList(keyword) } }key 的底层逻辑是它会改变组合树中该位置 group 的身份当 key 值变化时Compose 会把旧 group 销毁、新 group 创建。这样既保证了 UI 状态完全重置也避免了乱七八糟的复用错乱。key 最常见的应用场景是 LazyColumn 的 item 设置 keyLazyColumn { items(items list, key { it.id }) { item - ItemRow(item) } }给定稳定的 key 后LazyColumn 在列表变化时可以精准地复用和重排子组件而不会因为索引变化导致整列重组。我见过不少卡顿和 UI 闪烁问题最后都是加了个 key 解决的。3.4 Immutable 与 Stable跟编译器签一份“稳定性契约”前面提到编译器对稳定性有自己的判断但偶尔会误判。比如一个数据类明明所有属性都是 val但编译器因为某个泛型类型的原因判断不完全稳定。这时可以手动声明稳定性。Immutable data class User( val name: String, val age: Int )Immutable 表示这个类型所有属性都不可变一旦对象创建内容永远不会改变。Stable 更宽松一些表示“即使改变Compose 也能通过 equals 正确判断”或者虽然内部有可变属性但只要引用不变内容就不变。这两个注解属于“承诺型”优化。加了注解之后编译器会降低对这个类型的不稳定判断子组件更容易被跳过。但一旦违约比如加了 Immutable 的类里偷偷改属性结果就是 UI 不刷新排查起来比卡顿还要命。所以基本原则是只在确信类是不可变的时候用而且要配合单元测试保证不可变性。3.5 rememberUpdatedState给 lambda 一个最新鲜的做菜配方rememberUpdatedState 是专门为“创建一次 lambda但要读取最新状态”的场景准备的。典型场景是你有一个长时间运行的协程或动画它的 lambda 里要读取某个状态的最新值但你又不想因为状态变化而重新创建 lambda。Composable fun LongRunningTask(currentValue: String) { val updatedValue by rememberUpdatedState(currentValue) LaunchedEffect(Unit) { while (true) { delay(1000) Log.d(TAG, 当前值: $updatedValue) } } }LaunchedEffect(Unit) 里的协程只会启动一次如果你直接读 currentValue读到的永远是第一次的值。用 rememberUpdatedState 包装后协程体内读取 updatedValue 时每次循环都会拿到最新的值而且这个 lambda 本身不会触发重组。这个工具另外一个用途就是前面说的 lambda 缓存val latestCallback by rememberUpdatedState(onUserClick) val onClick remember { { latestCallback(user) } }onClick 只创建一次但调用时执行的是最新的 onUserClick完美兼顾跳过和新鲜度。4. 怎么验证优化效果工具、指标与问题排查4.1 Compose Compiler Metrics直接看参数稳定性和跳过能力优化的第一步是知道自己的代码里哪些 Composable 是 stable、哪些是 restartable、哪些是 skippable。官方提供了 Compose Compiler Metrics在构建时生成一份报告里面会有每个 Composable 的稳定性判定。在 Gradle 配置中开启kotlinOptions { freeCompilerArgs listOf( -P, plugin:androidx.compose.compiler.plugins.kotlin:metricsDestination project.buildDir.absolutePath /compose_metrics ) }生成后打开文本报告能看到类似这样的信息restartable skippable scheme[androidx.compose.ui.UiComposable] fun ArticleItem( stable article: Article )这个定义表示 ArticleItem 是 restartable 且 skippable 的参数 article 是 stable。如果你的类里出现了 unstable 字样那就要关注了。我一般会定期跑一次 metrics 报告发现 unstable 的传参再逐一修正比靠肉眼读代码高效得多。4.2 Layout Inspector 里的重组计数直接看现实运行表现光看静态报告还不能完全反映运行时性能。Android Studio 自带 Layout Inspector可以在真机或模拟器上直接查看当前组合树中每个组件重组的次数。操作步骤不复杂运行 App点击 Layout Inspector 窗口中的 “Show Recomposition Counts” 图标没有的话需要从工具栏打开 Composition 分析面板然后手动与界面交互观察哪个组件计数异常高。这里的判断标准是正常的少量交互下重组次数不应该疯狂增长。如果点一次按钮某个组件计数暴涨几百次或者滚动列表时所有 item 计数都在飙升说明该组件及其兄弟节点没有正确跳过。这个工具结合前面的稳定性报告基本能把大多数问题定位到具体代码位置。4.3 常见问题速查表我把日常查过的重组问题整理成了一张表格遇到性能报警时对照着看比重新看源码快速很多症状可能原因解决的优先方案父级一变大量子级全重组子级参数不稳定修改数据类型为 val、加 Immutable 注解列表滚动时整页卡顿item 函数体太重用 remember 缓存计算、用 derivedStateOf 降频点击事件传入后子级总重组lambda 每次新建remember 缓存 lambda 或函数引用动画带动整个页面重排动画状态读数太靠上移动读动画值的代码到最小组件某个组件的 key 需要重置状态变化后旧布局残留用 key(state) 主动重置频繁更新的状态导致无关组件被波及状态提升位置太高状态下沉或拆分集合变化后界面不更新mutableList 内部修改用不可变 List 新引用或 SnapshotStateList4.4 避免为了优化而优化先定位再动手说实话Compose 的性能问题不是想象中那么普遍。很多页面几十个组件轻轻松松过 60fps完全没有优化的必要。真正需要优化的通常是三类场景长列表几十上百条 item、高频状态更新动画、滚动、实时输入搜索、以及组件层级特别深的页面。所以在开始动手之前先用布局检查器和 metrics 看一下数据如果某个组件的重组次数并不高就不要去动它。优化重组这件事本身也是要付出代码可读性代价的为了一个不存在的瓶颈把代码改成各种 remember 和 derivedStateOf只会让维护的人崩溃。我见过有的同事在简单的标签页里也套各种缓存最后改版时谁都看不懂得不偿失。5. 最后再聊一点我的实际体会做重组优化这一年多我最大的感受是Compose 的跳过机制确实智能但它更像一个需要你主动配合的伙伴而不是万能管家。你给它稳定的参数它帮你跳过你给它不稳定的数据、新建的 lambda、放得太靠上的状态它也无能为力只能默默全量重组。我自己后来定了一个简单的习惯组件设计时先想三个问题。第一这个组件的参数会不会变化如果会变化频率高不高第二这个组件内部有没有重计算能否用 remember 缓存第三有哪些状态其实只在这个组件内部使用却被我放到了外面把这三个问题过一遍大部分重组问题都能在写代码阶段就避免根本不用等到性能优化阶段去排查。另外如果你是刚入门 Compose别急着把所有优化技巧都堆上。先把 remember 和 derivedStateOf 这两个最核心的用熟然后再去研究 Stable 注解和编译器报告。优化是一个循序渐进的过程先把基本功打好比什么技巧都重要。这也是我一个从 View 体系转过来、在 Compose 上踩了不少坑的过来人最想对你说的话。