android - 何时调用 Activity 上下文或应用程序上下文？

Question

关于这两种情况的帖子已经有很多了。但我仍然没有完全正确

据我所知: 每个都是其类的一个实例，这意味着一些程序员建议您尽可能频繁地使用 this.getApplicationContext() 以免“泄漏”任何内存。这是因为另一个 this(获取 Activity 实例上下文)指向一个 Activity，每次用户倾斜手机或离开应用程序等。显然垃圾收集器(GC)没有捕获，因此使用了太多内存..

但是任何人都可以提出一些非常好的编码示例，其中使用 this 是正确的(获取当前 Activity 实例的上下文)和应用程序上下文将无用/错误？

Answer 1

getApplicationContext() 几乎总是错误的。 Ms. Hackborn (除其他外)非常明确地表明，您仅在您知道为什么您正在使用 getApplicationContext()< 时才使用 getApplicationContext()/code> 并且仅当您需要 使用 getApplicationContext()。

坦率地说，“一些程序员”使用 getApplicationContext()(或 getBaseContext()，在较小程度上)是因为他们的 Java 经验有限。他们实现了一个内部类(例如，Activity 中的 Button 的 OnClickListener)并且需要一个 Context。他们不是使用 MyActivity.this 来获取外部类的 this，而是使用 getApplicationContext() 或 getBaseContext() 来获取一个 Context 对象。

你只有在你知道你需要一个Context的时候使用getApplicationContext()来做一些可能更长寿的事情比您可以使用的任何其他可能的Context。场景包括:

• 如果您需要与本身具有全局范围的 Context 相关联的东西，请使用 getApplicationContext()。我使用 getApplicationContext()，例如，在 WakefulIntentService 中，将静态 WakeLock 用于服务。由于 WakeLock 是静态的，我需要一个 Context 来获取 PowerManager 来创建它，因此使用 getApplicationContext( ).

• 当您从 Activity 绑定(bind)到 Service 时，如果您希望传递 ，请使用 getApplicationContext()通过 onRetainNonConfigurationInstance() 在 Activity 实例之间的 ServiceConnection(即绑定(bind)句柄)。 Android 通过这些 ServiceConnections 在内部跟踪绑定(bind)，并保存对创建绑定(bind)的 Contexts 的引用。如果您从 Activity 绑定(bind)，那么新的 Activity 实例将具有对 ServiceConnection 的引用，该引用具有对旧 Activity，旧的Activity不能被垃圾回收。

一些开发人员将 Application 的自定义子类用于他们自己的全局数据，他们通过 getApplicationContext() 检索这些数据。这当然是可能的。我更喜欢静态数据成员，如果没有其他原因，您只能拥有 one 自定义 Application 对象。我使用自定义 Application 对象构建了一个应用程序，发现它很痛苦。 Ms. Hackborn also agrees with this position .

以下是不在任何地方都使用getApplicationContext()的原因:

• 它不是一个完整的Context，支持Activity所做的一切。你试图用这个 Context 做的各种事情都会失败，mostly related to the GUI .

• 如果 getApplicationContext() 中的 Context 保留了您对其调用所创建的内容，但您没有清理该内容，则它会造成内存泄漏。对于Activity，如果它持有某物，一旦Activity 被垃圾回收，其他所有东西也会被清除。 Application 对象在您的进程的生命周期内保留。