在 Android 上恢复状态
当用户运行一个移动应用,然后选择运行另一个应用时,第一个应用会被移动到后台,或称之为后台化。操作系统(iOS 和 Android 均是如此)可能会终止后台应用以释放内存并提高前台应用的性能。
当用户再次选择该应用,将其带回前台时,操作系统会重新启动它。但是,除非你已经设置了在应用被终止前保存其状态的方法,否则你将丢失状态,应用会从头开始。用户失去了他们所期望的连续性,这显然不理想。(想象一下填写一个冗长的表单,却在点击提交前被电话打断。)
那么,如何才能恢复应用的状态,使其看起来就像被发送到后台之前那样呢?
Flutter 提供了解决方案,即 RestorationManager
(和相关类)在 services 库中。借助 RestorationManager
,Flutter 框架会随着状态变化将状态数据提供给引擎,这样当操作系统发出即将终止应用的信号时,应用就能做好准备,因为留给应用准备的时间只有几秒。
概述
#你只需完成几项任务即可启用状态恢复
为所有支持状态恢复的 widget 定义
restorationId
或restorationScopeId
,例如TextField
和ScrollView
。这会自动为这些 widget 启用内置状态恢复。对于自定义 widget,你必须决定要恢复哪些状态,并将这些状态保存在
RestorableProperty
中。(Flutter API 为不同的数据类型提供了各种子类。)在使用了RestorationMixin
的State
类中定义这些RestorableProperty
widget。在restoreState
方法中,将这些 widget 与 mixin 进行注册。如果你使用了任何 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 示例的相关部分要了解有关短期状态和长期状态的更多信息,请查阅区分瞬态状态和应用状态。
你可能想查看 pub.dev 上执行状态恢复的软件包,例如
statePersistence
。有关导航和
go_router
软件包的更多信息,请查阅导航和路由。