更深层次的理解Context
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（）方法。
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());
其思路和上面两个基本一样，在此就不再详述。
在此总结一下：
（1）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得到相同的结果
（2）在一个apk中，Context的数量等于Activity个数+Service个数+1.