试图决定（对于我的应用程序）在onPause()中保存什么以及在onSaveInstanceState()中保存什么，我梳理了整个 SO 以获得提示和明确的指导方针。
如果我理解正确，onSaveInstanceState()最适合保存“运行时更改”或“当前状态”（无论这意味着什么），而onPause()最适合保存“持久状态”（无论这意味着什么）。
我仍然难以确定我的应用程序中的“持久状态”与“当前状态”。例如，虽然用户偏好显然是持久的，onPause()但当用户更改它们时，Android UI 框架总是自动保存它们时，我是否需要保存它们？
类数据成员是否需要保存在onSaveInstanceState()中？我需要为我的应用程序中的每个课程都这样做吗？
我很困惑。
你能举出真实世界的例子来说明什么必须保存onPause()和什么必须保存onSaveInstanceState()吗？除了设备配置更改外，就是这样。
--
在我的问题得到回答后，一些新的见解：
您不需要在 onPause 中存储用户首选项，因为正如您所说，框架会为您执行此操作。
要区分持久数据与状态信息，请考虑一个文本编辑器应用程序。
持久数据
假设用户输入了几个单词，然后退出了应用程序。用户没有明确告诉我们将这些数据保存到文件中，但是当他们回来时将这些数据存储起来肯定会很好。这是持久数据，您希望将其存储在 onPause() 中。
状态数据
同样，假设您有 2 个选项卡和一个跟踪当前选择的选项卡的变量。这是您将存储在 onSaveInstanceState() 中的状态数据。
灰质
最后假设您在编辑器中有一个类，用于跟踪编辑器中的字符数和行数。这是状态数据，您可以将其存储在 onSaveInstanceState() 中，也可以将其丢弃并在重新启动时重新计算。是否丢弃它可能取决于计算需要多长时间，例如，如果您可以通过存储数据来阻止网络请求，那么就这样做。
进一步的想法
通过使用您的应用程序，您应该很明显是否有一个区域您未能存储正确的数据。请务必执行诸如点击主页按钮然后从设备管理器中关闭您的应用程序之类的操作。这将让您遇到应用程序关闭而不是暂停的极端情况。
如果您的 UI 状态在整个生命周期事件中保持一致并且您的用户数据仍然存在，那么做得很好。
根据评论编辑
我认为这里有两条标准来确定何时/保存什么。
第一个是相当主观的——你想保存数据吗？确实没有什么可以强迫您保存状态或数据。保存这些信息会带来更好的用户体验吗？如果您正在编写电子邮件并尝试从另一个应用程序复制/粘贴文本，那么每次应用程序关闭时丢失您输入一半的电子邮件会令人沮丧。
第二部分，确定要保存的内容取决于您是否可以根据您拥有的数据重建您的 UI 状态。例如，如果您保存了文本数据，那么这一定意味着用户正在编辑文本。所以现在我们知道切换到编辑文本选项卡并填写保存的文本。
一般来说，如果您希望将用户返回到他们离开的地方，那么您需要考虑返回该点所需的状态数据。想象一下您的应用程序的原始加载版本
这确实是 android 的工作方式，您的活动被销毁并重新创建，您的工作是再次启动这些部分（如果您选择这样做）。
这是答案。您可以通过三种不同的方式保存状态。
1）子类化应用程序（不是一个好主意）。2）SharedPreferences（适用于简单数据，快速可靠） 3）SQLite 数据库（更复杂，也更可靠）。
现在回答你的问题。android真的没有保证。在任何时候，它都可以并且可能在不调用任何特定函数的情况下破坏您的应用程序。因此，如果有重要的数据需要保存，答案是一拿到就保存。如果您知道需要立即保存某些东西，那么稍后保存通常没有太大的优势。
onSaveInstanceState() 仅用于保存与布局或方向更改相关的临时变量。
总之，持久状态/数据（应该在崩溃中幸存），应该尽快保存，不要等待onPause()，因为没有保证。这就是现实。
我的案例是一个游戏，我想将持久性数据保存到游戏服务器。
由于这可能需要一段时间，我发现尝试保存在 中并不是一件好事onPause，而是在onStop.
根据我所做的测试，onStop似乎能够在后台运行 whileonPause块，至少当我按下 home 时就是这种情况（使用简单的 for1循环10m和onPause测试onStop）。谁能证实这个阻塞理论？
onStop需要Honeycomb（api11+），因为在那个版本之前你可以在onClose被调用之前被杀死。
请参阅此处并killable在表格中查找 - 如果现实与文档匹配是另一个问题:)。