getApplication()vs getApplicationContext()

Question

getApplication()vs getApplicationContext()我找不到满意的答案，所以我们开始：怎么回事？Activity/Service.getApplication()和Context.getApplicationContext()?在我们的应用程序中，两者都返回相同的对象。在ActivityTestCase但是，模拟应用程序将使getApplication()带着模拟回来，但是getApplicationContext仍然会返回一个不同的上下文实例(一个由Android注入)。那是窃听器吗？是故意的吗？我一开始都不明白区别。在测试套件之外，是否有两个调用可能返回不同对象的情况？什么时候为什么？而且，为什么getApplication定义在Activity和Service，但不是继续Context？不应该总是有一个有效的应用程序实例从任何地方?

Answer 1

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

尽管在目前的Android活动和服务实现中，getApplication()和getApplicationContext()返回相同的对象，不能保证总是这样(例如，在特定的供应商实现中)。

因此，如果您希望在报表中注册的应用程序类，您应该绝不可能打电话getApplicationContext()并将其转换到您的应用程序中，因为它可能不是应用程序实例(显然是您在测试框架中体验到的)。

为什么getApplicationContext()首先存在吗？

getApplication()仅在活动类和服务类中可用，而getApplicationContext()在上下文类中声明。

这实际上意味着一件事：当在广播接收器中编写代码时，只能调用getApplicationContext()..这也意味着你不能保证在广播收发器中访问你的应用程序。

当查看Android代码时，您可以看到，当附加时，一个活动会接收一个基本上下文和一个应用程序，这些都是不同的参数。getApplicationContext()代表们这是号召baseContext.getApplicationContext().

还有一件事：文档中说，大多数情况下，不需要子类Application：

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

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

Answer 2

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

上下文是支持模拟和代理的一般抽象。由于许多上下文绑定到有限的生存期对象，例如Activity，需要有一种方法来获得更长时间的上下文，例如注册未来的通知。这是通过Context.getApplicationContext()..逻辑实现是返回全局Application对象，但是没有什么可以阻止上下文实现返回具有适当生存期的包装器或代理。

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

换句话说，getApplication()保证返回Application对象，同时getApplicationContext()可以自由地返回代理。