更深层次的理解Context

来源：互联网发布：mac找不到管理员账户编辑：程序博客网时间：2024/04/30 08:41

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（）方法。

[java] view plaincopyprint?
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中看看源码

[java] view plaincopyprint?
public final LoadedApk getPackageInfoNoCheck(ApplicationInfo ai) {  
        return getPackageInfo(ai, null, false, true);  
}  

里面其实调用的是getPackageInfo，继续跟进：

[java] view plaincopyprint?
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函数

[java] view plaincopyprint?
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.

0 0