compose-recomposition-performance

Compose 重组性能

仅用于路由——深入修复请参阅下方的专项技能。

三个维度

1. 参数稳定性 / 跳过 — Compose 能否跳过此可重启组合项；参数是否稳定且可比较？
2. 读取 State 的位置 — 帧率级 State 是在组合期间读取，还是在布局 / 绘制期间读取？
3. 跨阶段回写 — 后续阶段是否写入快照状态，从而使前面的阶段失效？例如：在组合期间修改 map/list，导致同一组合再次失效；onSizeChanged（布局阶段）写入某个同级项在组合期间读取的状态。

维度 2 和 3 经常重叠（同级项在组合期间读取测量尺寸，既违反了延迟读取原则，也是布局 → 组合回写）。维度 1 则相互独立。

从此处跳转 → 专项技能

主要疑点	下一步技能
跳过、不稳定参数、编译器 / composables.txt 变动	compose-stability-diagnostics
帧率级 State 的读取阶段（组合与布局 / 绘制）	compose-state-deferred-reads
组合期间的 putAll / map 重建 / 跨行 height(state)	compose-state-deferred-reads — § 回写
组合函数体中由焦点驱动的额外工作	compose-side-effects — snapshotFlow
有多个维度的证据	并行应用匹配的技能

审查顺序

1. 重现一次状态变化（移动焦点、插入、滚动），并记录哪些组合项发生了重组。
2. 如果未更改的惰性列表项的计数激增，先检查回写（组合期间的修改和跨行测量），再怀疑稳定性。
3. 如果滚动 / 动画期间计数逐帧攀升，请检查延迟读取。
4. 如果尽管数据稳定，跳过仍然失败，请检查参数稳定性和编译器报告。
5. 每次修复后重新测量。

容易误判的方向

这些更改通常不会降低重组次数：

尝试	失败原因
使用 remember(index) { isFirstRow(index) } 代替内联 when (index)	输入相同；无法改善跳过
为只读派生 map 使用身份缓存	可能提供过时的叠加层；remember(keys) 已足够
在测量行和同级行上使用 mutableIntStateOf + 布局修饰符	除非只在测量阶段读取，否则同级行仍会在组合期间读取尺寸
在焦点移动测试中强制两行都使用 Exactly(1)	其中一行通常正确地重组 0 次
提升状态但未稳定 lambda 捕获	每帧生成新的 lambda 实例仍会阻碍跳过

不适用的情况

• 重组与实际数据变化一致，或者问题在于正确性而非开销。
• 没有分析器 / 编译器信号表明存在问题。

相关内容

• compose-state-authoring — 安全地编写 mutableState*。