何时调用activity context或application context？

Question

有很多关于这两个上下文是什么的帖子。但我还是不太明白

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

但是，有没有人能想出一些非常好的编码示例，在这些示例中使用this (获取当前Activity实例的上下文)是正确的，而应用程序上下文将是无用的/错误的？

Answer 1

getApplicationContext()几乎总是错的。Ms. Hackborn (和其他人)一直非常明确地指出，只有当您知道为什么要使用getApplicationContext()并且只有当您需要使用getApplicationContext()时，才使用getApplicationContext()。

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

只有当你知道你需要一个比你所拥有的任何其他可能的Context更长的Context时，你才使用getApplicationContext()。场景包括：

• 如果您需要与本身具有全局作用域的Context绑定的内容，请使用getApplicationContext()。例如，我在WakefulIntentService中使用getApplicationContext()作为服务要使用的静态WakeLock。因为WakeLock是静态的，而我需要一个Context来获取PowerManager来创建它，所以当您从Activity绑定到一个getApplicationContext()时，如果您希望通过onRetainNonConfigurationInstance()在Activity实例之间传递ServiceConnection (即，绑定的句柄)，那么使用Activity Service是最安全的。安卓通过这些ServiceConnections在内部跟踪绑定，并保存对创建绑定的Contexts的引用。如果从Activity绑定，则新的Activity实例将具有对ServiceConnection的引用，该引用具有对旧Activity的隐式引用，并且不能对旧Activity进行垃圾回收。

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

以下是无论您走到哪里都不使用getApplicationContext()的原因：

• 它不是一个完整的Context，它支持Activity所做的一切。你尝试用这个Context做的各种事情都会失败，mostly related to the GUI.
• It可能会造成内存泄漏，如果来自getApplicationContext()的Context持有你对它的调用创建的东西，而你没有清理它。对于Activity，如果它持有某些内容，一旦Activity被垃圾收集，其他所有内容也会被清除。Application对象将在您的进程的生命周期内一直保留。

Answer 2

我认为SDK网站上有很多内容都没有很好的文档记录，这就是其中之一。我要声明的是，似乎默认使用应用程序上下文更好，只有在真正需要的时候才使用活动上下文。我所见过的唯一需要活动上下文的地方是用于进度对话框。SBERG412声称你必须为一个敬酒消息使用一个活动上下文，然而Android文档清楚地显示了正在使用的应用程序上下文。由于这个Google示例，我总是使用应用程序上下文来表示toast。如果这样做是错误的，那么谷歌在这一点上犯了错。

下面是更多需要思考和回顾的内容：

对于吐司消息，Google Dev Guide使用应用程序上下文，并显式地说‘s to use it：Toast Notifications

在开发人员指南的对话框部分中，您可以看到AlertDialog.Builder使用应用程序上下文，然后进度条使用活动上下文。谷歌没有解释这一点。Dialogs

使用应用程序上下文似乎是一个很好的理由，因为当您想要处理像方向更改这样的配置更改，并且想要保留需要上下文的对象时，比如视图。如果你看这里：Run Time Changes有一个关于使用活动上下文的警告，这可能会造成泄漏。这可以通过使用要保留的视图的应用程序上下文来避免(至少这是我的理解)。在我正在编写的应用程序中，我打算使用应用程序上下文，因为我试图在方向更改时保留一些视图和其他内容，并且我仍然希望在方向更改时销毁并重新创建活动。因此，我必须使用应用程序上下文才不会导致内存泄漏(参见Avoiding memory Leaks)。在我看来，使用应用程序上下文而不是活动上下文有很多很好的理由，而且在我看来，您似乎会更频繁地使用它而不是活动上下文。这就是我读过的许多Android书籍所做的事情，这也是我见过的大多数Google示例所做的事情。

Google文档确实让人觉得在大多数情况下使用应用程序上下文完全没问题，而且实际上在他们的示例中比使用活动上下文更常见(至少在我见过的示例中是这样)。如果使用应用程序上下文真的有这样的问题，那么Google真的需要更多地强调这一点。他们需要明确这一点，并且需要重做他们的一些例子。我不会完全责怪没有经验的开发人员，因为权威机构(Google)确实让使用应用程序上下文看起来不是问题。

Answer 3

对于何时使用不同类型的上下文，如应用程序上下文(即：getApplicationContext())和活动上下文，以及BroadcastReceiver context，我使用了此表作为指导

​

​

所有的优点都归功于原作者here以获取更多信息。