一.简介
Android应用模型是基于组件的应用设计模式，组件的运行要有一个完整的Android工程环境，在这个环境下，Activity、Service等系统组件才能够正常工作，而这些组件并不能采用普通的Java对象创建方式，new一下就能创建实例了，而是要有它们各自的上下文环境，也就是我们这里讨论的Context。可以这样讲，Context是维持Android程序中各组件能够正常工作的一个核心功能类。
源码中的注释是这么来解释Context：Context提供了关于应用环境全局信息的接口。它是一个抽象类，它的执行被Android系统所提供。它允许获取以应用为特征的资源和类型，是一个统领一些资源（应用程序环境变量等）的上下文。
Context描述一个应用程序环境的信息（即上下文）；Android提供了该抽象类的具体实现类；通过它我们可以获取应用程序的资源和类(包括应用级别操作，如启动Activity，发广播，接受Intent等)。
主要作用
a.四大组件的交互，包括启动 Activity、Broadcast、Service，获取 ContentResolver 等。
b.获取系统/应用资源，包括 AssetManager、PackageManager、Resources、System Service 以及 color、string、drawable 等。
c.文件，包括获取缓存文件夹、删除文件、SharedPreference 相关等。
d.数据库（SQLite）相关，包括打开数据库、删除数据库、获取数据库路径等。
二.继承关系
既然上面Context是一个抽象类，那么肯定有对应的实现类，通过查看源码，可以看到对应的关系图：
context继承关系.png
a.ContextImpl类
ContextImpl继承Context抽象类，实现了Context类中的抽象方法，是Context的具体实现类；它为Activity和其他应用程序组件提供基本上下文对象，应用中使用 Context的时候的方法就是它实现的。
b.ContextWrapper
ContextWrapper继承Context抽象类，作为Context类的包装类，其内部维护了一个Context类型的成员变量mBase，mBase最终会指向一个ContextImpl对象，ContextWrapper的方法其内部依赖mBase，ContextWrapper是Context类的修饰类(装饰器模式)，真正的实现类是 ContextImpl，ContextWrapper 里面的方法调用也是调用 ContextImpl 里面的方法。
c.ContextThemeWrapper
ContextThemeWrapper继承ContextWrapper，因此也拥有一个Context类型的成员变量mBase，mBase最终会指向一个ContextImpl对象，它的一个直接子类就是 Activity，所以Activity也就拥有了Context提供的所有功能。
d.Context类型
通过 Context 的继承关系图可以看到，Activity、Service、Application都是Context的子类，可以认为Context一共有三种类型，分别是 Application、Activity 和Service，他们分别承担不同的作用，但是都属于 Context，而他们具有 Context 的功能则是由ContextImpl 类实现的。
1.Application：继承ContextWrapper，因此也拥有一个Context类型的成员变量mBase，mBase最终会指向一个ContextImpl对象，ContextImpl是Context的具体实现类，所以Application也就拥有了Context提供的所有功能。
2.Service：继承ContextWrapper，因此也拥有一个Context类型的成员变量mBase，mBase最终会指向一个ContextImpl对象，ContextImpl是Context的具体实现类，所以Service也就拥有了Context提供的所有功能。
3.Activity：继承ContextThemeWrapper，ContextThemeWrapper继承ContextWrapper，因此也拥有一个Context类型的成员变量mBase，mBase最终会指向一个ContextImpl对象，ContextImpl是Context的具体实现类，所以Activity也就拥有了Context提供的所有功能。
三.作用域
context作用域.png
只有 Activity 显示界面，正因为如此，Activity 继承的是 ContextThemeWrapper 提供一些关于主题，界面显示的能力，间接继承了 ContextWrapper ；凡是跟 UI 有关的，都应该用 Activity 作为 Context 来处理，否则要么会报错，要么 UI 会使用系统默认的主题。
四.对应Display的Context
该场景适用于多屏扩展，比如：在不同的Display上弹出Toast及addView()，Toast的显示也是通过WindowManager.addView()来实现的，那么是如何区分在哪个Display上显示呢？不兜弯子，直接上代码：
DisplayManager displayManager = (DisplayManager) context.getSystemService(Context.DISPLAY_SERVICE);
Context context = context.createDisplayContext(displayManager.getDisplay(Display.SECOND_DISPLAY));
WindowManager wm = (WindowManager) context.getSystemService(Context.WINDOW_SERVICE);
w.addView(view, params);
通过以上代码就可以实现在对应Display上显示view，可以看到关键方法是createDisplayContext(Display display)，一起看一下该方法在 ContextImpl.java中的实现：
@Override
public Context createDisplayContext(Display display) {
ContextImpl context = new ContextImpl(this, mMainThread, mPackageInfo, mSplitName,
mActivityToken, mUser, mFlags, mClassLoader);
final int displayId = display.getDisplayId();
context.setResources(createResources(mActivityToken, mPackageInfo, mSplitName, displayId,
null, getDisplayAdjustments(displayId).getCompatibilityInfo()));
context.mDisplay = display;
return context;
}
ContextImpl对象有变量mDisplay，记录了对应的Display，之前分析过系统服务调用分析，通过Context.getSystemService()来获取系统服务，本文以WindowManager来举例：
@Override
public Object getSystemService(String name) {
return SystemServiceRegistry.getSystemService(this, name);
}
可以看到，在调用SystemServiceRegistry.getSystemService(this, name)时，会将this传入，再接着往下看：
public static Object getSystemService(ContextImpl ctx, String name) {
ServiceFetcher<?> fetcher = SYSTEM_SERVICE_FETCHERS.get(name);
return fetcher != null ? fetcher.getService(ctx) : null;
}
registerService(Context.WINDOW_SERVICE, WindowManager.class,
new CachedServiceFetcher<WindowManager>() {
@Override
public WindowManager createService(ContextImpl ctx) {
return new WindowManagerImpl(ctx);
}});
可以看到，在createService时会将ContextImpl作为参数传入，那么在获取WindowManager时，返回的是其实现类WindowManagerImpl对象，接着往下看：
public WindowManagerImpl(Context context) {
this(context, null);
}
private WindowManagerImpl(Context context, Window parentWindow) {
mContext = context;
mParentWindow = parentWindow;
}
在创建WindowManagerImpl对象时会保存mContext对象，那么当执行WindowManager.addView()时，看一下逻辑处理：
@Override
public void addView(@NonNull View view, @NonNull ViewGroup.LayoutParams params) {
mGlobal.addView(view, params, mContext.getDisplay(), mParentWindow);
}
可以看到，在执行addView()时，最终会调用到WindowManagerGlobal的addView()方法，此时会通过mContext.getDisplay()获取到创建Context时传入的Display，从而将view添加到对应的Display上。
还有一种场景，比如显式配置应用在指定Display上进行启动，那么该如何指定Activity的context对应指定的Display呢？
我们知道，在启动一个Activity时，通过AMS会回调到应用进程的ActivityThread内部的performLaunchActivty()方法，该方法内部会创建ContextImpl实例，通过attach()赋值给Actiivty内部，一起看一下：
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
.........................
ContextImpl appContext = createBaseContextForActivity(r);
...........................
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);
...................
}
通过createBaseContextForActivity()来创建ContextImpl实例appContext，看一下创建过程：
private ContextImpl createBaseContextForActivity(ActivityClientRecord r) {
final int displayId;
try {
displayId = ActivityManager.getService().getActivityDisplayId(r.token);
} catch (RemoteException e) {
throw e.rethrowFromSystemServer();
}
ContextImpl appContext = ContextImpl.createActivityContext(
this, r.packageInfo, r.activityInfo, r.token, displayId, r.overrideConfig);
final DisplayManagerGlobal dm = DisplayManagerGlobal.getInstance();
// For debugging purposes, if the activity's package name contains the value of
// the "debug.use-second-display" system property as a substring, then show
// its content on a secondary display if there is one.
String pkgName = SystemProperties.get("debug.second-display.pkg");
if (pkgName != null && !pkgName.isEmpty()
&& r.packageInfo.mPackageName.contains(pkgName)) {
for (int id : dm.getDisplayIds()) {
if (id != Display.DEFAULT_DISPLAY) {
Display display =
dm.getCompatibleDisplay(id, appContext.getResources());
appContext = (ContextImpl) appContext.createDisplayContext(display);
break;
}
}
}
return appContext;
}
可以看到，在该方法内部会先获取Activity在启动前设置的启动Display对应的displayId，然后通过createActivityContext()将displayId作为参数传入，此时ContextImpl会对应了Display信息；另外如果是调试pkgName(启动到SecondDisplay)，那么会创建SecondDisplay对应的ContextImpl实例并返回，此时ContextImpl也会对应Display信息；
扩展问题：Service中也需要ContextImpl对应Display，那么可以在handleCreateService()内部进行跟上述相同的修改来使Service的ContextImpl也对应Display信息。
private void handleCreateService(CreateServiceData data) {
.....................
ContextImpl context = ContextImpl.createAppContext(this, packageInfo);
//修改为对应Display的ContextImpl
final DisplayManagerGlobal dmg = DisplayManagerGlobal.getInstance();
if (packageInfo.mPackageName != null && dmg.isShowSecondDisplay(packageInfo.mPackageName)) {
for (int id : dmg.getDisplayIds()) {
if (id != Display.DEFAULT_DISPLAY) {
Display display = dmg.getCompatibleDisplay(id, context.getResources());
context = (ContextImpl) context.createDisplayContext(display);
break;
}
}
}
............................
service.attach(context, this, data.info.name, data.token, app,
ActivityManager.getService());
.................
}
五.正确使用Context
一般Context造成的内存泄漏，几乎都是当Context销毁的时候，却因为被引用导致销毁失败，而Application的Context对象可以理解为随着进程存在的，所以我们总结出使用Context的正确姿势：
1：当Application的Context能搞定的情况下，并且生命周期长的对象，优先使用Application的Context。
2：不要让生命周期长于Activity的对象持有Activity的引用。
3：尽量不要在Activity中使用非静态内部类，因为非静态内部类会隐式持有外部类实例的引用，如果使用静态内部类，将外部实例引用作为弱引用持有。
六.其他
a.在自定义MyApplication的构造方法中使用Context
在自定义MyApplication的构造方法中调用Context的getPackageName()[实际是在调用mBase.getPackageName()]时，attachBaseContext(Context base) 还未被系统调用，因此mBase为Null，出现空指针。
Application方法的执行顺序：构造方法>attachBaseContext()方法>onCreate()方法。attachBaseContext(Context base) 是被系统调用的，为mBase赋值为ContextImpl类型的context。
b.一个APP应用Context数量
Context 一共有 Application 、Activity 和 Service 三种类型，因此一个应用程序中 Context 数量的计算公式就可以这样写：
Context 数量 = Activity 数量 + Service 数量 + 1
上面的1代表着 Application 的数量，因为一个应用程序中可以有多个Activity和多个Service，但是只能有一个Application。
c.ContextImpl实例什么时候生成
ContextImpl实例生成对应着mBase的赋值过程：
在启动Activity时，在ActivityThread内部通过handleLaunchActivity()方法一系列调用，在通过Instrucmentation创建完Activity后，会先调用Activity的attach()方法，会传入已创建好的ContextImpl对象，在Attach()方法内部会先调用attachBaseContext(context)方法，会将ContextImpl通过super.attachBaseContext(context)一步一步最后赋值给ContextWrapper的mBase，接下来再调用activity的onCreate()。
d.ContentProvider里的Context初始化
ContentProvider本身不是Context ，但是它有一个成员变量 mContext ，是通过构造函数传入的。mContext初始化对应着ContentProvider创建时机。
应用创建Application是通过调用 ActivityThread.handleBindApplication方法，这个方法的相关流程有：
创建 Application
初始化 Application的Context
调用installContentProviders()并传入刚创建好的context来创建ContentProvider
调用Application.onCreate()
ContentProvider的Context是在Applicaiton创建之后，但是 onCreate方法调用之前初始化的。
以上就是Context的详解及使用中常见的问题！
网友评论