做Android性能分析尤其是Jetpack Compose这边有一半的时间其实不是在调代码而是在搞清楚Compose到底“重跑了哪些代码”。很多人把重组优化挂在嘴边但真到了项目里看到页面滑动掉帧、点一下列表项整页都重绘就开始一顿乱改加remember、改lambda、换StateFlow……改了半天发现没啥用。这篇就把重组优化的底子拆开讲透从重组机制本身聊到稳定类型、跳过逻辑、编译期报告最后给出一套可以直接上手的排查流程和几个我实际项目中踩过的大坑。内容偏Jetpack Compose方向适合已经有基础写Demo、但还没系统梳理过性能要点的开发者。1. 重组到底在重什么——先搞懂Compose的最小重绘单位1.1 重组不是重跑整个页面很多人刚开始用Compose时会下意识把它当成“整个页面重新执行一遍”。这个理解是重组优化入门最大的坑。Compose的重组本质上是只重新执行“读取了变化状态”的那部分代码而不是整个布局树。它靠的是编译期插桩编译器会把每个可组合函数包装成带跳过机制的执行单元。当某个State发生变化时Compose运行时只会找到那些在组合中真正读到该状态的读取点并把它们标记为无效。我举个例子你有一个LazyColumn每个列表项里显示标题和图片。如果其中一项的标题变成加载中理论上只有那一个item的Text需要重新走一遍组合函数。可如果你把整个列表的ListItem直接作为一个对象传下去并且在父级组合里不加任何拦截那么Compose无法判断列表内到底哪一项变了因为它看到的是“整个List引用变了”于是会把所有列表项全部重组。这就是“整页重绘”假象的根源。所以重组优化的第一个核心概念是让Compose能够判断“变化发生在哪”它才能把重组范围精确缩到最小。1.2 状态读取点决定生效范围接下来需要理解一个更底层的机制状态读取点。Compose的StateT读取不是透明的它通过Composer的调用栈实现跟踪。简单说当你在一个组合函数体里读取state.value时Compose会把这个读取行为“登记”到当前正在执行的组合函数上。之后该状态一旦被写入新值运行时就能根据登记信息精确地唤醒这些组合函数重新执行。这个机制带来一个非常有意思的推论同一份状态在哪个层级读取就只影响哪个层级及其子级。比如你在顶层Screen里读取userName那么只要userName变了整个Screen函数体都会重新执行但如果你把userName下沉到某个Text内部去读取Screen本身就不会被唤醒。我在实际代码里经常看到这个误用Composable fun Screen(viewModel: MyViewModel) { val userName by viewModel.userName.collectAsState() Column { Header(userName) // Header 会重组 UserList(viewModel.list) // 这里也会跟着重组 } }userName在Screen这一层被读取所以哪怕UserList完全没有依赖它只要用户名变了整个Column内部的组合函数都会重新走一遍。优化方式很简单把读取点下沉Composable fun Screen(viewModel: MyViewModel) { Column { UserNameText(viewModel.userName) // 只在 UserNameText 内部读取 UserList(viewModel.list) } } Composable fun UserNameText(flow: FlowString) { val name by flow.collectAsState() Text(name) }这就是“状态读取点决定生效范围”的实践意义。优化重组的第一步不是加缓存而是审视状态在哪里被读取把读取点位下沉到真正需要它的组件上。1.3 跳过机制基础强跳过模式Compose编译器在插桩时会为每个可组合函数生成跳过逻辑。简单讲就是函数的参数都和前一次相同且函数体里没有非稳定状态被全局修改时Compose就可以直接跳过这次执行复用上一次的结果。跳过逻辑依赖两个东西参数比较和稳定性判断。参数好理解比较的是前后两次传给函数的引用是否相同。稳定性就比较微妙了它描述的是“这个类型的实例中的数据能否安全假设为不变”。一个类型被判定为稳定stable后Compose才敢用“引用相同”替代“内容比较”所以String、Int这些基础类型都是稳定的data class如果字段全部稳定也是稳定的。反之如果你的参数类型被判定为不稳定unstable就算你每次传入的是同一个对象Compose也会倾向于不跳过宁可重新执行一遍。需要特别提一下强跳过模式Strong Skipping Mode。从Compose编译器1.5.4开始官方默认开启了强跳过模式它放宽了跳过的条件即使参数类型不稳定只要参数值通过equals比较没有发生变化函数体中的lambda参数也可以被跳过甚至带lambda参数的函数也能在lambda未被修改时跳过。这解决了一大批“底层状态变了导致整棵子树重组”的焦虑但前提是你还在用新版本编译器。如果还在老版本上稳定性就是硬约束一点都含糊不得。2. 决定重组范围的三类关键因素2.1 稳定性Compose敢不敢跳过你Compose编译器在编译期会根据类型结构自动推断每个类的稳定性。规则是原始类型和String稳定函数类型稳定前提是不捕获不稳定变量data class中所有字段都是稳定时这个data class是稳定的List、Map这类接口类型编译器默认按不稳定处理因为它只看接口声明无法确定底层实现是否可变自己写的普通class只要属性全部是val且类型稳定编译器会帮忙标成稳定否则就是不稳定。我在项目里最常碰到的就是List导致的不稳定。比如一个商品列表data class Product(val id: String, val name: String, val price: Double) Composable fun ProductList(products: ListProduct) { Column { products.forEach { product - ProductItem(product) } } }这里的products参数是ListProduct编译器默认认为它不稳定。因为接口类型可能被MutableList实现你传进来之后Compose无法证明它不会在别处被修改。所以哪怕你外部用remember把同一个products对象反复传进来只要父级发生重组ProductList一定会跟着重新执行。解决思路有两个方向一个是把类型换成编译器能确定稳定的容器比如用ImmutableList来自kotlinx.collections.immutable让编译器看到的是明确不可变的结构另一个是用Immutable注解自己写的包装类来承载列表告诉编译器“我不会改它”。2.2 Stable、Immutable 的正确打开方式很多人一遇到重组问题就无脑加Stable或Immutable这个做法很不严谨。这两个注解本质上是给编译器的承诺“这个类的属性的变化都会被Compose观察到如果需要观察的只是其中一部分我会用mutableStateOf包住变化的部分。”如果你违背了这个承诺就可能导致UI不更新的诡异bug比性能问题更难查。Immutable表示这个类型创建后永远不会变化是最强的稳定性保证。它适合那些“构造出来就不改”的纯数据类型比如菜单配置、常量字典。Stable则宽松一些表示类型内部有状态变化能力但变化会被Compose的状态机制观察到。我用一个真实场景说明假设我们要设计一个表单页有一个输入框和一个提交按钮。按钮的可用性依赖输入框内容。常见写法是把整个表单状态塞进一个data classdata class FormState( val username: String, val password: String, val submitEnabled: Boolean )如果你在TextField里修改用户名FormState整体会变成一个新实例编译器通过equals判断发现整个对象都变了于是哪怕密码没变绑定密码框的组合函数也会被判定为可能需要重组。正确的做法是把这个状态按“变化的维度”拆小用remember存独立的mutableStateOf让每个输入框只读自己那部分状态。这时候即便整个FormState被标成Stable只要内部变化字段能被单独观察重组范围也能被压缩得很小。2.3 lambda、集合、普通对象为何总拖后腿在Compose里lambda是最容易被忽视的“重组放大器”。因为你在组合函数里写一个lambda时它本质上是一个匿名对象。每一次组合函数重新执行都会创建新的lambda实例。如果这个lambda被当成参数传给子组件子组件做参数比较时发现引用变了于是就只能跟着重组。看这个例子Composable fun Parent(list: ListString) { Column { list.forEach { item - Child(item, onClick { handleClick(item) }) } } }这个onClick每次组合都会生成新实例而Child接收的是一个函数类型参数。如果Child没有做任何缓存每次父级重组它都会跟着执行。更麻烦的是这个lambda捕获了item编译器为了判断它是否变化需要分析捕获参数的稳定性。若item本身不稳定lambda也会被拖得不稳定。优化手段一般是把lambda提升到组合函数参数层让外界传入Composable fun Parent( list: ListString, onItemClick: (String) - Unit // 由外层传入通常更稳定 ) { Column { list.forEach { item - Child(item, onClick { onItemClick(item) }) } } }这样lambda的稳定性取决于外部调用方而外部调用方如果是在ViewModel层持有回调引用往往比内部临时创建稳定得多。另外如果你的业务回调不需要参数尽量用onClick: () - Unit而不是onClick: (Int) - Unit因为无参函数可以借助rememberUpdatedState等方式做更好的缓存优化。3. 一套可落地的重组优化操作方案3.1 状态提升与Composable拆分先做对结构进入实操阶段我的第一建议永远是先把结构拆好再谈要不要加缓存。组合函数拆得越细状态读取点就越容易被下沉重组范围就越小。这个拆不是无脑细颗粒而是按“状态边界”拆。我习惯的做法是页面级组合函数只负责组装“大的区块”不读取具体业务状态。比如一个商品详情页我会拆成ProductHeader、ProductGallery、ProductInfo、BuyBar四个区块。页面层只持有商品ID和必要回调具体商品数据的读取下沉到每个区块内部。这样做有双份收益第一状态读取点天然分散哪个区块的数据变了就只重组哪个区块第二写单元测试时区块也能独立验证UI逻辑。纯函数式组合也很重要。如果一个组合函数只依赖参数且参数都稳定它天然就是可跳过的。在写组件时尽量保持“函数式”输入参数明确没有隐式地读取外部可变状态。反之如果你在组合函数里直接读取一个object单例里的全局mutableStateOf那么这个组合函数的跳过逻辑基本失效因为编译器认为它随时可能被全局修改。提示结构拆分解决的是“变化传播范围”的问题缓存解决的是“高频重复计算”的问题。两者都重要但结构是根。3.2 remember 的三种正确打开方式remember是Compose缓存的基础API但很多人用得不对劲。我总结下来主要有三种正确姿势。第一种是缓存昂贵计算。比如一个复杂的列表项换算val expense remember(item) { calculateExpensiveValue(item) }这里remember的key是itemitem变了才重新计算。注意key必须是你真正依赖的输入漏掉key会导致缓存过期问题。第二种是缓存可组合作用域内的对象实例尤其是在配合mutableStateOf时val state remember { mutableStateOf() }这种写法保证每次重组拿到的是同一个State对象而不是新建一个。你如果写成val state mutableStateOf()没有包remember每次重组都会创建新StateUI读取到的永远是初始值根本不会刷新。第三种是用rememberSaveable做进程重建后的数据恢复。它内部用SaveableStateRegistry保存到Bundle适合输入框内容、选中状态这种需要在Activity重建后保留的数据。但注意rememberSaveable只能保存可被Bundle序列化的类型自定义对象要配Saver。我还想提醒一点remember不是越多越好。如果一个对象构造很廉价比如简单的String拼接加remember反而多了一层无意义的key比较逻辑。只有那些真正创建耗时或对象引用必须保持稳定时才需要它。3.3 derivedStateOf 与 key 的使用时机derivedStateOf是我做重组优化时特别爱用的一招。它适合处理“由其他状态推导出来的状态”尤其适合那些高频中间值不需要触发UI逻辑的场景。举个例子列表滚动时经常要判断“是否显示回到顶部按钮”。如果用scrollState.value直接驱动按钮状态每次滑动像素值变化都会触发重组val showButton by remember { derivedStateOf { scrollState.value 1000 } }derivedStateOf内部会做“只在推导结果变化时通知外部”的优化也就是说showButton只会在跨越1000这个阈值时变化滑动过程中不会高频触发重组。这个优化在真实滑动场景里效果非常明显。key则用于强制重置组合状态。当某个组件依赖的标识发生变化时你想让它彻底重建而不仅仅是重组。比如切到另一篇文章时评论输入框应该清空。把文章ID作为keykey(articleId) { CommentInput() }articleId变了CommentInput的组合会被丢弃后重新创建内部的remember状态自然重置。这里要注意key不只是性能工具更是一种“组合生命周期管理”工具用它来区分不同数据实体的UI状态非常合适。3.4 lambda 参数优化把不必要的变化挡在门外到了lambda层级我有一套固定套路。先说被动方式用rememberUpdatedState保持最新值但不触发重组。典型场景是子组件里做了一个延时操作结束后要调用最新的回调但你不能让这个回调变化导致子组件重组。Composable fun TimerButton(onTimeout: () - Unit) { val currentOnTimeout by rememberUpdatedState(onTimeout) LaunchedEffect(Unit) { delay(2000) currentOnTimeout() } }再说主动方式把lambda参数尽量改造成“稳定的函数引用”。如果你在ViewModel层定义了方法可以直接传方法引用不要包一层新lambda// 不推荐 onClick { viewModel.submit() } // 推荐 onClick viewModel::submit因为viewModel::submit是一个稳定的绑定函数引用每次不会新建对象有利于子组件跳过重组。还有一个容易被忽略的点高阶函数参数要尽量后置。Kotlin中带尾部lambda的参数可以放在括号外面提升代码可读性。但这不是重点重点是当你设计的函数有多个lambda参数时尽量把稳定的放前面、变化的放后面这样编译器比较参数时能更早命中相同引用减少无谓的对象比较成本。这个收益其实很小主要靠习惯养成。4. 排查重组问题的实战工具清单4.1 开启Compose编译器统计与强跳过模式说了这么多优化思路真正落地时不能靠猜。我强烈建议先做一次编译期体检。在模块的build.gradle.kts里配置composeCompiler { reportsDestination layout.buildDirectory.dir(compose_compiler_reports) metricsDestination layout.buildDirectory.dir(compose_compiler_metrics) }构建后会在对应目录生成一系列文件。重点看两个模块名-classes.csv和模块名-composables.csv。在classes.csv里有每个类的稳定性信息一眼能看出哪个data class被标成了unstable。看到不稳定的类型你就能定位到参数或状态包装是否需要改造。composables.csv则会列出每个可组合函数是否restartable、skippable。看到skippablefalse的函数就要注意了这意味着它每次都会执行。如果项目用的编译器在1.5.4以上强跳过模式默认是开的这部分不用手动配置。老项目如果想升级建议先在分支上切到新版编译器观察classes.csv里的稳定性标记变化再逐步处理不稳定的类型。4.2 Layout Inspector 检查真实重组次数编译期报告告诉你“哪些函数理论上有跳过能力”但运行时是不是真的跳过了还需要看实际执行情况。最直观的办法是用Android Studio自带的Layout Inspector。操作路径是运行App在Debug模式下打开Tools - Layout Inspector选择正在运行的界面点击任意节点右侧面板会显示Composable的Recomposition count和Skipped count。用这个数据就能验证你的优化是否生效。我第一次用这个工具时发现某个简单页面的某个节点重组了几十次当时还觉得是Compose的bug。后来排查发现是LazyColumn里item的key没有指定导致滚动刷新时滚动位置发生变化引起了大范围重组。加上key(item.id)之后重组次数直线下降。这个工具还有一个隐藏技巧使用Layout Inspector配合Profile GPU rendering或systrace来分析能够在屏幕滑动时捕捉到具体哪个阶段的耗时最长。组合阶段Rebuild耗时高就说明重组系统在高负荷运转这时候就要回头检查状态读取点和稳定性了。4.3 组合度量与自定义边界标记除了官方工具我在复杂项目里还会手动加一些“边界标记”。做法很简单在认为可疑的组合函数第一行插入一个日志Composable fun ProductItem(product: Product) { Log.d(ComposeDebug, ProductItem recomposed: ${product.id}) // ... }然后跑一个固定操作看日志输出频率。如果某个节点在无关状态变化时也频繁打印说明它没被正确跳过。这个方法简单粗暴却非常有效。日志打多了会影响性能所以我会在定位后立刻删掉。Compose从1.4开始还提供了CompositionTracer相关的API但可操作性不如日志直观。更推荐的做法是结合androidx.compose.runtime.trace里的Trace类在关键区块里手动埋点配合systrace查看组合、布局、绘制耗时分布。这样能区分出问题到底是出在重组、布局还是绘制阶段不至于一有卡顿就怪重组。5. 实际项目里最常踩的五个重组陷阱5.1 陷阱一用普通集合加索引渲染列表这是新手最容易踩的。在LazyColumn里直接itemsIndexed(list)然后每个item仅仅是简单展示看起来没啥问题。但列表里一旦有输入框、开关这类状态组件索引作为key会导致状态错乱。比如开关被用户打开了如果列表项发生了插入或删除索引会移动Compose根据索引去恢复状态就有概率把“打开”状态恢复到另一行上。更隐蔽的是这种错误不会让项目崩溃只是表现为状态错乱用户也说不清什么时候开始错乱的。解决方法是给items指定稳定keyLazyColumn { items(items list, key { it.id }) { item - ProductItem(item) } }这个key不仅让状态跟随数据实体移动也给Compose的diff算法提供了精确的复用依据避免整列的大范围重组。5.2 陷阱二稳定性误判导致的高阶组件失效还有一类问题是我在老项目改造时遇到的自定义的高阶组件或通用封装组件因为内部接收的参数类型不稳定导致原本精心设计的缓存逻辑全部失效。比如我写了一个防抖按钮内部用remember缓存了点击回调但因为回调参数类型是(Any) - Unit编译器认为它不稳定直接导致整个按钮组件无法跳过。我当时的排查思路是这样先看composables.csv里这个按钮组件是否skippable发现是false再看classes.csv里回调类型是否unstable果然中招。因为项目里的封装接口为了通用用了Any作为回调参数类型编译器无法推断Any的稳定性。解决方式是给这个接口加上Stable注解或者把回调泛型化并显式声明稳定。泛型在某些场景下也会导致编译器放弃稳定性推断所以遇到抽象层级较高的组件时稳定性标记一定要手动检查不能全靠自动推断。5.3 陷阱三错误使用remember导致状态过期remember用错了会埋下更难查的坑。最常见的错误是在组合函数里用remember缓存了从外部传入的参数但key没写全。Composable fun UserInfo(user: User) { val displayName remember { user.name.uppercase() } // ... }这里没有指定keyCompose会认为缓存永远有效。如果user整体对象变化但内部name变了因为user对象引用没变比如业务层复用了同一个对象缓存就不会更新页面展示的还是旧名字。更糟糕的是这种bug在开发环境不容易复现只有特定数据流才会触发。正确写法是val displayName remember(user.name) { user.name.uppercase() }另一个与之相对的陷阱是用remember保存了可变集合并在组合外修改它。比如val myList remember { mutableListOfString() } myList.add(new) // 在组合函数外某个地方修改这种写法不通过State机制通知ComposeUI永远不会感知列表变化。正确做法是remember { mutableStateListOfString() }让列表变化能被Compose的快照系统追踪。5.4 陷阱四高频状态更新触发的不必要重组滑动、拖拽、输入这类高频交互场景最容易暴露重组性能问题。我遇到过最典型的是滑块Slider和文本输入框。滑块值每秒变化几十次如果监听这个值的组合函数读取了太多无关状态就会导致整块区域高频重组。处理思路有三个层级第一层是把变化的State限制在最小范围内比如只让滑块本身的文本标签读取实时值不让外层容器读取第二层是用derivedStateOf把低频状态从高频流中分离出来第三层是使用Modifier级别的绘制优化比如drawWithContent只在State变化时重绘避免触发组合。另外针对高频悬浮层还需要考虑graphicsLayer的用法。滑动卡顿往往不是组合慢而是布局和绘制慢。如果组合阶段耗时不高就别在重组上死磕先检查是不是布局层级过深或绘制逻辑复杂。5.5 陷阱五滥用derivedStateOf和snapshotFlow最后一个陷阱跟过度优化有关。derivedStateOf确实能减少重组次数但用错了反而增加复杂度。比如在本来就低频变化的场景里硬套derivedStateOf只是白白增加一层状态依赖关系排查问题时多一个环节。更常见的是snapshotFlow误用。snapshotFlow用于把Compose状态转换为Flow适合在LaunchedEffect中收集。但它本身是在快照系统之上建立的一套数据流如果你的状态变化频率极高snapshotFlow会按帧整合变化处理不当会造成事件丢失。不要什么状态都往Flow里塞能用rememberCoroutineScope在事件回调里直接处理就用直接处理的方式。我个人判断标准是只有当某个状态“被读取的UI组件”和“产生该状态的源头”间隔较远或者状态本身需要经过聚合计算时才引入derivedStateOf或snapshotFlow。其余的简单映射关系直接读State更直观性能也够用。我做了这么久Compose项目一个很深的体会是性能优化不是靠一个神奇API救场而是靠对状态流和数据流的理解。每次看到一张卡片点一下导致整页重组我第一步会怀疑的不是某个组件没加缓存而是状态到底是不是在正确的层级被读取了。建议你在动手优化时先花十分钟把组合树和状态树画出来再对照着改代码效率比盲目试要高得多。最后一个小技巧优化完一个点用Layout Inspector记录优化前后的重组次数对比这个数据既是给团队的交代也是自己排查能力的积累。