存储状态和恢复状态是Android中的一个主要问题，简单的任务很复杂，因为它建议应该存储和恢复状态（使用Intent s，Parcelable等等）并且通过线程问题（使用AsyncTaskLoader，LoaderManager等）进一步复杂化。
但是，据我了解，static变量会持续存在一个流程（此处与应用程序运行相关），并且通过这些static变量存储状态和漏斗线程非常容易。
当然，如果进程被杀，状态将会丢失，但是这种情况经常发生在前台运行的应用程序中？
进一步维护状态很好但对大多数应用程序并不重要，特别是如果失去状态很少。
此外，如果状态为 对您至关重要，则可能不应使用Activity生命周期提供的功能来存储和恢复该状态，因为无法保证它们将在进程被终止时调用，而不是将您的状态存储在某个数据库中。
我认为推荐的方法是过度的，并且不必要地使大多数应用程序的开发过于复杂，接受它的原因是什么？
答案 0 :(得分：0)
当然，如果进程被终止，状态将会丢失，但这种情况多久发生在前台运行的应用程序中？
根据定义，永远不会，电池没电，用户关闭设备等等。
但是，你不是很在前台，可能不会在那里停留很长时间，具体取决于用户的行为。
进一步维护状态很好但对大多数应用程序并不重要，特别是如果失去状态很少。
失败状态非常频繁地发生，因为应用程序不经常或不一定很长时间处于前台。
此外，如果状态对您至关重要，则可能不应该使用Activity生命周期提供的函数来存储和恢复该状态，因为无法保证在进程被终止时将调用它们，而是应该不断地将你的状态存储在某个数据库中。
生命周期方法不适用于那种状态。它们用于存储应尽可能简化用户导航的数据（例如，处理方向更改），但不需要持久（应该在持久存储中）。
要进行类比，当您在此StackOverflow页面中键入问题时，在您提交表单之前，您输入的内容不需要保存到Web服务器。但是，当您在浏览器选项卡之间切换时，或者最小化（以及稍后还原）浏览器窗口时，Web浏览器应该保留此数据。而且，您的Web浏览器甚至可能会在某个临时文件中保留此数据，其中它们还包含打开的选项卡列表，这样，如果您的浏览器崩溃，它们可以尽可能地恢复您的状态。 “存储在Web服务器上的内容”，“存储在进程堆中的内容”和“存储在本地文件系统中的临时位置”之间的区别决定了哪些类型的数据与这些策略相关联。
同样，在Android中，“存储在静态数据成员中的内容”，“通过Intent附加内容传递的内容之类”之间的差异，以及“存储在持久点中的内容，如数据库“确定哪些数据与这些策略相关联。
接受它的原因是什么？
因为您的方法往往会导致内存泄漏，除非非常小心地处理静态缓存。
并且，因为您的方法混淆了真正的全局数据和逻辑上属于某些离散操作的数据之间的区别，因此应该通过Intent附加内容或其他特定于操作的方式传递。
除了静态数据成员在Java中被认为是不良形式的所有其他经典原因之外，还有其他原因。