存储状态和恢复状态是 Android 中的一个主要问题，简单的任务很复杂，因为它建议应该存储和恢复状态（使用Intents、Parcelables 等），并且由于线程问题（使用AsyncTaskLoaders、LoaderManagers、等等。）。
但是，据我了解，static变量会在整个过程中持续存在（这里与应用程序运行有关），并且通过这些static变量存储状态和汇集线程要容易得多。
当然，如果进程被杀死，状态会丢失，但是在前台运行的应用程序实际上多久会发生这种情况？
进一步维护状态很好，但对大多数应用程序来说并不重要，尤其是在很少丢失状态的情况下。
此外，如果状态对您至关重要，则可能不应该使用Activity生命周期提供的函数来存储和恢复该状态，因为不能保证在进程被终止时会调用它们，而是应该不断存储您在某个数据库中的状态。
我认为推荐的方法过于矫枉过正，并且不必要地使大多数应用程序的开发过于复杂，其接受的原因是什么？
当然，如果进程被杀死，状态会丢失，但是在前台运行的应用程序实际上多久会发生这种情况？
根据定义，绝不会出现电池耗尽、用户关闭设备等情况。
但是，您并不经常处于前台，并且可能不会在那里停留很长时间，具体取决于用户所做的事情。
进一步维护状态很好，但对大多数应用程序来说并不重要，尤其是在很少丢失状态的情况下。
丢失状态经常发生，因为应用程序不会经常或不一定长时间处于前台。
此外，如果状态对您至关重要，则可能不应该使用 Activity 生命周期提供的函数来存储和恢复该状态，因为不能保证在进程被终止时会调用它们，而是应该不断地将您的状态存储在某个数据库中。
生命周期方法不适用于那种状态。它们用于数据，这些数据应该尽可能地保留以简化用户导航（例如，处理方向更改），但不需要持久（应该放在持久存储中）。
打个比方，当您在此 StackOverflow 页面中输入问题时，您输入的内容不需要保存到 Web 服务器，直到您提交表单。但是，当您在浏览器选项卡之间切换或最小化（然后恢复）浏览器窗口时，您的 Web 浏览器当然应该保留这些数据。而且，您的 Web 浏览器甚至可能将这些数据保存在某个临时文件中，它们还保存打开的选项卡列表，因此如果您的浏览器崩溃，它们可以尽可能地恢复您的状态。“存储在 Web 服务器上的内容”、“存储在进程堆中的内容”和“存储在本地文件系统的临时位置上的内容”之间的区别决定了哪些类型的数据与这些策略相关联。
类似地，在 Android 中，“存储在静态数据成员中的内容”、“通过Intentextra 等传递的内容”和“存储在持久点（如数据库）中的内容”之间的区别决定了哪些类型的数据是与这些策略联系在一起。
它被接受的原因是什么？
因为您的方法往往会导致内存泄漏，除非非常小心地处理静态缓存。
而且，因为您的方法混淆了真正的全局数据和逻辑上属于某些离散操作的数据之间的区别，因此应该通过Intent额外或其他特定于操作的方式传递。
这些是静态数据成员在 Java 中被视为不良形式的所有其他经典原因的补充。