android application activity 关系,Android Application中的Context和Activity中的Context的异同...

前几天在做Android面试题的时候遇到这样一道题：请比较一下Application Context和Activity Context的异同？一开始看到这个题目的时候，我有点蒙，因为不知道怎么用两三句话来概括这两者之间的异同…我相信不管是刚开始学习Android的新手，还是Android大神对于Context的使用是再熟悉不过了，因为我们在开发过程中时刻与它打交道。在Android中Context可以做很多操作，比如我们需要加载和访问资源、启动Activity、启动Service、弹出Toast、发送广播等都需要传一个Context，Context字面上的意思也就是上下文，也可以理解成“运行环境”或者“场景”，可是我们平时在使用的时候有没有考虑过这样一个问题呢？接下来就把这几天对Context的学习做一个总结，如有不对的地方，还望指出来。

一、Context是什么：

1、Context是维持Android程序中各组件能够正常工作的一个核心功能类，我们选中Context类 ，按下快捷键F4，右边就会出现一个Context类的继承结构图啦，如下图所示：

看下我用红线标出来的地方，从这里可以看到Activity、Service、Application都是Context的子类；

2、再来从源码角度看Context类：

/**

* Interface to global information about an application environment. This is

* an abstract class whose implementation is provided by

* the Android system. It

* allows access to application-specific resources and classes, as well as

* up-calls for application-level operations such as launching activities,

* broadcasting and receiving intents, etc.

*/

public abstract class Context {

......

}

从源码中我们可以看见Context是个抽象类，里面定义了各种抽象方法，包括获取系统资源，获取系统服务，发送广播，启动Activity,Service等，结合上图也就是说Activity、Service、Application等都是Context类的一个实现。再仔细看一下上图：Activity、Service、Application都是继承自ContextWrapper(上下文功能的封装类)，而在ContextWrapper的源码中我们可以看到，ContextWrapper内部会包含一个base context(这里就不贴出来了，大家去看源码即可)，由这个base context去实现了绝大多数的方法。

二、下面我们来看一下在Android系统中Context类的继承结构：

通过继承关系可以看到，Context直接子类为ContextIml(具体实现类)和ContextWrapper(上下文功能包装类)，而ContextWrapper又有三个子类，分别是ContextThemeWrapper、Service和Application。基于Activity和Service、Application不在一个继承层级里，而是又继承了ContextThemeWrapper。细心的朋友看到ContextWrapper和ContextThemeWrapper这两个类的名字，相信你心里已经有了答案，对的，区别在Theme。ContextThemeWrapper是一个带主题的封装类，内部包含了主题(Theme)相关的接口，当Activity在启动的时候系统都会加载一个主题，也就是我们在配置文件AndroidManifest.xml里面写的android:theme=”@style/AppTheme”的属性啦！(如下图所示)，可是Service和Applicaton并不需要加载主题，因此他们继承自ContextWrapper。

三、Application中的Context和Activity中的Context的区别

在需要传递Context参数的时候，如果是在Activity中，我们可以传递this(这里的this指的是Activity.this，是当前Activity的上下文)或者Activity.this。这个时候如果我们传入getApplicationContext()，我们会发现这样也是可以用的。可是大家有没有想过传入Activity.this和传入getApplicationContext()的区别呢？首先Activity.this和getApplicationContext()返回的不是同一个对象，一个是当前Activity的实例，一个是项目的Application的实例，这两者的生命周期是不同的，它们各自的使用场景不同，this.getApplicationContext()取的是这个应用程序的Context，它的生命周期伴随应用程序的存在而存在；而Activity.this取的是当前Activity的Context，它的生命周期则只能存活于当前Activity，这两者的生命周期是不同的。getApplicationContext() 生命周期是整个应用，当应用程序摧毁的时候，它才会摧毁；Activity.this的context是属于当前Activity的，当前Activity摧毁的时候，它就摧毁。

四、Application中的Context和Activity中的Context各自的使用场景

Activity Context 和Application Context两者的使用范围存在着差异，具体如下图所示：

我们就只看Activity和Application，可以看到前三个操作不在Application中出现，也就是Show a Dialog、Start an Activity和Layout Inflation。开发的过程中，我们主要记住一点，凡是跟UI相关的，都用Activity做为Context来处理。

五、Context数量

在创建Activity、Service、Application时都会自动创建Context，它们各自维护着自己的上下文。在Android系统中Context类的继承结构里面我们讲到Context一共有Application、Activity和Service三种类型，因此如果要统计一个app中Context数量，我们可以这样来表示：

Context数量=Activity数量 + Service数量 + 1

这里要解释一下，上面的1表示Application数量。一个应用程序中可以有多个Activity和多个Service，但只有一个Application。可能有人会说一个应用程序里面可以有多个Application啊，我的理解是：一个应用程序里面可以有多个Application，可是在配置文件AndroidManifest.xml中只能注册一个，只有注册的这个Application才是真正的Application，才会调用到全部的生命周期，所以Application的数量是1。

六、结束 在Android开发中Context的使用不当会造成内存泄漏，后面打算把内存泄漏这一块知识点单独拿出来，本篇文章就到这里结束，总结过程中有不对的地方麻烦指出来，大家互相学习，谢谢。