何时使用或不使用Android应用程序类？

Question

我考虑使用android Application类作为存储临时状态和其他（片段）活动中共享代码的地方。

我想获得更多反馈，以确定它是否适合于以下用途：

1. 共享常量，如ID、偏好键名等。
2. 反映当前UI状态、导航、选定片段等全局变量（即setter/getter），以及一般不需要持久化的临时数据。
3. 在触发某些条件时，挂钩以持久化数据。
4. 在首选项更改后更新UI。
5. 提供一种轻松访问应用程序中任何位置的上下文的方法，包括在没有 getApplication（）的代码中，例如通过静态getter MyApp.getApp（）。
6. 需要全局状态变量可见性的常见方法，并且将这些方法移动到专用类中会变得过于繁琐。

除此之外，在活动类中还有哪些适合/有用/方便的内容？什么不适合保存在其中，有什么最佳替代方案？最后，在您的应用程序中，您发现Application最适合用于什么？

- ccpizza

---

将“-1”展开，因为该帖子有许多好问题，其他用户也会受益。 :) - karllindmark

Answer 1

共享常量，如ID、偏好键名等。

通常我会创建一个名为C的常量文件，因为这样更易于阅读。在我看来，C.SHARED_PREFS比Application.SHARED_PREFS更容易理解。

反映当前UI状态、导航、选择的片段以及一般临时数据（不需要持久化）的全局变量（即设置器/获取器）。

最好将其放在涉及到它的Activity或组件中（例如，Activity的UI状态应该存储在icicle bundle中或在该Activity实例中）。

在触发某些条件时钩子持久化数据。

这应该没问题。

在首选项更改后更新UI。

同样，我认为这应该放在相应的组件中。

提供一种方便的方式，在应用程序中的任何位置访问上下文，包括无法使用getApplication()的代码，例如通过类似MyApp.getApp()的静态getter。

这样可以工作，但要小心内存泄漏。通常情况下，当从Activity或Service或其他地方调用方法时，应将上下文作为参数传递。减少内存泄漏的机会。

需要全局状态变量的可见性的常见方法，如果移动到专用类中将变得太麻烦。

我认为最好还是努力创建专用类，因为当您的应用程序功能和大小增长时，这将变得难以维护。

- Raghav Sood

---

涉及的“activity”实际上是一个ViewPager，包含多个FragmentActivity页面 - 因此需要保持状态并允许片段之间进行通信。在我看来，在这种情况下使用事件会过度。 - ccpizza

Answer 2

可能是某个地方可以附加特定的钩子。

例如，如果您使用ACRA崩溃报告库，只需使用应用程序类，因为这是ACRA所附加的位置。这就是我开始使用这个类的原因；我以前从未需要过这个类。

- Audrius Meškauskas