在 Android 上恢复状态

当用户运行移动应用后选择运行另一个应用时，第一个应用会进入后台，或称 被置于后台。操作系统（iOS 与 Android 均如此）可能会终止后台应用以释放内存，并提升前台应用的性能。

当用户再次选择该应用、将其带回前台时，操作系统会重新启动它。但除非你在应用被终止前设置了保存状态的方式，否则状态会丢失，应用会从头开始。用户会失去他们期望的连续性，这显然不理想。（想象在点击 Submit 之前 填写冗长表单时被电话打断。）

那么，如何恢复应用状态，使其看起来与进入后台之前一样？

Flutter 在 services 库中通过 RestorationManager（及相关类）提供解决方案。使用 RestorationManager 时，Flutter 框架会在 状态变化时 将状态数据提供给引擎，以便在操作系统发出即将终止应用的信号时应用已就绪，而应用只有片刻时间准备。

只需完成几项任务即可启用状态恢复：

1. 为 CupertinoApp、MaterialApp 或 WidgetsApp 等类定义 restorationScopeId。

2. 为支持它的 widget（如 TextField 和 ScrollView）定义 restorationId。这会自动为这些 widget 启用内置状态恢复。

3. 对于自定义 widget，你必须决定要恢复哪些状态，并在 RestorableProperty 中保存该状态。（Flutter API 为不同数据类型提供多种子类。）在使用 RestorationMixin 的 State 类中定义这些 RestorableProperty widget。在 restoreState 方法中向 mixin 注册这些 widget。

4. 若使用任何 Navigator API（如 push、pushNamed 等），请迁移到名称中包含 restorable 的 API （restorablePush、restorablePushNamed 等）以恢复导航栈。

其他注意事项：

• 向 MaterialApp、CupertinoApp 或 WidgetsApp 提供 restorationScopeId 会通过注入 RootRestorationScope 自动启用状态恢复。若需要在应用类 之上 恢复状态，请手动注入 RootRestorationScope。

• restorationId 与 restorationScopeId 的区别： 接受 restorationScopeId 的 widget 会创建新的 restorationScope（新的 RestorationBucket），所有子级在其中保存状态。 restorationId 表示该 widget（及其子级）在周围的 bucket 中保存数据。

若希望应用返回到用户最近查看的特定路由（例如购物车），则还必须为导航实现状态恢复。

若直接使用 Navigator API，请将标准方法迁移为可恢复的方法（名称中包含 restorable）。例如，将 push 替换为 restorablePush。

要测试状态恢复，请将移动设备配置为应用进入后台后不保存状态。要了解如何在 iOS 与 Android 上操作，请参阅 RestorationManager 页面上的 Testing state restoration。

有关状态恢复的更多信息，请参阅以下资源。

• 要了解短期与长期状态的更多信息，请参阅 区分临时状态与应用状态。

• 有关导航与 go_router package 的更多信息，请参阅 导航与路由 以及 pub.dev 上的 State restoration 主题。