比较getApplication()和getApplicationContext()。

getApplication返回一个Application对象，它将允许你管理你的全局应用程序状态，并响应一些设备情况，如onLowMemory()和onConfigurationChanged()。

getApplicationContext returns the global application context - the difference from other contexts is that for example, an activity context may be destroyed (or otherwise made unavailable) by Android when your activity ends. The Application context remains available all the while your Application object exists (which is not tied to a specific Activity) so you can use this for things like Notifications that require a context that will be available for longer periods and independent of transient UI objects.

我想这取决于你的代码在做什么——尽管在正常使用中，我希望它们是不同的。

要回答这个问题，getApplication()返回一个Application对象，getApplicationContext()返回一个Context对象。根据您自己的观察，我假设两者的上下文是相同的(即在幕后，应用程序类调用后一个函数来填充基类的上下文部分或进行一些等效的操作)。如果你只是需要一个Context，那么调用哪个函数并不重要。

非常有趣的问题。我认为这主要是语义上的意思，也可能是由于历史的原因。

虽然在当前的Android Activity和Service实现中，getApplication()和getApplicationContext()返回相同的对象，但不能保证总是如此(例如，在特定的供应商实现中)。

因此，如果您想要在Manifest中注册的Application类，您永远不应该调用getApplicationContext()并将其强制转换为您的应用程序，因为它可能不是应用程序实例(您显然在测试框架中经历过)。

为什么getApplicationContext()首先存在?

getApplication()只在Activity类和Service类中可用，而getApplicationContext()在Context类中声明。

这实际上意味着一件事:当在广播接收器中编写代码时，它不是一个上下文，但在其onReceive方法中提供了一个上下文，您只能调用getApplicationContext()。这也意味着您不能保证能够访问BroadcastReceiver中的应用程序。

当查看Android代码时，你会看到当附加时，一个活动接收一个基本上下文和一个应用程序，这是不同的参数。getApplicationContext()将它的调用委托给baseContext.getApplicationContext()。

还有一件事:文档说在大多数情况下，你不需要子类化Application:

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

我知道这不是一个确切的答案，但是，这是否回答了你的问题?

这似乎与上下文包装有关。从Context派生的大多数类实际上是一个ContextWrapper，它本质上委托给另一个上下文，可能由包装器进行更改。

The context is a general abstraction that supports mocking and proxying. Since many contexts are bound to a limited-lifetime object such as an Activity, there needs to be a way to get a longer-lived context, for purposes such as registering for future notifications. That is achieved by Context.getApplicationContext(). A logical implementation is to return the global Application object, but nothing prevents a context implementation from returning a wrapper or proxy with a suitable lifetime instead.

活动和服务更具体地与应用程序对象相关联。我相信，这样做的有用之处在于，您可以创建并在清单中注册一个派生自Application的自定义类，并确保Activity.getApplication()或Service.getApplication()将返回该特定类型的特定对象，您可以将其转换为派生的Application类并用于任何自定义目的。

换句话说，getApplication()保证返回一个Application对象，而getApplicationContext()可以自由返回一个代理。