多个类扩展Application

Question

两个类扩展Application

• 第一个类我已经在清单中注册并且将其用作Application，它是为了...
• 第二个类是我的实用程序类。它执行大量的I/O操作，并有一些辅助方法。对于I/O，您需要上下文（例如getAssets等），因此我不情愿地扩展了Application。

注意：

一切都正常。

我的问题：

使用多个Application类有什么缺点？这是否被建议？

几点想法：

• 如果两个类中都定义了onCreate和其他回调方法，会发生什么？
• 如何在清单中同时注册它们呢？等等。

附注：我知道我可以只使用字段来存储第二个类中的上下文。

- Dheeraj Bhaskar

---

缺失的是：为什么要扩展Application，而不是创建自己的静态单例来实现帮助方法？如果需要上下文，则只需使用getApplicationContext或实现类似setHelperContext()的东西。如果您只有一个应用程序实例，则这是完全安全的，因为没有任何内容的生命周期大于应用程序上下文。只有在传递Activity上下文（有泄漏风险）时才会出现问题，但是帮助程序类不应该触及Activity资源。 - Simon

为什么，先生？我问为什么不呢？好啦，认真点：）我只是想它会起作用，并且有点起了作用。我需要上下文和其他一些东西，不想为每个字段都创建字段。就像你说的，我本可以创建一个单例并传递上下文。我甚至没有触及活动上下文，在这里我使用了getApplicationContext。帮助类正在帮助进行IO操作，因此它正在操作资源。 - Dheeraj Bhaskar

Answer 1

我认为这样做不太明智，因为应用程序中只能有一个实例(因此只能有一个类)。

我非常怀疑这是真正起作用的。您正在谈论实用程序类，因此可能正在使用良好的静态方法。但是您应该使用调试器，我几乎可以肯定，您会发现其中一个类从未被实例化。

顺便说一下，官方文档指出：

"通常不需要子类化Application。在大多数情况下，静态单例可以以更模块化的方式提供相同的功能。如果您的单例需要全局上下文(例如注册广播接收器)，则可以给检索它的函数提供内部使用Context.getApplicationContext()构造单例时的上下文。"

- Orabîg

---

是的，我在实用类中使用静态方法。正在正常工作的是需要上下文的IO方法（如果类未实例化，这里如何管理上下文？...有趣）。 - Dheeraj Bhaskar

我很好奇。不同任务中的多个活动实例不被视为应用程序的多个实例吗？ - Dheeraj Bhaskar

我理解Activity和Application是不同的类。但是这两个任务中的上下文和全局变量会非常不同，对吧？这意味着需要两个应用程序实例。 - Dheeraj Bhaskar

我没有使用this，但我正在使用getAssets()和getApplicationContext()。这两个以及类似的getter必须是单例的一部分，才能正常工作。这样对吗？ - Dheeraj Bhaskar

我指的是getApplicationContext()和getAssets()必须是单例模式的一部分，返回ApplicationContext和Assets实例的方法。我之所以这么说是因为这似乎可以在不实例化第二个应用程序的情况下工作。这些单例必须在第一个应用程序类初始化时被初始化。 - Dheeraj Bhaskar