前言
Android开发过程中，Context是绕不开的东西，因此本篇文章将一探究竟。
通过这篇文章，你将了解到：
1、Context衍生的子类
2、Context作用
3、四大组件里的Context
4、Context与Resources
5、不同Context关联与使用
Context家族
Context是抽象类，来看看常见的子类
上图展示了常见的Context子类的继承关系。
我们平时接触比较多的是Activity、Application、Service。
Context作用
根据上图，我们主要讲解Resource和四大组件相关的。
四大组件里的Context
Context 子类
Context里没有特别需要留意的成员变量，其成员方法也多靠子类实现。
ContextWrapper
成员变量
遍观ContextWrapper，只有个成员变量：
Context mBase;
成员方法
ContextWrapper重写Context的方法，内部依靠mBase调用。
mBase实际上就是ContextImpl类型的，来看看它的内容。
ContextImpl
成员变量
//ContentResolver
private final ApplicationContentResolver mContentResolver;
//通过ResourcesManager管理Resource
private final @NonNull ResourcesManager mResourcesManager;
//Resource引用
private @NonNull Resources mResources;
//主题资源
private int mThemeResource = 0;
//主题
private Resources.Theme mTheme = null;
//缓存context.getSystemService 获取的实例
final Object[] mServiceCache = SystemServiceRegistry.createServiceCache();
//省略...
成员方法
ContextImpl成员方法是Context方法具体实现的地方。
Context/ContextWrapper/ContextImpl 三者关系
如上图，ContextWrapper、ContextImpl继承自Context，ContextWrapper作为ContextImpl 代理。
ContextWrapper和ContextImpl关联
ContextWrapper和ContextImpl如何关联以及在什么时机进行关联的呢？
Application
Application是ContextWrapper子类，先来看看它是如何关联的。以下部分涉及到Application/Activity启动流程，有兴趣的请移步：Android Activity创建到View的显示过程
#LoadedApk.java
#makeApplication(...)
//创建ContextImpl 实例
ContextImpl appContext = ContextImpl.createAppContext(mActivityThread, this);
//创建Application实例，并将mBase指向appContext
//Application.attach(...)->ContextWrapper.attachBaseContext(...)->mBase=appContext
app = mActivityThread.mInstrumentation.newApplication(
cl, appClass, appContext);
//ContextImpl mOuterContext指向app
appContext.setOuterContext(app);
在创建Application的时候，会先构造ContextImpl对象，然后构造Application实例，并将Application里的mBase指向ContextImpl对象，最后将ContextImpl mOuterContext指向app。完成了Application和ContextImpl关联，也即是ContextWrapper和ContextImpl的关联。
Service
ContextWrapper还有另一个常见的子类：Service。来看看Service如何关联ContextImpl的。
#ActivityThread.java
private void handleCreateService(CreateServiceData data) {
//获取LoadedApk
LoadedApk packageInfo = getPackageInfoNoCheck(
data.info.applicationInfo, data.compatInfo);
Service service = null;
try {
java.lang.ClassLoader cl = packageInfo.getClassLoader();
//创建service
service = packageInfo.getAppFactory()
.instantiateService(cl, data.info.name, data.intent);
} catch (Exception e) {
}
try {
//创建ContextImpl
ContextImpl context = ContextImpl.createAppContext(this, packageInfo);
//contextImpl 持有该Service
context.setOuterContext(service);
Application app = packageInfo.makeApplication(false, mInstrumentation);
//初始化Service一些成员变量，关联ContextImpl
service.attach(context, this, data.info.name, data.token, app,
ActivityManager.getService());
//service onCreate方法，一般会重写该方法监听service的创建
service.onCreate();
} catch (Exception e) {
}
}
接着看看service.attach(...)
public final void attach(
Context context,
ActivityThread thread, String className, IBinder token,
Application application, Object activityManager) {
//关联ContextImpl
attachBaseContext(context);
mThread = thread; // NOTE: unused - remove?
mClassName = className;
mToken = token;
mApplication = application;
mActivityManager = (IActivityManager)activityManager;
mStartCompatibility = getApplicationInfo().targetSdkVersion
< Build.VERSION_CODES.ECLAIR;
}
以上，ContextImpl和Service关联起来了。
Activity
ContextWrapper还有一个子类ContextThemeWrapper。
ContextThemeWrapper顾名思义，和主题相关的。
{
//主题资源id
private int mThemeResource;
//theme
private Resources.Theme mTheme;
private LayoutInflater mInflater;
private Configuration mOverrideConfiguration;
private Resources mResources;
}
而Activity继承自ContextThemeWrapper，来看看Activity和ContextImpl如何关联上的。
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
//省略...
//创建ContextImp
ContextImpl appContext = createBaseContextForActivity(r);
//创建Activity
Activity activity = mInstrumentation.newActivity(
cl, component.getClassName(), r.intent);
//关联ContextImpl和activity
appContext.setOuterContext(activity);
//初始化Activity成员变量
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, window, r.configCallback,
r.assistToken);
//省略
}
类似的，继续看activity.attach(...)
最终也是调用到了ContextWrapper attachBaseContext(...)，关联mBase。
BroadcastReceiver
BroadcastReceiver 并没有继承自Context，但可以在onReceive(...)里拿到Context，那么这个Context是怎么来的呢？
Context作为参数传进来的，那么就看看onReceive(...)的调用栈。
#ActivityThread.java
private void handleReceiver(ReceiverData data) {
//省略...
Application app;
BroadcastReceiver receiver;
ContextImpl context;
try {
app = packageInfo.makeApplication(false, mInstrumentation);
//用的是Application的mBase，也就是ContextImpl
context = (ContextImpl) app.getBaseContext();
//构造receiver
receiver = packageInfo.getAppFactory()
.instantiateReceiver(cl, data.info.name, data.intent);
} catch (Exception e) {}
try {
//调用onReceive
receiver.onReceive(context.getReceiverRestrictedContext(),
data.intent);
} catch (Exception e) {
} finally {
}
}
我们注意到context.getReceiverRestrictedContext()：
#ContextImpl.java
final Context getReceiverRestrictedContext() {
//ReceiverRestrictedContext 是ContextWrapper的子类
if (mReceiverRestrictedContext != null) {
return mReceiverRestrictedContext;
}
//该Context是关联Application的，也即是ContextImpl，因此getOuterContext()返回的是
//Application实例。最后ReceiverRestrictedContext的mBase指向Application实例
return mReceiverRestrictedContext = new ReceiverRestrictedContext(getOuterContext());
}
因此我们得出结论是：
onReceive里的Context是ReceiverRestrictedContext类型，继承自ContextWrapper，其mBase指向Application。
可以看出，mBase不一定是ContextImpl类型，但是最终都会调用到ContextImpl。
ContentProvider
ContentProvider没有继承自Context，但是其成员变量mContext是Context类型的，那么这个变量是怎么赋值的呢？
在构造ContextImpl时，会初始化ContentResolver
mContentResolver = new ApplicationContentResolver(this, mainThread);
这个this即是ContextImpl自身，传进去赋值给了ContentResolver变量：
private final Context mContext;
当使用ContentResolver查询ContentProvider并且创建ContentProvider的时候，这个mContext就赋值给ContentProvider的mContext。
上面分析了Application和四大组件与Context关系，用图表示：
Context与Resources
之前列举了Context的用处，最常用的莫过于通过Context获取资源文件（Resources），具体情况是怎么样的，接下来分析。
Context并没有Resources类型的成员变量，ContextWrapper也没有，ContextImpl有成员变量：
private @NonNull Resources mResources;
而Context里有获取Resources的成员方法:
public abstract Resources getResources();
最终会调用ContextImpl，返回mResources。因此重点是ContextImpl的mResources如何赋值的。
上面提到过，Application/Activity/Service等关联ContextImpl时，会新构造一个ContextImpl实例，在初始化的时候，会给mResources赋值。而Resources是通过ResourcesManager管理的，最终来看ResourcesManager如何管理Resources的。
ResourcesManager
Resources 和 ResourcesImpl
Resources里有个成员变量：
private ResourcesImpl mResourcesImpl;
顾名思义，Resources具体加载资源是通过ResourcesImpl实现的。
ResourcesImpl里成员变量：
final AssetManager mAssets;
AssetManager负责与底层通信（操作文件）。
ResourcesManager获取Resources核心代码：
Resources getOrCreateResources(@android.annotation.Nullable IBinder activityToken,
@NonNull ResourcesKey key, @NonNull ClassLoader classLoader) {
//ResourcesKey 记录着资源文件的路径、Configuration等信息，最后用来生成AssetManager
synchronized (this) {
//activityToken 不为空，说明是Activity的Resource
if (activityToken != null) {
//从ResourcesImpl 的Map里寻找相应的缓存
ResourcesImpl resourcesImpl = findResourcesImplForKeyLocked(key);
if (resourcesImpl != null) {
return getOrCreateResourcesForActivityLocked(activityToken, classLoader,
resourcesImpl, key.mCompatInfo);
}
} else {
//非Activity的Resource
ResourcesImpl resourcesImpl = findResourcesImplForKeyLocked(key);
if (resourcesImpl != null) {
return getOrCreateResourcesLocked(classLoader, resourcesImpl, key.mCompatInfo);
}
}
//没找到现成的，生成ResourcesImpl 实例
//同时创建AssetManager
ResourcesImpl resourcesImpl = createResourcesImpl(key);
if (resourcesImpl == null) {
return null;
}
//记录到Map里
mResourceImpls.put(key, new WeakReference<>(resourcesImpl));
final Resources resources;
if (activityToken != null) {
//Activity Resource
resources = getOrCreateResourcesForActivityLocked(activityToken, classLoader,
resourcesImpl, key.mCompatInfo);
} else {
//非Activity Resource
resources = getOrCreateResourcesLocked(classLoader, resourcesImpl, key.mCompatInfo);
}
return resources;
}
}
总结来说：
1、通过ResourcesKey去检索之前是否创建过ResourcesImpl，如果没有则创建新的对象，并记录到Map里。
2、通过ArrayList遍历寻找可以复用的Resources对象，判断的依据是传入的ResourcesImpl与已有的相等（其中的条件）。如果没有可以复用的，则创建Resources对象，设置ResourcesImpl，并将Resources对象放入List等待下次复用。
3、可以看出ResourcesManager通过设置缓存来管理Resource。而ResourcesManager是单例，Context通过getResources(...)获取Resource本质是通过ResourcesManager获取的。
接下来看看Application/Service/Activity获取的Resource是同一个Resource吗？
ActivityThread为Application/Service创建ContextImpl时使用如下方法：
#ContextImpl.java
static ContextImpl createAppContext(ActivityThread mainThread, LoadedApk packageInfo,
String opPackageName) {
ContextImpl context = new ContextImpl(null, mainThread, packageInfo, null, null, null, 0,
null, opPackageName);
//从packageInfo 获取resources
context.setResources(packageInfo.getResources());
return context;
}
packageInfo.getResources():
#LoadedApk
public Resources getResources() {
//LoadedApk是全局的，因此它的mResources也只有一个
if (mResources == null) {
mResources = ResourcesManager.getInstance().getResources(null, mResDir,
splitPaths, mOverlayDirs, mApplicationInfo.sharedLibraryFiles,
Display.DEFAULT_DISPLAY, null, getCompatibilityInfo(),
getClassLoader());
}
return mResources;
}
可以看出，通过createAppContext(xx)创建的ContextImpl共用同一个Resources对象。
而ActivityThread为Activity创建ContextImpl时使用的是：
#ContextImpl.java
static ContextImpl createActivityContext(ActivityThread mainThread,
LoadedApk packageInfo, ActivityInfo activityInfo, IBinder activityToken, int displayId,
Configuration overrideConfiguration) {
ContextImpl context = new ContextImpl(null, mainThread, packageInfo, activityInfo.splitName,
activityToken, null, 0, classLoader, null);
final ResourcesManager resourcesManager = ResourcesManager.getInstance();
//通过resourcesManager 获取
context.setResources(resourcesManager.createBaseActivityResources(activityToken,
packageInfo.getResDir(),
splitDirs,
packageInfo.getOverlayDirs(),
packageInfo.getApplicationInfo().sharedLibraryFiles,
displayId,
overrideConfiguration,
compatInfo,
classLoader));
return context;
}
可以看出，直接使用了ResourcesManager获取Resource，最终不同的Activity获取的Resource对象不同，但是共用同一个ResourcesImpl对象。
不同Context关联与使用
这么多的Context，什么时候该使用哪种Context呢？以下列举几个易混的地方。
启动Activity
public void startActivity(Intent intent, Bundle options) {
final int targetSdkVersion = getApplicationInfo().targetSdkVersion;
//targetSdkVersion 小于7.0 或者大于9.0时
//通过ContextImpl启动Activity，如果没有加入FLAG_ACTIVITY_NEW_TASK，则抛出异常
if ((intent.getFlags() & Intent.FLAG_ACTIVITY_NEW_TASK) == 0
&& (targetSdkVersion < Build.VERSION_CODES.N
|| targetSdkVersion >= Build.VERSION_CODES.P)
&& (options == null
|| ActivityOptions.fromBundle(options).getLaunchTaskId() == -1)) {
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);
}
TargetSdkVersion相关请查看：targetSdkVersion、compileSdkVersion、minSdkVersion作用与区别
非得要用非Activity的Context启动Activity，只需要加入FLAG_ACTIVITY_NEW_TASK标记即可。建议持有当前栈顶Activity对象引用，通过Activity启动另一个Activity。
启动Dialog
非Activity Context启动Dialog会失败。原因是：
Activity带有IBinder appToken，Window关联WindowManager时会将appToken赋予Window的IBinder mAppToken，在添加Window到WindowManagerService过程中，会将mAppToken赋值给WindowManager.LayoutParams IBinder token。WindowManagerService检查添加窗口的合法性，发现如果要添加的窗口类型是Dialog，但是有没有Token，则抛出异常。
Activity启动Dialog时，Dialog获取的WindowManager即是Activity的WindowManager，其parentWindow是Activity的Window，而Activity的Window是有token的，最后该token赋值给LayoutParams。
Activity Window的关系有兴趣请查看：Android Activity创建到View的显示过程
因此启动Dialog需要Activity作为Context传进去。
View的Context
View的Context mContext变量是在创建View对象时赋值的。我们知道创建View对象有两种方式：
1、动态创建new View(Context)，此时决定于传入的Context。
2、xml布局，最终是通过LayoutInflater加载的。LayoutInflater from(Context context)，该context最终传给View。
View的Context并没有明确限制需要使用什么类型。但是如果没有使用Activity作为Context的话，就无法使用Activity Theme的特性。
主题相关请移步：
全网最深入 Android Style/Theme/Attr/Styleable/TypedArray 清清楚楚明明白白
自从看了这篇文章，妈妈再也不担心我不会Android 事件分发了
Android 输入事件一撸到底之View接盘侠（3）
