Context在开发Android应用的过程中扮演着非常重要的角色，比如启动一个Activity需要使用context.startActivity方法，将一个xml文件转换为一个View对象也需要使用Context对象，可以这么说，离开了这个类，Android开发寸步难行，对于这样一个类，我们又对他了解多少呢。我就说说我的感受吧，在刚开始学习Android开发时，感觉使用Context的地方一直就是传入一个Activity对象，久而久之感觉只要是Context的地方就传入一个Activity就行了，那么我们现在就来详细的分析一下Context和Activity的关系吧！
在开始本文之前我们先放置一个问题在这里：
我们平时在获取项目资源时使用context.getResources()的时候为什么放回的是同一个值，明明是使用不同的Activity调用getResources返回结果却是一样的。
Context本身是一个纯的abstract类，ContextWrapper是对Context的一个包装而已，它的内部包含了一个Context对象，其实对ContextWrapper的方法调用最终都是调用其中的Context对象完成的，至于ContextThremeWrapper，很明显和Theme有关，所以Activity从ContextThemmWrapper继承，而Service从ContextWrapper继承，ContextImpl是唯一一个真正实现了Context中方法的类。
从上面的继承关系来看，每一个Activity就是一个Context,每一个Service就是一个Context,这也就是为什么使用Context的地方可以被Activity或者Service替换了。
根据前面所说，由于实现了Context的只有ContextImpl类，Activity和Service本没有真正的实现，他们只是内部包含了一个真实的Context对象而已，也就是在在创建Activity或者Service的时候肯定要创建爱你一个ContextImpl对象，并赋值到Activity中的Context类型变量中。那我们就来看看Andorid源码中有哪些地方创建了ContextImpl.
据统计Android中创建ContextImpl的地方一共有7处：
- 在PackageInfo.makeApplication()中
- 在performLaunchActivity()中
- 在handleCreateBackupAgent（）中
- 在handleCreateService（）中
- 2次在hanldBinderAppplication（）中
- 在attach（）方法中
由于创建ContextImpl的基本原理类似，所以这里只会分析几个比较有代表性的地方：
1、 Application对应的Context
在应用程序启动时，都会创建一个Application对象，所以辗转调用到handleBindApplication（）方法。
private final void handleBindApplication(AppBindData data) {
mBoundApplication = data;
mConfiguration = new Configuration(data.config);
....
data.info = getPackageInfoNoCheck(data.appInfo);
...
Application app = data.info.makeApplication(data.restrictedBackupMode, null);
mInitialApplication = app;
....
}
其中data.info是LoadedApk类型的，到getPackageInfoNoCheck中看看源码
public final LoadedApk getPackageInfoNoCheck(ApplicationInfo ai) {
return getPackageInfo(ai, null, false, true);
}
里面其实调用的是getPackageInfo，继续跟进：
if (includeCode) {
ref = mPackages.get(aInfo.packageName);
} else {
ref = mResourcePackages.get(aInfo.packageName);
}
LoadedApk packageInfo = ref != null ? ref.get() : null;
if (packageInfo == null || (packageInfo.mResources != null
&& !packageInfo.mResources.getAssets().isUpToDate())) {
if (localLOGV) Slog.v(TAG, (includeCode ? "Loading code package "
: "Loading resource-only package ") + aInfo.packageName
+ " (in " + (mBoundApplication != null
? mBoundApplication.processName : null)
+ ")");
packageInfo =
new LoadedApk(this, aInfo, this, baseLoader,
securityViolation, includeCode &&
(aInfo.flags&ApplicationInfo.FLAG_HAS_CODE) != 0);
if (includeCode) {
mPackages.put(aInfo.packageName,
new WeakReference<LoadedApk>(packageInfo));
} else {
mResourcePackages.put(aInfo.packageName,
new WeakReference<LoadedApk>(packageInfo));
}
由于includeCode传入的是true,所以首先从mPackages中获取，如果没有，则new一个出来，并放入mPackages里面去，注意，这里的mPackages是ActivityThread中的属性。
下面继续分析一下LoadedApk这个类中的makeApplication函数
try {
java.lang.ClassLoader cl = getClassLoader();
//创建一个ContextImpl对象
ContextImpl appContext = new ContextImpl();
appContext.init(this, null, mActivityThread);
app = mActivityThread.mInstrumentation.newApplication(
cl, appClass, appContext);
appContext.setOuterContext(app);
} catch (Exception e) {
if (!mActivityThread.mInstrumentation.onException(app, e)) {
throw new RuntimeException(
"Unable to instantiate application " + appClass
+ ": " + e.toString(), e);
}
}
这里创建了一个ContextImpl对象，并调用了它的init方法，现在进入init方法。
mPackageInfo = packageInfo;
mResources = mPackageInfo.getResources(mainThread);
对mPackageInof和mResources两个变量初始化
回到makeApplication中，创建了一个Application对象，并将appContext传进去，其实就是将appContext传递给ContextWrapper中的Context类型变量(Application也是继承ContextWrapper)
2、Activity中的Context
在创建一个Activity时，经过辗转调用，会执行handleLaunchActivity(),然后调用performLaunchActivity(),该方法创建ContextImpl代码如下：
r.packageInfo= getPackageInfo(aInfo.applicationInfo,
Context.CONTEXT_INCLUDE_CODE);
ContextImplappContext = new ContextImpl();
appContext.init(r.packageInfo,r.token, this);
appContext.setOuterContext(activity);
activity.attach(appContext,this, getInstrumentation(), r.token,
r.ident, app, r.intent,r.activityInfo, title, r.parent,
r.embeddedID,r.lastNonConfigurationInstance,
r.lastNonConfigurationChildInstances, config);
由于getPackageInfo函数之前已经分析过了，稍微有点区别，但是大致流程是差不多的，所以此处的appContext执行init之后，其中的mPackages变量和mResources变量时一样的，activity通过attach函数将该appContext赋值到ContextWrapper中的Context类型变量
3、Service中的Context
同样 在创建一个Service时，经过辗转调用会调用到scheduleCreateService方法，之后会巧用handleCreateService
LoadedApkpackageInfo = getPackageInfoNoCheck(
data.info.applicationInfo);
ContextImplcontext = new ContextImpl();
context.init(packageInfo, null,this);
Application app =packageInfo.makeApplication(false, mInstrumentation);
context.setOuterContext(service);
service.attach(context, this,data.info.name, data.token, app,
ActivityManagerNative.getDefault());
其思路和上面两个基本一样，在此就不再详述。
在此总结一下：
- Context是一个抽象类，ContextWrapper是对Context的封装，它包含一个Context类型的变量,ContextWrapper的功能函数内部其实都是调用里面的Context类型变量完成的。Application,Service,Activity等都是直接或者间接继承自ContextWrapper,但是并没有真正的实现其中的功能，Application，Service，Activity中关于Context的功能都是通过其内部的Context类型变量完成的，而这个变量的真实对象必定是ContextImpl，所以没创建一个Application,Activity,Servcice便会创建一个ContextImpl,并且这些ContextImpl中的mPackages和mResources变量都是一样的，所以不管使用Acitivty还是Service调用getResources得到相同的结果
- 在一个apk中，Context的数量等于Activity个数+Service个数+1.
本文转载自：http://blog.csdn.net/yuanzeyao/article/details/12955459
