进程异常终止的完整恢复流程

理解进程死亡（Process Death）、Activity 重建与 ViewModel 恢复机制，是实现 Android 应用稳定性的基石。本章从系统层面的回收策略入手，逐步拆解一套完整的恢复链路。

1.1 进程死亡的本质

当 Android 系统内存不足或用户主动“清除后台”时，系统会选择终止（kill）某个后台进程。此时该进程内所有 Activity、服务、ViewModel 实例都会被销毁，但系统会尝试保留 Activity 的栈结构以及 onSaveInstanceState 保存的 Bundle 数据。

关键认知：进程死亡不等于 Activity 消亡——系统会记住任务栈的 Activity 顺序，并在下次启动时重新创建它们，前提是 Bundle 中保存了必要状态。

1.2 完整恢复流程

恢复过程可分为以下五个步骤，每一步都决定了应用能否无缝回显用户操作。

  1. 系统回收进程：LMK（Low Memory Killer）或用户主动杀进程，ActivityRecord 仍存在于 ActivityManagerService 的任务栈中。
  2. 保存 Bundle：系统在进程死亡前调用 onSaveInstanceState(Bundle outState)，将 UI 状态（如文本输入、滚动位置）序列化到 Bundle 中。
  3. Activity 重建：用户再次导航回该 Activity 时，系统调用 onCreate(Bundle savedInstanceState)，此时 savedInstanceState 携带上次保存的 Bundle。
  4. ViewModel 恢复：通过 ViewModelProvider 获取的 ViewModel 实例，其内部数据由 SavedStateHandle 自动从 Bundle 恢复；若 ViewModel 中持有网络数据，则可通过 onReinitialize 逻辑重新加载。
  5. UI 状态还原：Activity 从 ViewModel 或 Bundle 中读取状态，更新到视图控件，用户感知到“操作已恢复”。
实战提醒：若未正确保存 Bundle，Activity 重建后 savedInstanceState 为 null，需要手动回退到初始状态。ViewModel 的 SavedStateHandle 是官方推荐的新式状态保存工具，可替代传统 Bundle 操作。

1.3 Bundle 与 ViewModel 的恢复对比

维度 Bundle（onSaveInstanceState） ViewModel + SavedStateHandle
生命周期 与 Activity 重建绑定 跨越 Activity 重建，直到进程死亡
数据持久化 序列化到磁盘（Bundle） 通过 Bundle 间接持久化（SavedStateHandle 内部使用 Bundle）
处理复杂对象 需实现 Parcelable/Serializable 推荐使用基本类型、String 或可直接序列化的对象；复杂数据建议存入 Room 或 DataStore
适用场景 简单 UI 状态（输入框内容、滚动位置） 数据和业务逻辑的恢复（如列表内容、用户认证状态）

1.4 代码实现：恢复流程示例

以下代码展示了如何在 Activity 中保存/恢复状态，并通过 ViewModel 保持数据。

// Activity 部分
public class MainActivity extends AppCompatActivity {
    private MyViewModel viewModel;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        // 获取 ViewModel，即使在进程死亡重建后，只要 ViewModel 在同一个 Navigation 上，实例会复用？
        viewModel = new ViewModelProvider(this).get(MyViewModel.class);

        // 从 Bundle 恢复 UI 状态
        if (savedInstanceState != null) {
            String userName = savedInstanceState.getString("user_name");
            editText.setText(userName);
        }
    }

    @Override
    protected void onSaveInstanceState(Bundle outState) {
        super.onSaveInstanceState(outState);
        outState.putString("user_name", editText.getText().toString());
    }
}

// ViewModel 使用 SavedStateHandle
public class MyViewModel extends ViewModel {
    private final SavedStateHandle handle;

    public MyViewModel(SavedStateHandle handle) {
        this.handle = handle;
        // 从 SavedStateHandle 读取上次保存的数据
        String cached = handle.get("user_name");
        if (cached != null) {
            // 恢复数据
        }
    }

    public void saveUserName(String name) {
        handle.set("user_name", name);
    }
}

1.5 常见错误与调试

  • 未调用 super.onSaveInstanceState：会导致父类保存的自动恢复失效（如 Fragment 的恢复）。
  • 在 ViewModel 中持有 Activity 引用：进程死亡重建时 Activity 对象已变，旧引用导致内存泄漏或空指针。
  • 假设 ViewModel 始终存活：进程死亡后 ViewModel 实例也会被销毁，必须依赖 SavedStateHandle 或 Room 等持久化方案。
  • 调试方法：通过开发者选项“不保留活动”（Don’t keep activities）强制模拟 Activity 重建；通过“设置→开发者选项→限制后台进程”模拟进程死亡。
稳定性雷区：切勿在 onSaveInstanceState 中保存大量二进制数据（如 Bitmap），会导致 Bundle 序列化超时甚至 TransactionTooLargeException。正确做法是将大对象存入本地文件或数据库，仅保存标识符。

1.6 恢复流程的完整结构图

进程异常终止恢复流程 进程死亡 系统保存 Bundle Activity 重建 ViewModel + SavedStateHandle 从 Bundle 恢复 UI 状态 UI 恢复就绪 说明：箭头表示执行顺序；ViewModel 和 Bundle 恢复可以并行进行，最终汇合到 UI 更新。

上述流程清晰地展示了系统如何协同 Bundle 与 ViewModel 完成状态恢复。理解这一链路后，你可以在开发中针对性地使用 SavedStateHandle 代替手动 Bundle 管理，实现更加健壮的异常恢复。

← 上一章 📖 返回目录 下一章 →