android-activity - 只要可以使用应用程序，为什么还要使用 bundle 软件？

Question

我正在阅读这篇关于如何：correctly retain variable state in Android的文章，我被提醒，我从来没有得到一个好的答案（在这里找不到答案），为什么最好与捆绑包（这不是一个大麻烦，但肯定有它的局限性）斗争，而不是总是在你的应用程序中覆盖一个应用程序，只需将所有持久数据成员存储在那里。是否存在泄漏风险？有没有办法让内存意外释放？我只是不清楚…它似乎是所有活动的一个完全可靠的“阁楼”，是存储任何你担心的东西的完美场所，当用户打开设备或暂停应用程序时，这些东西可能会重置。
我错了吗？我想弄清楚应用程序中内存的真实生命周期是什么。
基于下面的答案，让我扩展我的问题。
假设我有一个应用程序，它的行为与启动时加载的XML文件不同。
具体来说，该应用程序是一个用户信息收集应用程序，根据xml设置，它将遵循一个开放式的多种路径（收集信息a，而不是j，提供调查p，然后提供可选的拍照机会等）。
理想情况下，我不必将这个行为路径的细节存储在一个包（上帝禁止）或一个数据库（也很难看，但不那么难看）中。我将加载XML，对其进行处理，并让应用程序保留该结构，这样我就可以参考它了解下一步要做什么以及如何做。如果应用程序暂停并且应用程序被释放，那么检查customflow对象（根据xml生成）中的null并重新实例化它就没那么麻烦了。不管怎么说，听起来这种情况不会经常发生。这是一个很好的例子，说明应用程序是最好的工具吗？

Answer 1

至于哪种方法更好的问题，很大程度上取决于您存储了哪些信息，需要访问哪些信息，以及哪些人（哪些组件、包等）需要访问这些信息。此外，改变生命周期的设置，如launchMode和configChanges可以帮助您确定哪种方法最适合您。
首先，让我注意到，我是一个扩展应用程序对象的大倡导者，并且经常扩展应用程序类，但是在上下文中使用所有的声明，因为重要的是要理解，在某些情况下，它根本不利于。
在一个应用程序的生命周期中：Cubbad大多正确地指出，应用程序具有与单个组件相同的生命。虽然它们非常接近，但还是有一些细微的差别。应用程序本身被OS视为一个Singleton，只要任何组件都是活的，它就活着，包括一个在另一个应用程序中可能存在的超级用户（或）。
所有组件最终访问同一个对象，即使它们在多个任务或进程中。然而，这并不能保证永远保持这种方式（因为应用程序实际上不是单一的），并且只能在谷歌Android中得到保证，而不是制造商覆盖的版本。这意味着某些事情应该在应用程序对象中小心处理。
你的Application对象不会死，除非你的所有组件也被杀死。然而，android可以选择杀死任何数量的组件。这意味着永远不能保证您有一个Application对象，但是如果您的任何组件都是活动的，则可以将其关联到一个Application对象。
Application的另一个好处是它没有被外部绑定到正在运行的组件。但是，你的组件绑定到它，使它非常有用。
应用程序对象中应避免的事项：
按照惯例，避免静态Context s。事实上，通常你不应该在这里存储一个Context，因为Application本身是Context。
这里的大多数方法应该是静态的，因为不能保证得到相同的Application对象，即使它极有可能。
如果重写Application，这里的数据和方法的类型将有助于进一步确定是否需要创建一个单独组件。
Drawables及其衍生物最容易被“泄漏”，如果不注意，也建议你避免引用Drawables这里。
任何单个组件的运行时状态。这是因为，同样，您不能保证返回相同的Application对象。此外，在Activity中发生的生命周期事件在此处都不可用。
要存储在应用程序中的内容（通过捆绑）
Application是存储组件之间必须共享的数据和方法的一个非常棒的地方，尤其是如果您有多个入口点（可以启动的多个组件，并且从启动活动中退出）。例如，在我所有的Applications中，我放置调试标记和日志代码。
如果你有一个内容提供者或广播接收器，这使得Application更理想，因为它们有小的生命周期，它们不像Activity或AppWidgetProvider的“可更新”，现在可以访问这些数据或方法。
首选项通常用于确定多个运行的运行选项，因此这是处理SharedPreferences的好地方，例如，使用一个访问而不是每个组件一个访问。事实上，任何在多次运行中“坚持”的东西在这里都是很好的。
最后，一个被忽略的主要优点是，您可以在这里存储和组织常量，而无需加载另一个类或对象，因为如果您的组件之一是，那么您的Application总是在运行。这对于意图操作、异常消息和其他类似类型的常量尤其有用。
要捆绑存储而不是应用程序存储的内容
依赖于单个组件或单个组件运行的存在或状态的运行时状态。此外，任何依赖于显示状态、定位或类似Android服务的任何东西在这里都不可取。这是因为Application从未收到这些更改的通知。最后，任何依赖于android系统通知的东西都不应该放在这里，比如对生命周期事件的反应。
还有…别处
对于需要持久化的其他数据，您始终拥有数据库、网络服务器和文件系统。像往常一样使用它们。
正如《资本论》那样有用和被忽视，一个好的理解很重要，因为它并不理想。希望，这些澄清会让你稍微理解为什么古鲁鼓励一种方式胜过另一种方式。要知道，许多开发人员都有类似的需求，而且大多数指导都是基于大多数社区所拥有的技术和知识。谷歌所说的不适用于所有程序员的需求，并且有一个原因，即应用程序没有被声明为“cc>”。
记住，Android需要能够杀死你的组件是有原因的。主要原因是内存，而不是处理。通过使用如上所述的应用程序和开发适当的方法来保存适当的信息，您可以构建更为系统、用户、其兄弟组件和其他开发人员所考虑的更强大的应用程序。利用这里每个人提供的信息应该给你一些关于如何以及何时扩展你的Application的很好的指导。
希望能帮上忙，
绒毛状