关于 Context ,打从接触 Android 开始，就看到了相关文章，自己的笔记里也做了相关的记录,网上关于解析 Context 的优秀的博客已经很多了，这里纯粹当作记录啦。
Context,意为上下文。弄懂 Context 对于 Android 开发者还是比较重要的。首先，我们看下 Context 的主要继承结构。这里明确一点，是主要。
Context继承结构.jpg
Context 主要应用了装饰模式。ContextWrapper 主要是 Context 的封装类，ContextImpl 则是 Context 的实现类。我们熟悉的 Activity、Service 和 Application 都是 Context 的子类。那么我们就很有必要看下 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 是一个抽象类。我们通过它可以访问当前包的资源（getResources、getAssets）和启动其他组件（Activity、Service、Broadcast）。
接下来我们来看 ContextImpl 类，这里只截取其中关于 startActivity 的实现。总是 ContentImpl 是 Context 的实现类。
/**
* Common implementation of Context API, which provides the base
* context object for Activity and other application components.
*/
class ContextImpl extends Context {
@Override
public void startActivity(Intent intent, Bundle options) {
warnIfCallingFromSystemProcess();
if ((intent.getFlags()&Intent.FLAG_ACTIVITY_NEW_TASK) == 0) {
throw new AndroidRuntimeException(
"Calling startActivity() from outside of an Activity "
+ " context requires the FLAG_ACTIVITY_NEW_TASK flag."
+ " Is this really what you want?");
}
mMainThread.getInstrumentation().execStartActivity(
getOuterContext(), mMainThread.getApplicationThread(), null,
(Activity)null, intent, -1, options);
}
}
我们来看 ContextWrapper 类，里面维护了一个 Context 的引用，是Context 的封装类。
/**
* Proxying implementation of Context that simply delegates all of its calls to
* another Context. Can be subclassed to modify behavior without changing
* the original Context.
*/
public class ContextWrapper extends Context {
Context mBase;
public ContextWrapper(Context base) {
mBase = base;
}
/**
* Set the base context for this ContextWrapper. All calls will then be
* delegated to the base context. Throws
* IllegalStateException if a base context has already been set.
*
* @param base The new base context for this wrapper.
*/
protected void attachBaseContext(Context base) {
if (mBase != null) {
throw new IllegalStateException("Base context already set");
}
mBase = base;
}
/**
* @return the base context as set by the constructor or setBaseContext
*/
public Context getBaseContext() {
return mBase;
}
@Override
public AssetManager getAssets() {
return mBase.getAssets();
}
@Override
public Resources getResources()
{
return mBase.getResources();
}
}
Activity、Service 和 Application 都是Context 的具体装饰类。那为什么 Activity 不直接继承 ContextWrapper 类，而是继承于 ContextThemeWrapper 这个好像多余的类呢？其实不然，我们来看下 ContentThemeWrapper 的源码注释：
/**
* A ContextWrapper that allows you to modify the theme from what is in the
* wrapped context.
*/
public class ContextThemeWrapper extends ContextWrapper {
......
}
原来这个类的目的是让我们可以去修改或者说替换 Cotnext 的主题Theme。即android:theme 属性指定的。
Context 数量
关于一个应用中到底有多少个Context其实是显而易见的了。Context 一共有 Application、Activity 和 Service 三种类型，因此一个应用中 Context 数量为：
Context 数量 = Activity 数量 + Service 数量 + 1(Applcation)
Context 实例化过程的源码分析
Activity 对象中 Context 的实例化。
通过 startActivity 启动一个 Activity 进过一系列的调用方法之后会来到 ActivityThread（即主线程）的 performLaunchActivity（）方法来创建一个 Activity 实例，然后回调 Activity 的 onCreate（）等方法。
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
......
if (activity != null) {
//创建一个Context对象
Context appContext = createBaseContextForActivity(r, activity);
......
//将上面创建的appContext传入到activity的attach方法
activity.attach(appContext, this, getInstrumentation(), r.token,
r.ident, app, r.intent, r.activityInfo, title, r.parent,
r.embeddedID, r.lastNonConfigurationInstances, config,
r.referrer, r.voiceInteractor);
......
}
......
return activity;
}
可以看到，通过 createBaseContextForActivity（r,activity）
创建一个 Context 对象并在 attach 方法关联它。
我们再来看下 createBaseContextForActivity 方法。
private Context createBaseContextForActivity(ActivityClientRecord r,
final Activity activity) {
//实质就是new一个ContextImpl对象，调运ContextImpl的有参构造初始化一些参数
ContextImpl appContext = ContextImpl.createActivityContext(this, r.packageInfo, r.token);
//特别特别留意这里！！！
//ContextImpl中有一个Context的成员叫mOuterContext，通过这条语句就可将当前新Activity对象赋值到创建的ContextImpl的成员mOuterContext（也就是让ContextImpl内部持有Activity）。
appContext.setOuterContext(activity);
//创建返回值并且赋值
Context baseContext = appContext;
......
//返回ContextImpl对象
return baseContext;
}
总结：Activity 内部持有一个 ContextImpl 引用（ContextWrapper 的成员 mBase）,进而 执行 Context（ContextImpl 继承于 Context） 中的方法。
Service 对象中 Context 的实例化。
通过 startService 或者 bindService 方法创建一个新 Service 时会回调 ActivityThread 类的 handleCreateService（）方法完成相关数据操作。
private void handleCreateService(CreateServiceData data) {
......
//类似上面Activity的创建，这里创建service对象实例
Service service = null;
try {
java.lang.ClassLoader cl = packageInfo.getClassLoader();
service = (Service) cl.loadClass(data.info.name).newInstance();
} catch (Exception e) {
......
}
try {
......
//不做过多解释，创建一个Context对象
ContextImpl context = ContextImpl.createAppContext(this, packageInfo);
//特别特别留意这里！！！
//ContextImpl中有一个Context的成员叫mOuterContext，通过这条语句就可将当前新Service对象赋值到创建的ContextImpl的成员mOuterContext（也就是让ContextImpl内部持有Service）。
context.setOuterContext(service);
Application app = packageInfo.makeApplication(false, mInstrumentation);
//将上面创建的context传入到service的attach方法
service.attach(context, this, data.info.name, data.token, app,
ActivityManagerNative.getDefault());
service.onCreate();
......
} catch (Exception e) {
......
}
}
Application对象中 Context 的实例化。
其实，Application 对象中 Context 对象的实例化 和 Activity 、Service 中的基本一致。ContentImpl 的创建在 LoadedApk 类 的 makeApplication 方法实现。
public Application makeApplication(boolean forceDefaultAppClass,
Instrumentation instrumentation) {
//只有新创建的APP才会走if代码块之后的剩余逻辑
if (mApplication != null) {
return mApplication;
}
//即将创建的Application对象
Application app = null;
String appClass = mApplicationInfo.className;
if (forceDefaultAppClass || (appClass == null)) {
appClass = "android.app.Application";
}
try {
java.lang.ClassLoader cl = getClassLoader();
if (!mPackageName.equals("android")) {
initializeJavaContextClassLoader();
}
//不做过多解释，创建一个Context对象
ContextImpl appContext = ContextImpl.createAppContext(mActivityThread, this);
//将Context传入Instrumentation类的newApplication方法
app = mActivityThread.mInstrumentation.newApplication(
cl, appClass, appContext);
//特别特别留意这里！！！
//ContextImpl中有一个Context的成员叫mOuterContext，通过这条语句就可将当前新Application对象赋值到创建的ContextImpl的成员mOuterContext（也就是让ContextImpl内部持有Application）。
appContext.setOuterContext(app);
} catch (Exception e) {
......
}
......
return app;
}
应用程序 App 各种 Context 访问资源的唯一性
可以发现，Application、Activity 和 Service 都有自己 Context 的实例，那么平常我们通过 context.getResources() 得到的资源是不是同一份呢？
class ContextImpl extends Context {
......
private final ResourcesManager mResourcesManager;
private final Resources mResources;
......
@Override
public Resources getResources() {
return mResources;
}
......
}
context.getResources 方法获得的 Resources 对象就是上面 ContextImpl 的成员变量 mResources。mResource 的赋值操作如下：
private ContextImpl(ContextImpl container, ActivityThread mainThread,
LoadedApk packageInfo, IBinder activityToken, UserHandle user, boolean restricted,
Display display, Configuration overrideConfiguration) {
......
//单例模式获取ResourcesManager对象
mResourcesManager = ResourcesManager.getInstance();
......
//packageInfo对于一个APP来说只有一个，所以resources 是同一份
Resources resources = packageInfo.getResources(mainThread);
if (resources != null) {
if (activityToken != null
|| displayId != Display.DEFAULT_DISPLAY
|| overrideConfiguration != null
|| (compatInfo != null && compatInfo.applicationScale
!= resources.getCompatibilityInfo().applicationScale)) {
//mResourcesManager是单例，所以resources是同一份
resources = mResourcesManager.getTopLevelResources(packageInfo.getResDir(),
packageInfo.getSplitResDirs(), packageInfo.getOverlayDirs(),
packageInfo.getApplicationInfo().sharedLibraryFiles, displayId,
overrideConfiguration, compatInfo, activityToken);
}
}
//把resources赋值给mResources
mResources = resources;
......
}
由此可以看出在设备等其他因素不变的情况下我们通过 Context 实例得到的 Resources 是同一套资源。这里要注意的是只有在设备等其他因素不变的情况下，这句话才是正确的。因为 res 下可能存在多个适配不同设备、不同分辨率、不同系统版本的目录，不同设备在访问同一个应用的时候可以不同，有可能是 hdpi 的 或者 xxhdpi 的。而且如果为横竖屏状态下提供了不同的资源，-land、-port,处在横屏状态下的 ContextImpl 和处在竖屏状态下的 ContextImpl 访问的资源也不是同一个资源对象。
getApplication 和 getApplicationContext 的区别
首先我们看 getApplication 方法，这个方法是 Activity 和 Service 中才有的。Application 和 Context 都没有此方法。
public class Activity extends ContextThemeWrapper
implements LayoutInflater.Factory2,
Window.Callback, KeyEvent.Callback,
OnCreateContextMenuListener, ComponentCallbacks2,
Window.OnWindowDismissedCallback {
......
public final Application getApplication() {
return mApplication;
}
......
}
public abstract class Service extends ContextWrapper implements ComponentCallbacks2 {
......
public final Application getApplication() {
return mApplication;
}
......
}
Activity 和 Service 提供了getApplication方法，而且返回类型都是 Application。这个 Application 是在 ActivityThread 中各自实例化时获取的 make Application 方法返回值。所以不同的 Activity 和 Service 返回的Application均为同一个全局对象。
接着我们来看 getApplicationContext 方法，
class ContextImpl extends Context {
......
@Override
public Context getApplicationContext() {
return (mPackageInfo != null) ?
mPackageInfo.getApplication() :mMainThread.getApplication();
}
......
}
可以看到，getApplicationContext 方法 是Context 方法，而且返回值是 Context 类型，返回对象和上面通过 Service 或者 Activity 的 getApplication 返回的是一个对象。
因此 getApplication 方法 和 getApplicationContext 方法只是返回值类型不同，一个返回的是 Application ，另一个是 Context。还有就是依附的对象不同而已。
参考资料
[1] 工匠若水.Android应用Context详解及源码解析
[2] singwhatiwannaAndroid源码分析-全面理解Context
网友评论