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方法中使用 mixin 注册这些 widget。

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

其他注意事项

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

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

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

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

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

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

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

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

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

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

• 您可能需要查看 pub.dev 上执行状态恢复的插件，例如statePersistence。

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

除非另有说明，否则本网站上的文档反映了 Flutter 的最新稳定版本。页面上次更新于 2024-06-04。 查看源代码 或 报告问题.