Context

什么是Context

Context是一个抽象基类，我们通过它访问当前包的资源（getResources、getAssets）和启动其他组件（Activity、Service、Broadcast）以及得到各种服务（getSystemService），当然，通过Context能得到的不仅仅只有上述这些内容。对Context的理解可以来说：Context提供了一个应用的运行环境，在Context的大环境里，应用才可以访问资源，才能完成和其他组件、服务的交互，Context定义了一套基本的功能接口，我们可以理解为一套规范，而Activity和Service是实现这套规范的子类，这么说也许并不准确，因为这套规范实际是被ContextImpl类统一实现的，Activity和Service只是继承并有选择性地重写了某些规范的实现。

Context相关类的继承关系

通过对比可以清晰地发现，Service和Application的类继承关系比较像，而Activity还多了一层继承ContextThemeWrapper，这是因为Activity有主题的概念，而Service是没有界面的服务，Application更是一个抽象的东西，它也是通过Activity类呈现的。

相关类介绍：

Context类 

路径：/frameworks/base/core/java/android/content/Context.java

说明：抽象类，提供了一组通用的API。

源代码(部分)如下：

public abstract class Context {
	 ...
 	 public abstract Object getSystemService(String name);  //获得系统级服务
	 public abstract void startActivity(Intent intent);     //通过一个Intent启动Activity
	 public abstract ComponentName startService(Intent service);  //启动Service
	 //根据文件名得到SharedPreferences对象
	 public abstract SharedPreferences getSharedPreferences(String name,int mode);
	 ...
}

ContextIml.java类

路径 ：/frameworks/base/core/java/android/app/ContextImpl.java

说明：该Context类的实现类为ContextIml，该类实现了Context类的功能。请注意，该函数的大部分功能都是直接调用其属性mPackageInfo去完成，这点我们后面会讲到。

源代码(部分)如下：

/**
 * Common implementation of Context API, which provides the base
 * context object for Activity and other application components.
 */
class ContextImpl extends Context{
	//所有Application程序公用一个mPackageInfo对象
    /*package*/ ActivityThread.PackageInfo mPackageInfo;
    
    @Override
    public Object getSystemService(String name){
    	...
    	else if (ACTIVITY_SERVICE.equals(name)) {
            return getActivityManager();
        } 
    	else if (INPUT_METHOD_SERVICE.equals(name)) {
            return InputMethodManager.getInstance(this);
        }
    } 
    @Override
    public void startActivity(Intent intent) {
    	...
    	//开始启动一个Activity
        mMainThread.getInstrumentation().execStartActivity(
            getOuterContext(), mMainThread.getApplicationThread(), null, null, intent, -1);
    }
}

ContextWrapper类

路径 ：\frameworks\base\core\java\android\content\ContextWrapper.java

说明： 正如其名称一样，该类只是对Context类的一种包装，该类的构造函数包含了一个真正的Context引用，即ContextIml对象。

源代码(部分)如下：

public class ContextWrapper extends Context {
    Context mBase;  //该属性指向一个ContextIml实例，一般在创建Application、Service、Activity时赋值
    
    //创建Application、Service、Activity，会调用该方法给mBase属性赋值
    protected void attachBaseContext(Context base) {
        if (mBase != null) {
            throw new IllegalStateException("Base context already set");
        }
        mBase = base;
    }
    @Override
    public void startActivity(Intent intent) {
        mBase.startActivity(intent);  //调用mBase实例方法
    }
}

ContextThemeWrapper类

路径：/frameworks/base/core/java/android/view/ContextThemeWrapper.java

说明：该类内部包含了主题(Theme)相关的接口，即android:theme属性指定的。只有Activity需要主题，Service不需要主题，所以Service直接继承于ContextWrapper类。

源代码(部分)如下：

public class ContextThemeWrapper extends ContextWrapper {
	 //该属性指向一个ContextIml实例，一般在创建Application、Service、Activity时赋值
	 
	 private Context mBase;
	//mBase赋值方式同样有一下两种
	 public ContextThemeWrapper(Context base, int themeres) {
	        super(base);
	        mBase = base;
	        mThemeResource = themeres;
	 }

	 @Override
	 protected void attachBaseContext(Context newBase) {
	        super.attachBaseContext(newBase);
	        mBase = newBase;
	 }
}

Context对资源的访问

很明确，不同的Context得到的都是同一份资源。这是很好理解的，请看下面的分析：得到资源的方式为context.getResources，而真正的实现位于ContextImpl中的getResources方法，在ContextImpl中有一个成员 private Resources mResources，它就是getResources方法返回的结果，mResources的赋值代码为：mResources =mResourcesManager.getTopLevelResources(mPackageInfo.getResDir(),                  Display.DEFAULT_DISPLAY, null, compatInfo, activityToken);

