再谈Android各种Context的前世今生！

稳住，今天是周六，大家有啥疑问可以尽管留言，不过今天主休息，但时间较多，留言会抽空慢慢回复。

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的显示过程。

https://www.jianshu.com/p/7e260b7890a3

#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作用与区别。

https://www.jianshu.com/p/12e42558378a

非得要用非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的显示过程

https://www.jianshu.com/p/7e260b7890a3

因此启动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: wanandroid.com ，包含详尽的知识体系、好用的工具，还有本公众号文章合集，欢迎体验和收藏！