Android 应用 Context 详解及源码解析，Android 大厂技术面试题汇总
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;
}
......
}
该类的构造函数包含了一个真正的 Context 引用（ContextImpl 对象），然后就变成了 ContextImpl 的装饰着模式。
再来看看 ContextWrapper 的子类 ContextThemeWrapper 源码注释：
/**
A ContextWrapper that allows you to modify the theme from what is in the
wrapped context.
*/
public class ContextThemeWrapper extends ContextWrapper {
......
}
该类内部包含了主题 Theme 相关的接口，即 android:theme 属性指定的。
再来看看 Activity、Service、Application 类的继承关系源码：
public class Activity extends ContextThemeWrapper
implements LayoutInflater.Factory2,
Window.Callback, KeyEvent.Callback,
OnCreateContextMenuListener, ComponentCallbacks2,
Window.OnWindowDismissedCallback {
......
}
public abstract class Service extends ContextWrapper implements ComponentCallbacks2 {
......
}
public class Application extends ContextWrapper implements ComponentCallbacks2 {
......
}
看见没有？他们完全符合上面我们绘制的结构图与概述。
2-3 解决应用 Context 个数疑惑
有了上面的 Context 继承关系验证与分析之后我们来看下一个应用程序到底有多个 Context？
Android 应用程序只有四大组件，而其中两大组件都继承自 Context，另外每个应用程序还有一个全局的 Application 对象。所以在我们了解了上面继承关系之后我们就可以计算出来 Context 总数，如下：
APP Context 总数 = Application 数(1) + Activity 数(Customer) + Service 数(Customer);
到此，我们也明确了 Context 是啥，继承关系是啥样，应用中 Context 个数是多少的问题。接下来就有必要继续深入分析这些 Context 都是怎么来的。
【工匠若水 http://blog.csdn.net/yanbober 转载烦请注明出处，尊重分享成果】
3 各种 Context 在 ActivityThread 中实例化过程源码分析
在开始分析之前还是和《Android异步消息处理机制详解及源码分析》的 3-1-2 小节及《Android应用setContentView与LayoutInflater加载解析机制源码分析》的 2-6 小节一样直接先给出关于 Activity 启动的一些概念，后面会写文章分析这一过程。
Context 的实现是 ContextImpl，Activity 与 Application 和 Service 的创建都是在 ActivityThread 中完成的，至于在 ActivityThread 何时、怎样调运的关系后面会写文章分析，这里先直接给出结论，因为我们分析的重点是 Context 过程。
3-1 Activity 中 ContextImpl 实例化源码分析
通过 startActivity 启动一个新的 Activity 时系统会回调 ActivityThread 的 handleLaunchActivity()方法，该方法内部会调用 performLaunchActivity()方法去创建一个 Activity 实例，然后回调 Activity 的 onCreate()等方法。所以 Activity 的 ContextImpl 实例化是在 ActivityThread 类的 performLaunchActivity 方法中，如下：
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
......
//已经创建好新的 activity 实例
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;
}
看见上面 performLaunchActivity 的核心代码了吗？通过createBaseContextForActivity(r, activity);创建 appContext，然后通过 activity.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.attach，也就是 Activity 中的 attach 方法，如下：
final void attach(Context context, ActivityThread aThread,
Instrumentation instr, IBinder token, int ident,
Application application, Intent intent, ActivityInfo info,
CharSequence title, Activity parent, String id,
NonConfigurationInstances lastNonConfigurationInstances,
Configuration config, String referrer, IVoiceInteractor voiceInteractor) {
//特别特别留意这里！！！
//与上面 createBaseContextForActivity 方法中 setOuterContext 语句类似，不同的在于：
//通过 ContextThemeWrapper 类的 attachBaseContext 方法，将 createBaseContextForActivity 中实例化的 ContextImpl 对象传入到 ContextWrapper 类的 mBase 变量，这样 ContextWrapper（Context 子类）类的成员 mBase 就被实例化为 Context 的实现类 ContextImpl
attachBaseContext(context);
......
}
通过上面 Activity 的 Context 实例化分析再结合上面 Context 继承关系可以看出：
Activity 通过 ContextWrapper 的成员 mBase 来引用了一个 ContextImpl 对象，这样，Activity 组件以后就可以通过这个 ContextImpl 对象来执行一些具体的操作（启动 Service 等）；同时 ContextImpl 类又通过自己的成员 mOuterContext 引用了与它关联的 Activity，这样 ContextImpl 类也可以操作 Activity。
SO，由此说明一个 Activity 就有一个 Context，而且生命周期和 Activity 类相同（记住这句话，写应用就可以避免一些低级的内存泄漏问题）。
3-2 Service 中 ContextImpl 实例化源码分析
写 APP 时我们通过 startService 或者 bindService 方法创建一个新 Service 时就会回调 ActivityThread 类的 handleCreateService()方法完成相关数据操作（具体关于 ActivityThread 调运 handleCreateService 时机等细节分析与上面 Activity 雷同，后边文章会做分析）。具体 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) {
......
}
}
再来看看 service.attach，也就是 Service 中的 attach 方法，如下：
public final void attach(
Context context,
ActivityThread thread, String className, IBinder token,
Application application, Object activityManager) {
//特别特别留意这里！！！
//与上面 handleCreateService 方法中 setOuterContext 语句类似，不同的在于：
//通过 ContextWrapper 类的 attachBaseContext 方法，将 handleCreateService 中实例化的 ContextImpl 对象传入到 ContextWrapper 类的 mBase 变量，这样 ContextWrapper（Context 子类）类的成员 mBase 就被实例化为 Context 的实现类 ContextImpl
attachBaseContext(context);
......
}
可以看出步骤流程和 Activity 的类似，只是实现细节略有不同而已。
SO，由此说明一个 Service 就有一个 Context，而且生命周期和 Service 类相同（记住这句话，写应用就可以避免一些低级的内存泄漏问题）。
3-3 Application 中 ContextImpl 实例化源码分析
当我们写好一个 APP 以后每次重新启动时都会首先创建 Application 对象（每个 APP 都有一个唯一的全局 Application 对象，与整个 APP 的生命周期相同）。创建 Application 的过程也在 ActivityThread 类的 handleBindApplication()方法完成相关数据操作（具体关于 ActivityThread 调运 handleBindApplication 时机等细节分析与上面 Activity 雷同，后边文章会做分析）。而 ContextImpl 的创建是在该方法中调运 LoadedApk 类的 makeApplication 方法中实现，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;
}
接着看看 Instrumentation.newApplication 方法。如下源码：
public Application newApplication(ClassLoader cl, String className, Context context)
throws InstantiationException, IllegalAccessException,
ClassNotFoundException {
return newApplication(cl.loadClass(className), context);
}
继续看重载两个参数的 newApplication 方法，如下：
static public Application newApplication(Class<?> clazz, Context context)
throws InstantiationException, IllegalAccessException,
ClassNotFoundException {
......
//继续传递 context
app.attach(context);
return app;
}
继续看下 Application 类的 attach 方法，如下：
final void attach(Context context) {
//特别特别留意这里！！！
//与上面 makeApplication 方法中 setOuterContext 语句类似，不同的在于：
//通过 ContextWrapper 类的 attachBaseContext 方法，将 makeApplication 中实例化的 ContextImpl 对象传入到 ContextWrapper 类的 mBase 变量，这样 ContextWrapper（Context 子类）类的成员 mBase 就被实例化为 Application 的实现类 ContextImpl
attachBaseContext(context);
......
}
可以看出步骤流程和 Activity 的类似，只是实现细节略有不同而已。
SO，由此说明一个 Application 就有一个 Context，而且生命周期和 Application 类相同（然而一个 App 只有一个 Application，而且与应用生命周期相同）。
4 应用程序 APP 各种 Context 访问资源的唯一性分析
你可能会有疑问，这么多 Context 都是不同实例，那么我们平时写 App 时通过 context.getResources 得到资源是不是就不是同一份呢？下面我们从源码来分析下，如下：
class ContextImpl extends Context {
......
private final ResourcesManager mResourcesManager;
private final Resources mResources;
......
@Override
public Resources getResources() {
return mResources;
}
......
}
看见没，有了上面分析我们可以很确定平时写的 App 中 context.getResources 方法获得的 Resources 对象就是上面 ContextImpl 的成员变量 mResources。那我们追踪可以发现 mResources 的赋值操作如下：
还未添加个人签名 2021.10.31 加入
还未添加个人简介
评论