下面看一下ResourcesManager的getTopLevelResources方法，这个方法的思想是这样的：在ResourcesManager中，所有的资源对象都被存储在ArrayMap中，首先根据当前的请求参数去查找资源，如果找到了就返回，否则就创建一个资源对象放到ArrayMap中。有一点需要说明的是为什么会有多个资源对象，原因很简单，因为res下可能存在多个适配不同设备、不同分辨率、不同系统版本的目录，按照android系统的设计，不同设备在访问同一个应用的时候访问的资源可以不同，比如drawable-hdpi和drawable-xhdpi就是典型的例子。

public Resources getTopLevelResources(String resDir, int displayId, Configuration overrideConfiguration, CompatibilityInfo compatInfo, IBinder token) {  
    final float scale = compatInfo.applicationScale;  
    ResourcesKey key = new ResourcesKey(resDir, displayId, overrideConfiguration, scale,  
            token);  
    Resources r;  
    synchronized (this) {  
        // Resources is app scale dependent.  
        if (false) {  
            Slog.w(TAG, "getTopLevelResources: " + resDir + " / " + scale);  
        }  
        WeakReference<Resources> wr = mActiveResources.get(key);  
        r = wr != null ? wr.get() : null;  
        //if (r != null) Slog.i(TAG, "isUpToDate " + resDir + ": " + r.getAssets().isUpToDate());  
        if (r != null && r.getAssets().isUpToDate()) {  
           if (false) {  
                Slog.w(TAG, "Returning cached resources " + r + " " + resDir  
                        + ": appScale=" + r.getCompatibilityInfo().applicationScale);  
            }  
            return r;  
        }  
    }  
  
    //if (r != null) {  
    //    Slog.w(TAG, "Throwing away out-of-date resources!!!! "  
    //            + r + " " + resDir);  
    //}  
  
    AssetManager assets = new AssetManager();  
    if (assets.addAssetPath(resDir) == 0) {  
        return null;  
    }  
  
    //Slog.i(TAG, "Resource: key=" + key + ", display metrics=" + metrics);  
    DisplayMetrics dm = getDisplayMetricsLocked(displayId);  
    Configuration config;  
    boolean isDefaultDisplay = (displayId == Display.DEFAULT_DISPLAY);  
    final boolean hasOverrideConfig = key.hasOverrideConfiguration();  
    if (!isDefaultDisplay || hasOverrideConfig) {  
        config = new Configuration(getConfiguration());  
        if (!isDefaultDisplay) {  
            applyNonDefaultDisplayMetricsToConfigurationLocked(dm, config);  
        }  
        if (hasOverrideConfig) {  
            config.updateFrom(key.mOverrideConfiguration);  
        }  
    } else {  
        config = getConfiguration();  
    }  
    r = new Resources(assets, dm, config, compatInfo, token);  
    if (false) {  
        Slog.i(TAG, "Created app resources " + resDir + " " + r + ": "  
                + r.getConfiguration() + " appScale="  
                + r.getCompatibilityInfo().applicationScale);  
    }  
  
    synchronized (this) {  
        WeakReference<Resources> wr = mActiveResources.get(key);  
        Resources existing = wr != null ? wr.get() : null;  
        if (existing != null && existing.getAssets().isUpToDate()) {  
            // Someone else already created the resources while we were  
            // unlocked; go ahead and use theirs.  
            r.getAssets().close();  
            return existing;  
        }  
  
        // XXX need to remove entries when weak references go away  
        mActiveResources.put(key, new WeakReference<Resources>(r));  
        return r;  
    }  
}

根据上述代码中资源的请求机制，再加上ResourcesManager采用单例模式，这样就保证了不同的ContextImpl访问的是同一套资源，注意，这里说的同一套资源未必是同一个资源，因为资源可能位于不同的目录，但它一定是我们的应用的资源，或许这样来描述更准确，在设备参数和显示参数不变的情况下，不同的ContextImpl访问到的是同一份资源。设备参数不变是指手机的屏幕和android版本不变，显示参数不变是指手机的分辨率和横竖屏状态。也就是说，尽管Application、Activity、Service都有自己的ContextImpl，并且每个ContextImpl都有自己的mResources成员，但是由于它们的mResources成员都来自于唯一的ResourcesManager实例，所以它们看似不同的mResources其实都指向的是同一块内存(C语言的概念)，因此，它们的mResources都是同一个对象（在设备参数和显示参数不变的情况下）。在横竖屏切换的情况下且应用中为横竖屏状态提供了不同的资源，处在横屏状态下的ContextImpl和处在竖屏状态下的ContextImpl访问的资源不是同一个资源对象。

代码：单例模式的ResourcesManager类 

public static ResourcesManager getInstance() {  
    synchronized (ResourcesManager.class) {  
       if (sResourcesManager == null) {  
           sResourcesManager = new ResourcesManager();  
        }  
        return sResourcesManager;  
    }  
}

getApplication和getApplicationContext的区别

getApplication返回结果为Application，且不同的Activity和Service返回的Application均为同一个全局对象，在ActivityThread内部有一个列表专门用于维护所有应用的application：

finalArrayList<Application> mAllApplications  = newArrayList<Application>();

