前言

Android开发过程中，Context是绕不开的东西，因此本篇文章将一探究竟。
通过这篇文章，你将了解到：

1、Context衍生的子类
2、Context作用
3、四大组件里的Context
4、Context与Resources
5、不同Context关联与使用

Context家族

Context是抽象类，来看看常见的子类

image.png

上图展示了常见的Context子类的继承关系。
我们平时接触比较多的是Activity、Application、Service。

Context作用

image.png

根据上图，我们主要讲解Resource和四大组件相关的。

四大组件里的Context

Context 子类

Context里没有特别需要留意的成员变量，其成员方法也多靠子类实现。

ContextWrapper

成员变量
遍观ContextWrapper，只有个成员变量：

Context mBase;

成员方法
ContextWrapper重写Context的方法，内部依靠mBase调用，相当于mBase作为其代理。

image.png

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方法具体实现的地方。

image.png
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(...)

image.png
最终也是调用到了ContextWrapper attachBaseContext(...)，关联mBase。
BroadcastReceiver
BroadcastReceiver 并没有继承自Context，但可以在onReceive(...)里拿到Context，那么这个Context是怎么来的呢？
image.png
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。

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关系，用图表示：

image.png

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去检索之前是否创建过ResourceImpls，如果没有则创建新的对象，并记录到Map里。
2、通过ArrayList遍历寻找可以复用的Resources对象，判断的依据是传入的ResourceImpls与已有的相等（其中的条件）。如果没有可以复用的，则创建Resources对象，设置ResourceImpls，并将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创建的ContextImpl，最后都共用一个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并没有明确限制需要使用什么类型。