在 Android 上恢复状态

当用户运行一个移动应用，然后选择运行另一个应用时，第一个应用会被移动到后台，或称之为后台化。操作系统（iOS 和 Android 均是如此）可能会终止后台应用以释放内存并提高前台应用的性能。

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

那么，如何才能恢复应用的状态，使其看起来就像被发送到后台之前那样呢？

Flutter 提供了解决方案，即 RestorationManager（和相关类）在 services 库中。借助 RestorationManager，Flutter 框架会随着状态变化将状态数据提供给引擎，这样当操作系统发出即将终止应用的信号时，应用就能做好准备，因为留给应用准备的时间只有几秒。

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

1. 为所有支持状态恢复的 widget 定义 restorationId 或 restorationScopeId，例如 TextField 和 ScrollView。这会自动为这些 widget 启用内置状态恢复。

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

3. 如果你使用了任何 Navigator API（例如 push、pushNamed 等），请迁移到名称中包含“restorable”的 API（restorablePush、restorablePushNamed 等），以恢复导航堆栈。

其他注意事项

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

• restorationId 和 restorationScopeId 的区别： 接受 restorationScopeID 的 widget 会创建一个新的 restorationScope（一个新的 RestorationBucket），所有子级都在其中存储其状态。restorationId 意味着 widget（及其子级）将数据存储在周围的 bucket 中。

如果你希望应用返回到用户最近浏览的特定路由（例如购物车），那么你还必须为导航实现状态恢复。

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

VeggieSeasons 示例（在下面的“其他资源”中列出）使用 go_router 软件包实现了导航。restorationId 值的设置发生在 lib/screens 类中。

要测试状态恢复，请设置你的移动设备，使其在应用进入后台后不保存状态。要了解如何在 iOS 和 Android 上执行此操作，请查阅 RestorationManager 页面上的测试状态恢复。

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

• 有关实现状态恢复的示例，请查阅 VeggieSeasons，这是一个为 iOS 编写并使用 Cupertino widget 的示例应用。iOS 应用需要在 Xcode 中进行一些额外的设置，但恢复类在 iOS 和 Android 上的工作方式相同。
  以下列表链接到 VeggieSeasons 示例的相关部分

  • 将 RestorablePropery 定义为实例属性
  • 注册属性
  • 更新属性值
  • 在 build 中使用属性值
    

• 要了解有关短期状态和长期状态的更多信息，请查阅区分瞬态状态和应用状态。

• 你可能想查看 pub.dev 上执行状态恢复的软件包，例如 statePersistence。

• 有关导航和 go_router 软件包的更多信息，请查阅导航和路由。