当您可以只使用应用程序时，为什么要使用捆绑包？

Question

我正在阅读这篇关于如何：在 Android 中正确保留变量状态的文章，我被提醒我从来没有得到一个好的答案（并且在这里找不到），为什么最好与 Bundle（哪个不是一个巨大的麻烦，但肯定有其局限性）而不是总是在您的应用程序中覆盖一个应用程序，并将所有持久数据成员存储在那里。是否存在泄漏风险？有没有办法可以意外释放内存？我只是不清楚这一点......它似乎是所有活动的完全可靠的“阁楼”，并且是存储您担心在用户转动设备或暂停时可能会重置的任何内容的理想场所应用程序。

我错了吗？很想弄清楚应用程序中内存的真实生命周期是什么。

---

根据下面的答案，让我扩展我的问题。

假设我有一个基于它在启动时加载的 XML 文件而表现不同的应用程序。

具体来说，该应用程序是一个用户信息收集应用程序，根据 XML 设置，它将遵循开放式的各种路径（收集信息 A，但不收集 J，并提供调查 P，然后是可选的拍照机会等）。

理想情况下，我不必将此行为路径的详细信息存储在 Bundle（上帝保佑）或数据库（也很丑，但不那么重要）中。我将加载 XML，对其进行处理，并使应用程序保留该结构，以便我可以参考它以了解下一步要做什么以及如何做。如果应用程序被暂停并且应用程序被释放，那么检查我的 CustomFlow 对象（根据 XML 生成）中的 null 并重新实例化它并不是一件大事。无论如何，听起来这种情况不会经常发生。这是应用程序是*最佳工具的一个很好的例子吗？

Answer 1

关于哪种方法更好的问题在很大程度上取决于您正在存储和需要访问哪些信息以及谁（哪些组件、包等）需要访问该信息。此外，诸如改变生命周期launchMode和configChanges改变生命周期的设置可以帮助您确定哪种方法最适合您。

首先，让我注意，我大力提倡扩展 Application 对象并经常扩展 Application 类，但是将这里陈述的所有内容放在其上下文中，因为了解在某些情况下它根本没有好处很重要。

关于应用程序的生命周期： Chubbard 大部分正确地指出应用程序与单例组件具有相同的生命周期。虽然它们非常接近，但还是有一些细微的差别。应用程序本身被操作系统视为单例，并且只要任何组件处于活动状态，包括 AppWidget（可能存在于另一个应用程序中）或 ContentResolver 就一直处于活动状态。

您的所有组件最终都会访问同一个对象，即使它们位于多个任务或进程中。但是，这不能保证永远保持这种方式（因为应用程序实际上不是单例），并且仅在 Google Android 中得到保证，而不是制造商覆盖的版本。这意味着在应用程序对象中应该小心处理某些事情。

Application除非您的所有组件都被杀死，否则您的对象不会死亡。但是，Android 可以选择终止任意数量的组件。这意味着你永远不能保证有一个Application对象，但如果你的任何组件是活动的，就有一个Application可以将它关联到。

另一个Application好处是它不能与正在运行的组件分离。但是，您的组件绑定到它，使其非常有用。

在应用程序对象中要避免的事情：

• 按照惯例，避免 static Contexts。事实上，通常情况下，您根本不应该将 a 存储Context在这里，因为ApplicationaContext本身就是。
• 这里的大多数方法应该是静态的，因为你不能保证得到相同的Application对象，即使它极有可能。
• 如果您覆盖Application，您在这里存储的数据和方法的类型将帮助您进一步确定是否需要制作单例组件。
• Drawables如果不注意，它的衍生物最有可能“泄漏”，因此也建议您避免引用Drawables此处。
• 任何单个组件的运行时状态。这是因为，您不能保证取回相同的Application对象。此外，这里没有发生在 中的生命周期事件Activity。

要存储在应用程序中的东西（通过 Bundle）

这Application是一个很棒的地方来存储必须在组件之间共享的数据和方法，特别是如果您有多个入口点（多个组件可以在启动活动之外启动和运行）。Application例如，在我的所有s 中，我都放置了 DEBUG 标记和日志代码。

如果您有 ContentProvider 或 BroadcastReceiver，这将Application更加理想，因为它们的生命周期较短，不像Activityor那样“可再生” AppWidgetProvider，现在可以访问这些数据或方法。

首选项通常用于确定多次运行的运行选项，因此这可能是处理您的 的好地方SharedPreferences，例如，一次访问而不是每个组件一个。事实上，任何在多次运行中“持续存在”的东西都可以在这里访问。

最后，一个被忽视的主要优势是您可以在此处存储和组织您的常量，而无需加载另一个类或对象，因为Application如果您的一个组件正在运行，您将始终在运行。这对于意图操作和异常消息以及其他类似类型的常量特别有用。

要存储在 Bundle 中的东西，而不是 依赖于单个组件或单个组件运行的存在或状态的应用程序运行时状态。此外，这里不推荐任何依赖于显示状态、方向或类似 Android 服务的内容。这是因为Application从未通知这些更改。最后，任何依赖于该 Android 系统通知的内容都不应该放在这里，例如对生命周期事件的反应。

还有……别处

对于需要持久化的其他数据，您始终拥有数据库、网络服务器和文件系统。像往常一样使用它们。

尽管有用和被忽视，但Application良好的理解很重要，因为它并不理想。希望这些澄清能让您对为什么大师鼓励一种方式而不是另一种方式有所了解。了解许多开发人员有类似的需求，并且大多数指导都是基于社区中大多数人拥有的技术和知识。谷歌所说的没有任何内容适用于所有程序员的需求，并且没有声明应用程序是有原因的Final。

请记住，Android 需要能够杀死您的组件是有原因的。主要原因是内存，而不是处理。通过使用上述应用程序并开发适当的方法来保存适当的信息，您可以构建更强大的应用程序，这些应用程序考虑到系统、用户、其兄弟组件和其他开发人员。利用这里每个人提供的信息应该会给你一些很好的指导，告诉你如何以及何时扩展你的Application.

希望这会有所帮助， FuzzicalLogic