"persistent state" vs. "current state"

试图决定（对于我的应用程序）在onPause（）中保存什么以及在onSaveInstanceState（）中保存什么，我梳理了整个SO以获取提示和明确的指南。

如果我理解正确，onSaveInstanceState（）最适合保存"运行时更改"或"当前状态"（无论这意味着什么），而 onPause（）最适合保存"持久状态"（无论这意味着什么）。

我仍然难以确定我的应用程序中什么构成"持久状态"与"当前状态"。例如，虽然用户首选项显然是持久的，但当用户更改它们时，Android UI 框架始终自动保存它们时，我是否需要将它们保存在 onPause() 中？

类数据成员是否需要保存在 onSaveInstanceState（）中？我是否需要为申请中的每个类执行此操作？

我很困惑。

你能举出真实世界的例子，说明什么必须在onPause()中保存，什么必须在onSaveInstanceState()中保存吗？除了设备配置更改，也就是说。

在我的

问题得到回答后，一些新的见解：

您不需要在onPause中存储用户首选项，因为正如您所说，框架会为您执行此操作。

若要区分持久性数据与状态信息，请考虑文本编辑器应用程序。

持久数据

假设用户键入了几个单词，然后退出应用。用户没有明确告诉我们将数据保存到文件中，但是将这些数据存储起来以备他们回来时肯定会很好。这是持久性数据，您希望将其存储在 onPause（）中。

状态数据

同样，假设您有 2 个选项卡和一个跟踪当前选择的选项卡的变量。这是存储在 onSaveInstanceState（）中的状态数据。

灰质

最后，假设您在编辑器中有一个类，用于跟踪编辑器中的字符数和行数。这是状态数据，您可以将其存储在 onSaveInstanceState（）中，也可以将其丢弃并在再次启动时重新计算它。是否丢弃它可能取决于计算所需的时间，例如，如果可以通过存储数据来阻止网络请求，请这样做。

进一步的想法

通过玩你的应用程序，应该很明显，如果有一个区域你未能清理正确的数据。请务必执行诸如点击主页按钮之类的操作，然后从设备管理器中关闭您的应用程序。这将让你遇到应用关闭而不仅仅是暂停的极端情况。

如果您的 UI 状态在生命周期事件中保持一致，并且您的用户数据保持不变，那么工作很好。

根据评论进行编辑

我认为这里有 2 个标准来确定何时/保存什么。

第一个是相当主观的 - 你想保存数据吗？实际上没有什么可以强制您保存状态或数据。保存此信息是否有助于更好的用户体验？如果您正在编写电子邮件并尝试从另一个应用程序复制/粘贴文本，那么每次应用程序关闭时丢失半输入的电子邮件都会令人沮丧。

第二部分，确定要保存的内容取决于是否可以根据拥有的数据重建 UI 状态。例如，如果您保存了文本数据，那么这必须意味着用户正在编辑文本。所以现在我们知道切换到编辑文本选项卡并填写保存的文本。

一般来说，如果希望将用户返回到他们离开的同一位置，那么需要考虑返回到该点所需的状态数据。想象您的应用程序的原始加载版本

这就是 android 的真正工作方式，您的活动被销毁并重新创建，您的工作是再次启动这些部分（如果您选择这样做）。

这是答案。您可以通过三种不同的方式保存状态。

1）子类化应用程序（不是一个好主意）。2）共享首选项（适用于简单的数据，快速可靠）3）SQLite数据库（更复杂，也可靠）。

现在回答你的问题。安卓真的没有保证。在任何时候，它都可以并且可能销毁您的应用程序，而无需在执行此操作之前调用任何特定函数。因此，如果有需要保存至关重要的数据，答案是在获得数据后立即保存。以后保存某些内容通常没有太大优势，如果您知道您将需要立即保存某些内容。

onSaveInstanceState（）仅用于保存与布局或方向更改相关的临时变量。

总之，持久状态/数据（应该在崩溃中幸存下来）应该尽快保存，不要等待onPause()，因为没有保证。这就是现实。

我的情况是一个游戏，我想将持久数据保存到游戏服务器。

由于这可能需要一段时间，我发现尝试在onPause中保存不是一件好事，而是在onStop中保存。

根据我所做的测试，onStop似乎能够在onPause块时在后台运行，至少当我按 home 时是这样（使用简单的 for 1 在 onPause 和 onStop 中10m循环进行测试）。谁能证实这个阻塞理论？

onStop需要Honeycomb（api11+），因为在那个版本之前，你可以在onClose被调用之前被杀死。

请参阅此处并在表中查找killable - 如果现实与文档匹配是:)的另一个问题。

相关内容