Jetpack Compose可组合项重建时状态持久化的最佳方案

条件渲染状态丢失的根因 #

第一种if/else分支实现出现状态重置，是Compose的默认设计行为：当可组合项从Composition视图树中被移除时，它内部通过remember持有的所有状态会被同步回收。切换分支时，不在当前判断逻辑内的组件会被完全销毁，下次进入分支时就是全新的实例，自然会重新生成随机数这类内部状态。

符合规范的状态保留方案 #

不存在必须上提所有状态的强制要求，根据状态的类型和使用场景选对应方案即可：

• 轻量UI状态优先用rememberSaveable
  这是改动成本最低的方案。把组件内部的remember替换为rememberSaveable即可，状态会被持久化到系统Bundle中，哪怕组件被移出Composition、甚至页面重建/进程被杀后恢复，状态都能保留。这个方案仅适合可序列化、体积较小的状态，比如输入框内容、开关选中值、示例中的随机数这类简单数据，大体积对象、复杂数据结构不适用。

  // 替换前
  val myRandomNumber by remember { mutableStateOf(Random.nextInt(100)) }
  // 替换后
  val myRandomNumber by rememberSaveable { mutableStateOf(Random.nextInt(100)) }
  

• 同树组件状态错配用key标识身份
  如果是同类型组件在列表、条件分支中出现状态串扰，给组件加上全局唯一的key修饰符即可，Compose会根据key识别组件身份，避免复用过程中的状态错配，但这个方案不能解决组件被移出树后的状态丢失问题。
• 共享/重状态遵循上提原则
  如果状态需要被上层组件、同级其他组件访问，或是内部持有后台任务、资源订阅这类重逻辑，把状态上提到控制切换逻辑的上层（比如上层可组合项、ViewModel）是最符合Compose设计规范的方案。子组件通过参数接收状态、通过回调触发状态变更，本身不持有状态，自然不存在切换重建丢失的问题。

尺寸0dp隐藏方案的性能风险 #

这种把两个组件都留在视图树、通过修改尺寸实现“切换”的写法属于非标准hack，开销完全取决于子组件的实现：

• 对于示例中这种无副作用、纯展示的轻量Button+Text组件，0尺寸下不会参与绘制，布局计算成本极低，几乎没有可感知的性能影响。
• 只要组件包含以下逻辑，就会产生明确的性能损耗，甚至引发业务bug：
  • 持有LaunchedEffect、DisposableEffect等副作用：只要组件存在于Composition树中，副作用就会持续运行，哪怕尺寸为0，动画、网络请求、事件订阅、后台任务都不会停止，会持续占用CPU、内存资源。
  • 持有重资源对象：比如播放器实例、大尺寸Bitmap、数据库/传感器监听器，不会因为组件尺寸为0被自动释放，会持续占用系统资源。
  • 订阅了全局状态：状态变更时，不可见的组件仍然会参与重组计算，无故增加主线程负载。
• 额外风险：0尺寸组件如果没有做触摸拦截，部分场景下仍然会响应点击事件，容易引发难以排查的交互冲突。

方案选择建议 #

1. 仅需保留轻量UI状态、切换时允许组件销毁释放资源：直接用rememberSaveable，代码改动最小。
2. 切换时组件需要持续运行逻辑（比如多Tab页实时刷新）：不要用0尺寸hack，优先使用官方提供的HorizontalPager、TabRow等组件，这类组件内置了离屏优化；如果是自定义切换逻辑，用Modifier.graphicsLayer { alpha = if (visible) 1f else 0f }控制可见性，同时配合生命周期感知，给不可见组件下发暂停信号，停止后台任务、释放重资源。
3. 涉及跨组件共享的业务状态：直接上提到上层作用域或ViewModel统一管理，是长期维护成本最低的方案。

内容的提问来源于stack exchange，提问作者Lucas Sousa