在 Android 上恢复状态
当用户运行移动应用然后选择另一个应用运行时,第一个应用会被移到后台,或称为“后台化”。操作系统(iOS 和 Android)可能会终止后台应用以释放内存并提高前台应用的性能。
当用户再次选择该应用,将其带回前台时,操作系统会重新启动它。但是,除非您设置了在应用被终止前保存应用状态的方法,否则您将丢失状态,应用将从头开始。用户将失去他们期望的连续性,这显然不是理想的。(想象一下,在填写一个冗长的表单后,在点击 **提交** *之前* 接到了一个电话。)
那么,如何恢复应用的状态,使其看起来与后台化之前一样呢?
Flutter 在 services 库中提供了 RestorationManager
(及相关类)来解决这个问题。通过 RestorationManager
,Flutter 框架会在状态改变时将状态数据提供给引擎,以便在操作系统发出即将终止应用的信号时,应用已准备就绪,只给应用几秒钟的准备时间。
概述
#只需几个步骤即可启用状态恢复
为所有支持的 widget(如
TextField
和ScrollView
)定义一个restorationId
或restorationScopeId
。这会自动为这些 widget 启用内置的状态恢复。对于自定义 widget,您必须决定要恢复哪些状态,并将该状态保存在
RestorableProperty
中。(Flutter API 提供了各种适用于不同数据类型的子类。)在使用了RestorationMixin
的State
类中定义这些RestorableProperty
widget。在restoreState
方法中向 mixin 注册这些 widget。如果您使用任何 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”)。例如,用 restorablePush
替换 push
。
VeggieSeasons 示例(在下面的“其他资源”下列出)使用 go_router
包实现导航。restorationId
值的设置发生在 lib/screens
类中。
测试状态恢复
#要测试状态恢复,请设置您的移动设备,使其在应用后台化时不会保存状态。要了解如何在 iOS 和 Android 上执行此操作,请查看 RestorationManager
页面上的 测试状态恢复。
其他资源
#有关状态恢复的更多信息,请参阅以下资源
有关实现状态恢复的示例,请查看 VeggieSeasons,这是一个为 iOS 编写的示例应用,使用了 Cupertino widgets。iOS 应用在 Xcode 中需要一些额外的设置,但恢复类在 iOS 和 Android 上使用方式基本相同。
以下列表链接到 VeggieSeasons 示例的相关部分要了解有关短期和长期状态的更多信息,请参阅 区分临时状态和应用状态。
您可能想查看 pub.dev 上的执行状态恢复的软件包,例如
statePersistence
。有关导航和
go_router
包的更多信息,请参阅 导航和路由。