getApplicationContext返回的也是Application对象，只不过返回类型为Context，看看它的实现

@Override  
public Context getApplicationContext() {  
    return (mPackageInfo != null) ?  
            mPackageInfo.getApplication() : mMainThread.getApplication();  
}

上面代码中mPackageInfo是包含当前应用的包信息、比如包名、应用的安装目录等，原则上来说，作为第三方应用，包信息mPackageInfo不可能为空，在这种情况下，getApplicationContext返回的对象和getApplication是同一个。但是对于系统应用，包信息有可能为空，具体就不深入研究了。从这种角度来说，对于第三方应用，一个应用只存在一个Application对象，且通过getApplication和getApplicationContext得到的是同一个对象，两者的区别仅仅是返回类型不同。

具体创建Context的时机

Context的真正实现都在ContextImpl中，也就是说Context的大部分方法调用都会转到ContextImpl中，而三者的创建均在ActivityThread中完成

应用程序创建Context实例的情况有如下几种情况：

1.创建Application对象时， 而且整个App共一个Application对象

2.创建Service对象时

3.创建Activity对象时

因此应用程序App共有的Context数目公式为：

总Context实例个数 = Service个数 + Activity个数 + 1（Application对应的Context实例）

创建Application对象的时机

每个应用程序在第一次启动时，都会首先创建Application对象。如果对应用程序启动一个Activity(startActivity)流程比较清楚的话，创建Application的时机在创建handleBindApplication()方法中，该函数位于ActivityThread.java类中，如下：

//创建Application时同时创建的ContextIml实例
private final void handleBindApplication(AppBindData data){
    ...
	///创建Application对象
    Application app = data.info.makeApplication(data.restrictedBackupMode, null);
    ...
}

public Application makeApplication(boolean forceDefaultAppClass, Instrumentation instrumentation) {
	...
	try {
        java.lang.ClassLoader cl = getClassLoader();
        ContextImpl appContext = new ContextImpl();    //创建一个ContextImpl对象实例
        appContext.init(this, null, mActivityThread);  //初始化该ContextIml实例的相关属性
        ///新建一个Application对象 
        app = mActivityThread.mInstrumentation.newApplication(
                cl, appClass, appContext);
       appContext.setOuterContext(app);  //将该Application实例传递给该ContextImpl实例         
    } 
	...
}

创建Activity对象的时机

通过startActivity()或startActivityForResult()请求启动一个Activity时，如果系统检测需要新建一个Activity对象时，就会回调handleLaunchActivity()方法，该方法继而调用performLaunchActivity()方法，去创建一个Activity实例，并且回调onCreate()，onStart()方法等，函数都位于 ActivityThread.java类，如下：

//创建一个Activity实例时同时创建ContextIml实例
private final void handleLaunchActivity(ActivityRecord r, Intent customIntent) {
	...
	Activity a = performLaunchActivity(r, customIntent);  //启动一个Activity
}
private final Activity performLaunchActivity(ActivityRecord r, Intent customIntent) {
	...
	Activity activity = null;
    try {
    	//创建一个Activity对象实例
        java.lang.ClassLoader cl = r.packageInfo.getClassLoader();
        activity = mInstrumentation.newActivity(cl, component.getClassName(), r.intent);
    }
    if (activity != null) {
        ContextImpl appContext = new ContextImpl();      //创建一个Activity实例
        appContext.init(r.packageInfo, r.token, this);   //初始化该ContextIml实例的相关属性
        appContext.setOuterContext(activity);            //将该Activity信息传递给该ContextImpl实例
        ...
    }
    ...    
}

创建Service对象的时机

通过startService或者bindService时，如果系统检测到需要新创建一个Service实例，就会回调handleCreateService()方法，完成相关数据操作。handleCreateService()函数位于ActivityThread.java类，如下：

//创建一个Service实例时同时创建ContextIml实例
private final void handleCreateService(CreateServiceData data){
	...
	//创建一个Service实例
	Service service = null;
    try {
        java.lang.ClassLoader cl = packageInfo.getClassLoader();
        service = (Service) cl.loadClass(data.info.name).newInstance();
    } catch (Exception e) {
    }
	...
	ContextImpl context = new ContextImpl(); //创建一个ContextImpl对象实例
    context.init(packageInfo, null, this);   //初始化该ContextIml实例的相关属性
    //获得我们之前创建的Application对象信息
    Application app = packageInfo.makeApplication(false, mInstrumentation);
    //将该Service信息传递给该ContextImpl实例
    context.setOuterContext(service);
    ...
}

另外，需要强调一点的是，通过对ContextImp的分析可知，其方法的大多数操作都是直接调用其属性mPackageInfo(该属性类型为PackageInfo)的相关方法而来。这说明ContextImp是一种轻量级类，而PackageInfo才是真正重量级的类。而一个App里的所有ContextIml实例，都对应同一个packageInfo对象。

 

整理自：

http://www.cnblogs.com/android100/p/Android-Context.html

http://blog.csdn.net/qinjuning/article/details/7310620