getApplicationContext()几乎总是错的。Hackborn女士（等等）已经非常明确，你只用getApplicationContext()当你知道为什么你使用getApplicationContext()，只有当你需要使用getApplicationContext()。

直言不讳，“某些程序员”之所以使用getApplicationContext()（或getBaseContext()程度较小）是因为他们的Java经验有限。他们实现了一个内部类（例如，in中的OnClickListenerfor ），并且需要a 。他们使用或获取对象，而不是使用“获取外部类” 。ButtonActivityContextMyActivity.thisthisgetApplicationContext()getBaseContext()Context

你只用getApplicationContext()当你知道你需要Context的东西，可以活得比其他任何可能Context您在您的处置。场景包括：

使用getApplicationContext()，如果你需要的东西绑在Context本身将具有全局作用域。我在中使用getApplicationContext()，例如，WakefulIntentService将静态WakeLock用于服务。既然这WakeLock是静态的，并且我需要Context先PowerManager进行创建，那么使用它是最安全的getApplicationContext()。

如果要通过绑定实例之间的（即绑定的句柄），则从getApplicationContext()绑定到时使用。Android会通过这些内部跟踪绑定，并保留对创建绑定的的引用。如果从绑定，则新实例将具有对的引用，而对则具有对旧的隐式引用，并且不能对旧实例进行垃圾回收。ServiceActivityServiceConnectionActivityonRetainNonConfigurationInstance()ServiceConnectionsContextsActivityActivityServiceConnectionActivityActivity

一些开发人员将自定义子类的Application用作自己的全局数据，然后通过进行检索getApplicationContext()。当然有可能。我更喜欢静态数据成员，如果出于其他原因，您只能拥有一个自定义Application对象。我使用一个自定义Application对象构建了一个应用程序，发现它很痛苦。哈克伯恩女士也同意这一立场。

以下是无论您在何处都不使用的原因getApplicationContext()：

它不是一个完整的功能Context，支持所有Activity功能。您将尝试执行的各种操作Context将失败，主要与GUI有关。

如果ContextfromgetApplicationContext()保留了您不清除的调用所创建的某些内容，则可能导致内存泄漏。使用Activity，如果它保留了某物，则一旦Activity收集到垃圾，其他所有内容也会被清除。该Application对象将在过程的整个生命周期中保留。