- 一 context与applicationactivityservice的继承关系
- 二 context与三者的对应关系描述
- 1 Application与Context的关系
- 2 Activity与Context的关系
- 3 Service与Context的关系
- 总结
一 、context与application、activity、service的继承关系
在开发过程中，经常会遇到使用context的情况，如通过context得到resource，通过context实现layoutInflater等，在代码环境中使用context，可用通过activity、application以及service来实现，那么这是为什么呢？
因为三者都是继承自context抽象类的，如下图所示：
可以看到，activity是继承自ContextThemeWrapper，而Service和Application继承自ContextWrapper
对于ContextWrapper和ContextThemeWrapper而言，两者存在继承关系，最终继承自Context，而Context实际上是一个抽象类，它的实现是交给ContextImpl类负责，所以可以先提一下，app在启动时，application、activity和service三者能够关联到context，实际上都是在创建者三个要素的时候，同时实现了ContextImpl对象，具体证明放在之后描述。
知道了activity、service和application与context的关系之后，也就理解了为什么可以把这仨当context来用了，其实context意义为场景，而activity、service及application从语义上理解也是场景的概念。那么还有一个问题，activity等着仨是如何实现各自context的对应关系呢，需要分析app的启动过程了。
二、 context与三者的对应关系描述
在app启动时，或者启动一个新的activity及service中，实际上先由AmS(Activity Manager Service)来负责，AmS在一个进程中，启动的Activity或app是由另一个所在进程ActivityThread来实现，AmS负责管理ActivityThread中的相关具体过程，因此需要实现跨进程间的数据交互，而AmS和ActivityThread的数据交互入口是ActivityThread中的ApplicationThread，ApplicationThread是一个Binder变量，可以接受AmS传递来的数据。2.1 Application与Context的关系
application初启动时，对于ActivityThread中，首先会执行到bindApplication方法，该方法的声明如下：public final void bindApplication(String processName, ApplicationInfo appInfo, List<ProviderInfo> providers, ComponentName instrumentationName, ProfilerInfo profilerInfo, Bundle instrumentationArgs, IInstrumentationWatcher instrumentationWatcher, IUiAutomationConnection instrumentationUiConnection, int debugMode, boolean isRestrictedBackupMode, boolean persistent, Configuration config, CompatibilityInfo compatInfo, Map<String, IBinder> services, Bundle coreSettings )
{
//这里是代码逻辑
}可以在参数列表中发现有一个ApplicationInfo类型的参数appInfo，该数据实际上是由AmS传递过来的，且ApplicationInfo类型实现了Parcelable接口。
在调用了bindApplication方法之后，通过传递来的appInfo，会构建一个AppBindData类型的数据，该数据构建完成之后，会由ActivityThread的内部Handler发送一个消息：sendMessage(H.BIND_APPLICATION, data);此时，ActivityThread由于实现了Handler的handleMessage，所以在收到消息为BIND_APPLICATION时会回调handleBindApplication方法,在该方法中可以找到创建Application的过程：
private void handleBindApplication(AppBindData data){
//...省略
Application app = data.info.makeApplication(data, restrictedBackupMode, null);
mInitialApplication = app;
//...省略
}可以看到一个关键方法data.info.makeApplication()
这里的data就是之前创建完成的AppBindData类型的，也是handleBindApplication的传入参数;info是LoadApk类型，在老版本中info实际上就是PackageInfo这个类，所以LoadApk就是PackageInfo，LoadApk这个类中有makeApplication方法，在该方法中存在实现context和application关联的步骤，查看makeApplication方法：public Application makeApplication(){
//省略
ContextImp appContext=ContextImpl.createAppContext(mActivityThread, this);
app = mActivityThread.mInstrumentation.newApplication(cl, appClass, appContext);
appContext.setOuterContext(app);
//省略
}在makeApplication方法中，创建了ContextImpl对象，并在ActivityThread中，通过Instrumentation对象创建了app，然后将app设置为context的外在体现，即setOuterContext方法，该方法如下：final void setOuterContext(Context context){
mOuterContext = context;
}该方法接收一个context对象，把其设置成mOuterContext，其实就是代言人的概念了。
以上就实现了application的创建过程中实现context关联的过程，再由流程图的形式描述一下：
2.2 Activity与Context的关系
activity与context的关系也类似与application的流程，启动activity时，首先也是交由AmS进行处理，AmS会传递一个ActivityInfo类型的数据给ActivityThread，然后ActivityThread拿到了该数据之后执行后续的一系列操作。ActivityInfo也是一个实现Parcelable接口的类型。
ActivityThread接收到创建Activity的命令之后，会首先触发scheduleLaunchActivity方法:
public final void scheduleLaunchActivity(Intent intent, IBinder
token, int ident, ActivityInfo info,
compatInfo, String referrer, IVoiceInteractor
PersistableBundle persistentState,
List<ReferrerIntent> pendingNewIntents,
ProfilerInfo profilerInfo) {
updateProcessState(procState, false);
ActivityClientRecord r = new ActivityClientRecord();
r.token = token;
r.ident = ident;
r.intent = intent;
r.referrer = referrer;
r.voiceInteractor = voiceInteractor;
r.activityInfo = info;
r.compatInfo = compatInfo;
r.state = state;
r.persistentState = persistentState;
r.pendingResults = pendingResults;
r.pendingIntents = pendingNewIntents;
r.startsNotResumed = notResumed;
r.isForward = isForward;
r.profilerInfo = profilerInfo;
updatePendingConfiguration(curConfig);
sendMessage(H.LAUNCH_ACTIVITY, r);
}ScheduleLaunchActivity这个方法相当于在接收到AmS传递来的ActivityInfo之后，执行的预处理工作，这个预处理主要是updateProcessState和构建ActivityClientRecord对象，完成之后sendMessage在handleMessage方法中回调了handleLaunchActivity方法,在该方法中，通过Intent和ActivityClientRecord创建了Activity：
private void handleLaunchActivity(ActivityClientRecord r, Intent customIntent){
//省略
Activity a = performLaunchActvity(r,customIntent);
//省略
}看到了Activity是如何明面上创建的了，接下来执行到performLaunchActivity方法中:
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent){
//省略
Activity activity = null;
try {
java.lang.ClassLoader cl = r.packageInfo.getClassLoader();
activity = mInstrumentation.newActivity(
cl, component.getClassName(), r.intent);
StrictMode.incrementExpectedActivityCount(activity.getClass());
r.intent.setExtrasClassLoader(cl);
r.intent.prepareToEnterProcess();
if (r.state != null) {
r.state.setClassLoader(cl);
}
} catch (Exception e) {
if (!mInstrumentation.onException(activity, e)) {
throw new RuntimeException(
"Unable to instantiate activity " + component
+ ": " + e.toString(), e);
}
}
//...
Context appContext = createBaseContextForActivity(r, activity);
//省略
}从上面的代码中就了解了Activity对象是如何创建的，以及Context对象是如何关联到activity的，可以看看createBaseContextForActivity这个方法的具体实现:private Context createBaseContextForActivity(ActivityClientRecord r, final Activity activity){
ContextImpl appContext =ContextImpl.createActivityContext(this, r.packageInfo, r.token);
appContext.setOuterContext(activity);
Context baseContext = appContext;
//省略
}可以看到在该方法中，同样通过ContextImpl的静态方法createActivityContext来创建ContextImpl对象，然后通过setOuterContext来设置activity为context的外部代言人
整体流程如下：
2.3 Service与Context的关系
与上述两种情况类似，启动Service(注意这里是startService而不是bindService)时，首先AmS进行处理，包装出一个ServiceInfo类型的数据，ActivityThread接收到数据后首先执行scheduleCreateService方法:
public final void scheduleCreateService(IBinder token, ServiceInfo info, CompatibilityInfo compatInfo, int processState){
updateProcessState(processState, false);
CreateServiceData s = new CreateServiceData();
s.token = token;
s.info = info;
s.compatInfo = compatInfo;
sendMessage(H.CREATE_SERVICE, s);
}创建了CreateServiceData之后发送消息CREATE_SERVICE，然后得到handleMessage的响应，进入到handleCreateService方法中:private void handleCreateService(CreateServiceData data){
//省略
ContextImpl context = ContextImpl.createAppContext(this, packageInfo);
context.setOuterContext(service);
Application app = packageInfo.makeApplication(false, mInstrumentation);
service.attach(context, this, data.info.name, data.token, app,
ActivityManagerNative.getDefault());
service.onCreate();
//省略
}在该方法中，首先通过getPackageInfoNoCheck得到了packageInfo对象，根据该对象得到ClassLoader后通过反射构建了service，获取了service对象之后，利用ContextImpl的静态方法得到了context，context设置了service为其外部代言人，之后创建了application，将service attach上去，最后启动onCreate方法。
有一个疑问，为什么在创建了service的过程中需要构建application对象呢？可能是跟后台service依旧属于一个application，虽然没有前台界面的展示，没有明显的application构建，但是service需要依赖application，所以针对无界面、后台service启动的情况下需要创建application为service提供attach支持。整体流程如下：
总结
通过第二部分的分析，可以总结如下：
不论是启动app还是某个activity，亦或是service，最初都需要提交给AmS，AmS相当于总负责人，总负责人处理好消息后打包成数据(ApplicationInfo、ActivityInfo及ServiceInfo)，并将数据通过跨进程传递的方式递交给ActivityThread进行处理，ActivityThread在接收时对外首先暴露ApplicationThread这个Binder接口，然后获取到相应的数据之后执行创建application、activity及service的流程；同时在创建这仨时，通过ContextImpl的静态方法来创建ContextImpl对象，对象创建完成之后通过setOuterContext方法指定各类的外部代言人，但是该方法的参数是Context，而恰好Application、Activity及Service都继承自Context，所有可以有效充当contextImpl的外部代言人，来调用contextImpl中的方法，这就是application、activity及service是context的本质，本质在于以代言人的身份调用方法(好像属于一类设计模式?)。
多提一句，contextImpl内的核心实现其实大部分都在LoadApk方法内具体完成的。
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
