在 Jetpack Compose 应用里，界面状态丢失通常不是“偶发现象”，而是配置变更、Activity 重建和系统回收进程后的常见结果。要把问题处理好，关键不只是“会不会保存”，而是先分清状态属于界面层还是业务层，再选对 rememberSaveable、ViewModel 和 SavedStateHandle 这些工具。本文按状态丢失原因、保存策略、实践边界和验证方法逐段梳理，帮助你判断什么该放进 Bundle，什么应该交给本地持久化存储。
为什么 Compose 界面状态会丢失
Android 应用中的界面状态，常见会在下面几类场景中丢失：
- 系统发起的进程终止：例如内存不足时，系统直接杀掉进程。
- 配置更改：例如屏幕旋转、语言切换、深浅色模式变化等。
- 用户发起的进程终止：例如用户明确关闭应用。
其中，用户主动关闭应用后，某些瞬时界面状态丢失通常可以接受；但如果是配置更改或系统回收进程导致输入内容、展开状态、滚动位置全部重置，用户体验就会明显下降。
先分层，再决定用哪种状态保存方案
在 Compose 中，保存状态的核心判断标准不是控件类型，而是状态被提升到了哪里、以及它是否参与业务逻辑。
界面逻辑中的状态：优先使用 rememberSaveable
如果状态只服务于界面展示，并且保存在可组合函数内部，或者保存在生命周期限定于组合范围的普通状态容器中，通常应使用 rememberSaveable。它可以在 Activity 重新创建以及进程恢复后，把界面元素状态从保存的实例状态中还原出来。
一个典型例子，是保存某个气泡消息的“详情是否展开”状态：
@Composable
fun ChatBubble(message: Message) {
var showDetails by rememberSaveable { mutableStateOf(false) }
ClickableText(
text = AnnotatedString(message.content),
onClick = { showDetails = !showDetails }
)
if (showDetails) {
Text(message.timestamp)
}
}
这类状态的特点是简单、局部、主要影响当前界面的渲染结果。使用 rememberSaveable 后，即使发生重建，也能把用户刚才的界面操作保留下来。
`rememberSaveable` 的存储机制与适用边界
rememberSaveable 本质上依赖保存的实例状态机制，最终把数据放进 Bundle。这意味着它很适合存简单状态，但不适合无限扩张地塞入复杂对象。
- 基元类型可以直接保存到
Bundle中。 - 非基元类型，例如数据类，可以借助
Parcelize、listSaver、mapSaver，或者自定义Saver来处理。
例如，Compose 自带的列表滚动状态就可以通过 Saver 恢复：
@Composable
fun rememberLazyListState(
initialFirstVisibleItemIndex: Int = 0,
initialFirstVisibleItemScrollOffset: Int = 0
): LazyListState {
return rememberSaveable(saver = LazyListState.Saver) {
LazyListState(initialFirstVisibleItemIndex, initialFirstVisibleItemScrollOffset)
}
}
这也是一个很实用的判断标准：如果一个状态本身就是界面元素的轻量描述，例如布尔值、输入框内容、滚动位置，那么它通常适合进入 rememberSaveable。
业务逻辑相关的状态：放进 ViewModel，必要时配合 SavedStateHandle
当界面元素状态已经不只是“显示问题”，而是需要进入业务逻辑、参与数据处理或跨组合共享时，状态通常会被提升到 ViewModel。
ViewModel 的一个直接优势是：在配置更改后实例仍然存在，因此相关状态可以继续保留在内存中，不会因为简单的旋转屏幕而丢失。
但要注意，ViewModel 并不能解决系统发起的进程终止。一旦进程被杀，ViewModel 也会失效。这时候就需要 SavedStateHandle 补上恢复能力。
下面是一个把输入框状态保存到 SavedStateHandle 的例子：
class ConversationViewModel(savedStateHandle: SavedStateHandle) : ViewModel() {
var message by savedStateHandle.saveable(stateSaver = TextFieldValue.Saver) {
mutableStateOf(TextFieldValue(""))
}
private set
fun update(newMessage: TextFieldValue) {
message = newMessage
}
}
@Composable
fun UserInput(viewModel: ConversationViewModel = viewModel()) {
TextField(
value = viewModel.message,
onValueChange = { viewModel.update(it) }
)
}
这里的关键点是：界面层继续通过 Compose 渲染状态，但状态来源已经被提升到了 ViewModel，并借助 SavedStateHandle 在进程恢复时继续拿回原值。
`SavedStateHandle` 常用 API 怎么选
SavedStateHandle 常见有两种使用方式：
saveableAPI：适合以MutableState形式读写界面元素状态，支持基元类型和自定义Saver。getStateFlowAPI：适合把状态作为数据流暴露出来，在更偏响应式的数据处理场景中使用。
简单理解，前者更贴近 Compose 的状态写法，后者更适合需要与 Flow 管道配合的业务层状态管理。
实际项目里的最佳实践
不要把大型复杂对象直接塞进 Bundle
无论是 rememberSaveable 还是 SavedStateHandle，底层都离不开 Bundle。而 Bundle 容量有限，如果把大型对象、复杂对象图，或者整组列表数据直接保存进去，就可能触发 TransactionTooLargeException。
这类问题往往不是一开始就暴露，而是在页面变复杂、列表变长、对象字段变多之后突然出现，因此在设计时就要控制保存粒度。
只保存恢复界面所需的最小状态
更稳妥的做法，是只保存恢复界面必需的最少数据，例如：
- 当前选中项的 ID
- 输入框内容
- 滚动位置
- 筛选条件或排序键
复杂的屏幕状态应当根据这些最小字段，从数据层重新生成，而不是整体序列化后塞回 Bundle。
复杂状态交给持久化存储
如果状态本身已经超出“界面元素状态”的范围，例如包含大量业务数据、离线缓存结果、复杂编辑内容或需要跨会话保留的信息，就不应该继续依赖 SavedStateHandle。
这类内容更适合放进本地永久性存储，例如 Room 数据库。界面层只保存恢复入口，真正的数据从持久化层重新读取，这样更符合 Android 的状态恢复模型，也更容易长期维护。
如何验证状态确实能恢复
光是“写了 rememberSaveable”并不等于状态恢复一定可靠。要验证 Compose 元素在 Activity 重建或状态恢复后的行为，可以使用 StateRestorationTester。
示例代码如下：
@Test
fun testStateRestoration() {
val tester = StateRestorationTester(context)
tester.setContent {
val (value, setValue) = rememberSaveable { mutableStateOf(0) }
// Test logic here
}
}
测试的重点不只是“值有没有保存”，还包括界面在恢复后是否按预期重新渲染、交互是否连续，以及自定义 Saver 是否真的覆盖到了目标类型。
结论：按状态归属选 API，别让保存机制承担过多职责
如果状态只属于界面展示层，优先使用 rememberSaveable；如果状态已经进入业务逻辑并提升到 ViewModel，再用 SavedStateHandle 处理进程恢复。两者都适合轻量、可序列化、可恢复的界面元素状态，而不是完整业务数据。
真正稳定的做法，是把 Bundle 看成“恢复入口”而不是“完整存储层”：保存最小必要状态，复杂数据交给 Room 等持久化方案，再通过测试确认恢复路径成立。
