参考文献:刘望舒《Android进阶解密》
前言
看了数篇分析Activity启动流程的文章,但是自从看了《Android进阶解密》关于Activity启动流程的分析,我就放弃了自己撸一遍的念头。因为书里关于这部分的分析比较详细。这里记录一下书中关于Activity的启动流程。加深一下印象,便于以后温习查看。
Activity的启动过程分为两种,一种是根Activity的启动过程,可以认为是初次点击桌面的应用图标,启动Manifest中注册的作为应用的启动页面的Activity。根Activity的启动过程也可以理解为应用程序的启动过程。另一种就是普通Activity的启动过程,也就是根Activity以外的Activity的启动过程。这两种Activity的启动过程有重叠的部分,但是根Activity一般理解为应用程序的启动过程,更具有指导意义。因此本文就根Activity的启动过程进行分析。
谈到Activity的启动流程就绕不开ActivityManagerService(简称AMS),它主要负责四大组件的启动、切换、调度以及进程的管理,是Android中最核心的服务,参与了所有应用程序的启动管理。Activity的启动流程围绕AMS,可以大致分为3个部分:
- Launcher请求AMS的过程
- AMS到ApplicationThread的调用过程
- ActivityThread启动Activity的过程
下面就针对这3个部分逐一进行分析。
1.Launcher请求AMS的过程
该过程的时序图如下:
当我们点击桌面的应用快捷图标时,就会调用Launcher的startActivitySafely方法:
public boolean startActivitySafely(View v, Intent intent, ItemInfo item) {
...
// Prepare intent
// 注释1
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
...
// Could be launching some bookkeeping activity
// 注释2
startActivity(intent, optsBundle);
...
}
对于不太需要关注的代码省略了,主要是走调用流程,对关键代码进行分析,在注释1处将Flag设置为Intent.FLAG_ACTIVITY_NEW_TASK,这样根Activity会在新的任务栈中启动。在注释2处调用startActivity方法,这个方法在Activity中实现,Activity中startActivity方法有好几种重载方式,但它们最终都会调用startActivityForResult方法:
public void startActivityForResult(@RequiresPermission Intent intent, int requestCode,
@Nullable Bundle options) {
// 注释1
if (mParent == null) {
options = transferSpringboardActivityOptions(options);
// 注释2
Instrumentation.ActivityResult ar =
mInstrumentation.execStartActivity(
this, mMainThread.getApplicationThread(), mToken, this,
intent, requestCode, options);
...
} else {
...
}
}
注释1处的mParent是Activity类型的,表示当前Activity的父类,因为目前根Activity还没有创建出来,因此mParent==null成立,执行注释2处的逻辑,调用Instrumentation的execStartActivity方法,Instrumentation主要是用来监控应用程序和系统的交互,execStartActivity方法代码如下:
public ActivityResult execStartActivity(
Context who, IBinder contextThread, IBinder token, Activity target,
Intent intent, int requestCode, Bundle options) {
...
try {
intent.migrateExtraStreamToClipData();
intent.prepareToLeaveProcess(who);
// 注释1
int result = ActivityManager.getService()
.startActivity(whoThread, who.getBasePackageName(), intent,
intent.resolveTypeIfNeeded(who.getContentResolver()),
token, target != null ? target.mEmbeddedID : null,
requestCode, 0, null, options);
checkStartActivityResult(result, intent);
} catch (RemoteException e) {
throw new RuntimeException("Failure from system", e);
}
return null;
}
核心逻辑就是注释1的代码,首先调用ActivityManager的getService方法来获取AMS的代理对象,接着调用startActivity方法。我们先进入ActivityManager的getService方法:
public static IActivityManager getService() {
return IActivityManagerSingleton.get();
}
private static final Singleton<IActivityManager> IActivityManagerSingleton =
new Singleton<IActivityManager>() {
@Override
protected IActivityManager create() {
// 注释1
final IBinder b = ServiceManager.getService(Context.ACTIVITY_SERVICE);
// 注释2
final IActivityManager am = IActivityManager.Stub.asInterface(b);
return am;
}
};
getService方法调用了IActivityManagerSingleton的get方法,看一下Singleton代码
public abstract class Singleton<T> {
private T mInstance;
protected abstract T create();
public final T get() {
synchronized (this) {
if (mInstance == null) {
mInstance = create();
}
return mInstance;
}
}
}
不难发现IActivityManagerSingleton的get方法,会调用create方法,在注释1处得到IBinder类型的AMS引用,接着在注释2处将它转化成IActivityManager类型的对象,即AMS的代理对象,这段代码采用的是AIDL,IActivityManager.java类是由AIDL工具在编译时自动生成的。AMS继承IActivityManager.Stub类并实现相关方法。通过这个代理对象和AMS(AMS所在的进程为SystemServer系统服务进程)进行跨进程通信,如果你对Binder机制有一定的认识,这里就比较好理解。如果还不太熟悉Binder机制,强烈建议一定要补一下,要不然分析源码总会一知半解的。需要注意的Android8.0之前并没有采用AIDL,是用AMS的代理对象ActivityManagerProxy来与AMS进行跨进程通信的。Android8.0去除了ActivityManagerNative的内部类ActivityManagerProxy,代替它的是IActivityManager,它就是AMS的代理对象。经过上面的分析,我们知道execActivity方法最终调用的是AMS的startActivity方法。补充一句,这里就由Launcher进程经过一系列调用到了SystemServer进程,可以简单概括为下图:
2.AMS到ApplicationThread的调用过程
Launcher请求AMS后,代码逻辑进入AMS中,接着是AMS到ApplicationThread的调用流程,时序图如下:
AMS的startActivity方法如下:
@Override
public final int startActivity(IApplicationThread caller, String callingPackage,
Intent intent, String resolvedType, IBinder resultTo, String resultWho,
int requestCode, int startFlags, ProfilerInfo profilerInfo, Bundle bOptions) {
return startActivityAsUser(caller, callingPackage, intent, resolvedType, resultTo,
resultWho, requestCode, startFlags, profilerInfo, bOptions,
UserHandle.getCallingUserId());
}
AMS的startActivity方法中返回了startActivityAsUser方法,可以发现startActivityAsUser方法比startActivity方法多了一个参数UserHandle.getCallingUserId(),这个方法会获得调用者的UserId,AMS根据这个UserId来确定调用者的权限。下面进入startActivityAsUser方法:
@Override
public final int startActivityAsUser(IApplicationThread caller, String callingPackage,
Intent intent, String resolvedType, IBinder resultTo, String resultWho,
int requestCode,int startFlags, ProfilerInfo profilerInfo, Bundle bOptions,
int userId) {
// 注释1
// 判断调用者进程是否被隔离
enforceNotIsolatedCaller("startActivity");
// 注释2
// 检查调用者的权限
userId = mUserController.handleIncomingUser(Binder.getCallingPid(),
Binder.getCallingUid(),userId, false, ALLOW_FULL_ONLY,
"startActivity", null);
// TODO: Switch to user app stacks here.