Activity的启动流程
基础概念
1、AMS（ActivityManagerService）
定义：
系统服务，负责四大组件、应用进程启动以及管理等工作
2、ATMS（ActivityTaskManagerService）
作用：
在Android Q版本之后，管理activity的启动和调度
3、Instrumentation
定义：
Instrumentation是activity与外界联系的类（不是activity本身的统称外界，相对activity而言），activity通过Instrumentation来请求创建，应用在ActivityThread里通过Instrumentation来创建activity和创建Application。而且它还分发Application和Activity的生命周期
4、ActivityTaskManager（Android Q之后）
定义：
ATMS的客户端
5、IActivityTaskManager
定义：
AIDL文件
6、Launcher
定义：
程序入口
7、ActivityStackSuperVisor
定义：
负责管理所有ActivityStack
8、ActivityStack
定义：
ActivityStack是用来管理TaskRecord的，包含了多个TaskRecord
9、TaskRecord
定义：
一系列相关（可以理解为由不同启动模式启动同名Activity）的ActivityRecord组成了一个TaskRecord
10、ActivityRecord
定义：
ActivityRecord包含了一个Activity的所有信息。每一个ActivityRecord都会有一个Activity与之对应，一个Activity可能会有多个ActivityRecord，因为Activity可以被多次实例化，取决于其launchmode。
包含了部分重要信息：
IApplicationToken.Stub appToken：用来与WMS交互ActivityInfo info：所有信息，包含：theme、launchMode、permission、taskAffinity还有一系列标志位TaskRecordpackageName：包名
11、ActivityManager（Android Q之前）
作用：
同ActivityTaskManager
12、ActivityThread
定义：
ActivityThread，每个应用程序唯一一个实例，负责对接AMS，通过ApplicationThread将AMS对客户端的调用转接给自己，继而分发给应用程序，而ApplicationThread只是应用程序和服务端进程通信的类而已，只负责通信，把AMS的任务交给ActivityThread。
13、ApplicationThread
定义：
ApplicationThread是作为Activitythread和AMS/ATMS通信的桥梁，继承自IApplicationThread.Stub，也就是说它是一个Binder本地对象
14、processRecord
定义：
记录每个进程的信息。
15、ActivityStarter
定义：
真正进行启动Activiyt的类
源码分析
Activity
1、startActivity
要注意的是这里的
startActivity是Activity自己重写的，而Service和Application的startActivity方法是调用了父类ContextWrapper从而调用到ContextImpl的，ContextImpl里面的startActivity有对Flag做了判断：如果不是FLAG_ACTIVITY_NEW_TASK的话，会抛出错误，这也就是为什么Service启动Activity需要加入这个FLAG
public void startActivity(Intent intent, @Nullable Bundle options) {
if (options != null) {
startActivityForResult(intent, -1, options);
} else {
startActivityForResult(intent, -1);
}
}
3、startActivityForResult
这里主要通过一个叫做
Instrumentation的类去处理创建Activity的事务。Instrumentation是Activity与AMS进行交互需要经过的一个类，它不止负责Activity的创建和分发生命周期，同时也负责Application同样的事务
public void startActivityForResult(@RequiresPermission Intent intent, int requestCode,
@Nullable Bundle options) {
//不再有ActivityGroup，因为已经被Fragment替代了
//所以这里一定为true
if (mParent == null) {
//...
//调用Instrumentation的execStartActivity
Instrumentation.ActivityResult ar =
mInstrumentation.execStartActivity(
this, mMainThread.getApplicationThread(), mToken, this,
intent, requestCode, options);
//...
} else {
//...
}
}
Instrumentation
1、execStartActivity
我看源码时候的代码版本是
Android Q之后的，关于Activity的管理已经从AMS转移到另外一个单独的服务ATMS里面了
public ActivityResult execStartActivity(
Context who,IBinder contextThread, IBinder token, Activity target,
Intent intent, int requestCode, Bundle options) {
//...
try {
//在Android Q版本，对Activity的操作已经移到
//ActivityTaskManager
//因此这里获取到的服务是ActivityTaskManagerService
int result = ActivityTaskManager.getService()
.startActivity(whoThread, who.getBasePackageName(), intent,
intent.resolveTypeIfNeeded(who.getContentResolver()),
token, target != null ? target.mEmbeddedID : null,
requestCode, 0, null, options);
} catch (RemoteException e) {
//...
}
return null;
}
ATMS（ActivityTaskManagerService）
1、startActivity
这里的
1~3主要做了权限检查，然后将启动事务交给ActivityStarter
@Override
public final int startActivity(...) {
//调用startActivityAsUser
return startActivityAsUser(...);
}
2、startActivityAsUser
权限检查
@Override
public int startActivityAsUser(...) {
return startActivityAsUser(...);
}
3、startActivityAsUser
将任务交给真正负责启动
Activity的类：ActivityStarter
int startActivityAsUser() {
//...
//1、通过ActivityStartController拿到ActivityStarter
//2、调用ActivityStarter的execute
return getActivityStartController().obtainStarter(intent, "startActivityAsUser")
.setCaller(caller)
.setCallingPackage(callingPackage)
.setResolvedType(resolvedType)
.setResultTo(resultTo)
.setResultWho(resultWho)
.setRequestCode(requestCode)
.setStartFlags(startFlags)
.setProfilerInfo(profilerInfo)
.setActivityOptions(bOptions)
//设置setMayWait(userId)会导致后面为true
.setMayWait(userId)
.execute();
}
ActivityStarter
1、execute
因为在
startActivityAsUser里面有调用setMayWait(userId)，所以这里走的是startActivityMayWait
int execute() {
try {
//因为在构造ActivityStarter的时候有setMayWait
//因此这里为true
if (mRequest.mayWait) {
return startActivityMayWait(...);
} else {
return startActivity(}
} finally {
...
}
}
2、startActivityMayWait
这里主要创建了一个很重要的对象
ActivityRecord数组，用来保存ActivityRecord对象。包括Service、Broadcast都有一个在服务端的记录对象，这个对象包含了可以描述这个Activity的所有信息，同时在客户端也有一个ActivityClientRecord对象与之对应
private int startActivityMayWait(...) {
//...
//1、创建新的ActivityRecord[]数组，长度为1，但是并没有初始化
final ActivityRecord[] outRecord = new ActivityRecord[1];
//2、但在这里并没将它添加到TaskRecord里面，而是将TaskRecord
//和ActivityRecord一起传入方法中
//3、调用startActivity
int res = startActivity(...);
//...
return res;
}
3、startActivity
这里主要将本次要启动的
Activity记录在AMS的内部变量mLastStartActivityResult中
private int startActivity(...) {
//这是第一个startActivity，作用是将即将到启动的Activity
//存入到 “上次尝试启动的活动记录” 数组中
//继续调用下一个
mLastStartActivityResult = startActivity(...);
if (outActivity != null) {
//将即将到启动的Activity存入到 “上次尝试启动的活动记录” 数组中
outActivity[0] = mLastStartActivityRecord[0];
}
return getExternalResult(mLastStartActivityResult);
}
4、startActivity
创建
ActivityRecord，然后存入之前创建的ActivityRecord数组里面
private int startActivity(...) {
//在这里创建了新的ActivityRecord，并将它存入之前创建的
//ActivityRecord[]数组中
ActivityRecord r = new ActivityRecord(...);
if (outActivity != null) {
outActivity[0] = r;
}
//...
//继续调用第三个startActivity
final int res = startActivity(...);
return res;
}
5、startActivity
这里主要是创建了
ActivityStack
private int startActivity(...) {
//正要启动的这个Activity所在的栈
final ActivityStack startedActivityStack;
try {
//停止surface的更新，相当于锁住surface
mService.mWindowManager.deferSurfaceLayout();
//调用startActivityUnchecked
result = startActivityUnchecked(...);
} finally {
//初始化
final ActivityStack currentStack = r.getActivityStack();
startedActivityStack = currentStack != null ? currentStack : mTargetStack;
//继续surface更新
mService.mWindowManager.continueSurfaceLayout();
}
return result;
}
6、startActivityUnchecked（重要）
这里主要做了几件事：
- 1、找到目标
ActivityStack：mTargetStack，然后调用了mTargetStack.startActivityLocked找到所在TaskRecord，并将activity插入到合适位置。 这样Activity的ActivityRecord就加入了对应的TaskRecord里面了- 2、然后调用
mRootActivityContainer.resumeFocusedStacksTopActivities
private int startActivityUnchecked(...) {
//...
//要注意这里是将activity插入taskRecord，并没有做实际启动activity的事情
mTargetStack.startActivityLocked(...);
if (mDoResume) {
//这里才是Activity启动流程的主流程
mRootActivityContainer.resumeFocusedStacksTopActivities(
mTargetStack, mStartActivity, mOptions);
}
//...
return START_SUCCESS;
}
ActivityStack
1、startActivityLocked
这个流程只是
找到activity的TaskRecord，并将activity对应的ActivityRecord插入到TaskRecord的合适位置，到此，应用第一个activity的ActivityRecord已创建，并找到其ActivityStack。最后在ActivityStack中将ActivityRecord插入到所在的TaskRecord的合适位置。
void startActivityLocked(...) {
//...
}
RootActivityContainer
1、resumeFocusedStacksTopActivities
调用
targetStack.resumeTopActivityUncheckedLocked
boolean resumeFocusedStacksTopActivities(...) {
if (!mStackSupervisor.readyToResume()) {
return false;
}
boolean result = false;
if (...) {
//调用targetStack.resumeTopActivityUncheckedLocked
result = targetStack.resumeTopActivityUncheckedLocked(target, targetOptions);
}
//...
return result;
}
ActivityStack
1、resumeTopActivityUncheckedLocked
调用
resumeTopActivityInnerLocked，这部份主要是判断栈顶的Activity是不是要启动的这个，如果是，就resume它
@GuardedBy("mService")
boolean resumeTopActivityUncheckedLocked(...) {
boolean result = false;
try {
//调用resumeTopActivityInnerLocked
result = resumeTopActivityInnerLocked(prev, options);
} finally {
}
return result;
}
2、resumeTopActivityInnerLocked
因为我们看的是
根Activity的启动，所以这里的mResumedActivity其实就是我们的桌面组件——Launcher，如果非根Activity的启动，mResumedActivity就是上一个resume状态的Activity，这里通过startPausingLocked去触发组件的onPause生命周期。
private boolean resumeTopActivityInnerLocked(ActivityRecord prev, ActivityOptions options) {
ActivityRecord next = topRunningActivityLocked(true);
...
if (mResumedActivity != null) {
pausing |= startPausingLocked(userLeaving, false, next, false);
}
...
if (next.attachedToProcess()) {
//...
} else {
//由于activity所在的进程还没生成，所以
//next.attachedToProcess()为false
mStackSupervisor.startSpecificActivityLocked(next, true, true);
}
return true;
}
ActivityStackSuperVisor
1、startSpecificActivityLocked
这里主要会分成两种情况
- 1、进程已存在：调用
realStartActivityLocked- 2、进程不存在：调用
startProcess创建进程
我们先看进程不存在的情况
void startSpecificActivityLocked(ActivityRecord r, boolean andResume, boolean checkConfig) {
final WindowProcessController wpc =
mService.getProcessController(r.processName, r.info.applicationInfo.uid);
//如果已有进程，会调用realStartActivityLocked
if (wpc != null && wpc.hasThread()) {
try {
realStartActivityLocked(r, wpc, andResume, checkConfig);
return;
} catch (RemoteException e) {
}
}
//...
//这里的mService即ActivityTaskManagerService(ATMS)，
//mService.mH是ATMS的内部类 自定义的Handler。
//关于这个Handler：它是ATMS initialize()时创建的，它的
//Looper是AMS中mActivityTaskManager.initialize创建的
try {
final Message msg = PooledLambda.obtainMessage(
//调用静态方法startProcess
//ActivityManagerInternal是抽象类，实现
//类是AMS中的LocalService，注意这里是AMS
ActivityManagerInternal::startProcess, mService.mAmInternal, r.processName,
r.info.applicationInfo, knownToBeDead, "activity", r.intent.getComponent());
mService.mH.sendMessage(msg);
} finally {
Trace.traceEnd(TRACE_TAG_ACTIVITY_MANAGER);
}
}
AMS（ActivityManagerService）# LocalService
1、startProcess
LocalService是AMS的一个内部类
public final class LocalService extends ActivityManagerInternal {
@Override
public void startProcess(...) {
try {
synchronized (ActivityManagerService.this) {
...
startProcessLocked(processName, info, knownToBeDead, 0 ,
new HostingRecord(hostingType, hostingName),
false, false,true);
}
} finally {
}
}
}
2、startProcessLocked
进入
ProcessList
final ProcessRecord startProcessLocked(String processName,
ApplicationInfo info, boolean knownToBeDead, int intentFlags,
HostingRecord hostingRecord, boolean allowWhileBooting,
boolean isolated, boolean keepIfLarge) {
return mProcessList.startProcessLocked(processName, info, knownToBeDead, intentFlags,
hostingRecord, allowWhileBooting, isolated, 0, keepIfLarge,null, null, null,null);
}
ProcessList
1、startProcessLocked
在这里会调用多个同名方法，主要是创建
ProcessRecord
/**
在调用过程创建了ProcessRecord对象并处理保存了进程所需的各种信息。
**/
//--------------第一次startProcessLocked--------------//
final ProcessRecord startProcessLocked(...) {
long startTime = SystemClock.elapsedRealtime();
ProcessRecord app;
if (!isolated) {
app = getProcessRecordLocked(processName, info.uid, keepIfLarge);
} else {
app = null;
}
//...
//第一次调用startProcessLocked
final boolean success = startProcessLocked(app, hostingRecord, abiOverride);
return success ? app : null;
}
//--------------第二次startProcessLocked--------------//
final boolean startProcessLocked(ProcessRecord app,
HostingRecord hostingRecord,String abiOverride) {
//第二次调用startProcessLocked
return startProcessLocked(app, hostingRecord,
false /* disableHiddenApiChecks */, false /* mountExtStorageFull */, abiOverride);
}
//--------------第三次startProcessLocked--------------//
boolean startProcessLocked(ProcessRecord app, HostingRecord hostingRecord,
boolean disableHiddenApiChecks, boolean mountExtStorageFull,
String abiOverride) {
......
try {
......
if ("1".equals(SystemProperties.get("debug.checkjni"))) {
runtimeFlags |= Zygote.DEBUG_ENABLE_CHECKJNI;
}
......
final String seInfo = app.info.seInfo
+ (TextUtils.isEmpty(app.info.seInfoUser) ? "" : app.info.seInfoUser);
final String entryPoint = "android.app.ActivityThread";
//第三次调用startProcessLocked
return startProcessLocked(hostingRecord, entryPoint, app, uid, gids,
runtimeFlags, mountExternal, seInfo, requiredAbi, instructionSet, invokeWith,
startTime);
} catch (RuntimeException e) {
......
}
}
//--------------第四次startProcessLocked--------------//
boolean startProcessLocked(...) {
app.pendingStart = true;
app.killedByAm = false;
app.removed = false;
app.killed = false;
......
if (mService.mConstants.FLAG_PROCESS_START_ASYNC) {
mService.mProcStartHandler.post(() -> {
try {
final Process.ProcessStartResult startResult = startProcess(app.hostingRecord,
entryPoint, app, app.startUid, gids, runtimeFlags, mountExternal,
app.seInfo, requiredAbi, instructionSet, invokeWith, app.startTime);
synchronized (mService) {
handleProcessStartedLocked(app, startResult, startSeq);
}
} catch (RuntimeException e) {
......
}
});
return true;
} else {
try {
//调用startProcess
final Process.ProcessStartResult startResult = startProcess(hostingRecord,
entryPoint, app,
uid, gids, runtimeFlags, mountExternal, seInfo, requiredAbi, instructionSet,
invokeWith, startTime);
handleProcessStartedLocked(app, startResult.pid, startResult.usingWrapper,
startSeq, false);
} catch (RuntimeException e) {
......
}
return app.pid > 0;
}
}
2、startProcess
这里调用了
Process.start，最终调用ZYGOTE_PROCESS.start，通过Zygote去fork出一个进程，并调用这个进程的入口函数，也就是ActivityThread的main方法
private Process.ProcessStartResult startProcess(...) {
try {
final Process.ProcessStartResult startResult;
if (hostingRecord.usesWebviewZygote()) {
} else if (hostingRecord.usesAppZygote()) {
} else {
//进入这里，最终fork出一个应用程序的进程
startResult = Process.start(...);
}
return startResult;
} finally {
......
}
}
ActivityThread
1、main
当应用进程
fork出来后，最终会执行到ActivityThread的main方法
在这里主要做了几件事：
- 1、创建
Looper- 2、创建
ActivityThread对象- 3、调用
attach，在这个方法里面创建Application- 4、启动
Looper
public static void main(String[] args) {
//...
Looper.prepareMainLooper();
//...
ActivityThread thread = new ActivityThread();
//systemMain调用的时候第一个为true
thread.attach(false, startSeq);
if (sMainThreadHandler == null) {
sMainThreadHandler = thread.getHandler();
}
......
Looper.loop();
}
2、attach
创建完进程后，该要创建
Application了
因此这里就是通过AMS创建Application
private void attach(boolean system, long startSeq) {
sCurrentActivityThread = this;
mSystemThread = system;
if (!system) {
//...
final IActivityManager mgr = ActivityManager.getService();
try {
//很明显这个也是binder机制进行跨进程的，调用的是
//AMS的attachApplication
mgr.attachApplication(mAppThread, startSeq);
} catch (RemoteException ex) {
throw ex.rethrowFromSystemServer();
});
} else {
//...
}
}
AMS
1、attachApplication
调用
attachApplicationLocked
@Override
public final void attachApplication(IApplicationThread thread, long startSeq) {
synchronized (this) {
//调用attachApplicationLocked
attachApplicationLocked(thread, callingPid, callingUid, startSeq);
Binder.restoreCallingIdentity(origId);
}
}
2、attachApplicationLocked
因为
Instrumentation在ActivityThread的attach里面已经创建了，所以调用了thread.bindApplication，thread是一个IApplicationThread，所以调用的是ApplicationThread.bindApplication
注：这里要留意调用完bindApplication之后会调用下面的mAtmInternal.attachApplication，我们将其分为分支1和分支2，分支1主要做创建Application的事情，而分支2是在创建完Application之后继续去调用我们在ActivityStackSuperVisor.startSpecificActivityLocked时候没有调用的realStartActivityLocked
@GuardedBy("this")
private boolean attachApplicationLocked(...) {
ProcessRecord app;
long startTime = SystemClock.uptimeMillis();
long bindApplicationTimeMillis;
if (pid != MY_PID && pid >= 0) {
synchronized (mPidsSelfLocked) {
app = mPidsSelfLocked.get(pid);
}
...
final String processName = app.processName;
...
final BackupRecord backupTarget = mBackupTargets.get(app.userId);
try {
final ActiveInstrumentation instr2 = app.getActiveInstrumentation();
if (app.isolatedEntryPoint != null) {
} else if (instr2 != null) {
//走这里
//这里的thread是一个IApplicationThread
//所以调用的是ApplicationThread.bindApplication
thread.bindApplication(...);
} else {
thread.bindApplication(/*instr2为null则传null*/);
}
//....
} catch (Exception e) {
//...
if (normalMode) {
try {
//走这里
//这里调用的是ATMS的attachApplication
didSomething = mAtmInternal.attachApplication(app.getWindowProcessController());
} catch (Exception e) {
badApp = true;
}
}
......
return true;
}
分支1
ActivityThread # ApplicationThread
1、bindApplication
因为我们知道
ApplicationThread是一个用于通信的类，具体逻辑都是通过Handler转交给ActivityThread处理的（不止Activity，其他组件也都是这个规律）
这里做了一件很重要：通过LoadedApk调用makeApplication去创建Application，其实内部是调用Instrumentation去创建，LoadedApk只是负责创建ContextImpl
//---------ApplicationThread.bindApplication-----------//
public final void bindApplication(...) {
......
data.contentCaptureOptions = contentCaptureOptions;
//通过handler发送消息
sendMessage(H.BIND_APPLICATION, data);
}
//-----------ActivityThread.Handler------------------//
class H extends Handler {
public static final int BIND_APPLICATION = 110;
public void handleMessage(Message msg) {
switch (msg.what) {
case BIND_APPLICATION:
AppBindData data = (AppBindData)msg.obj;
//调用这个方法
handleBindApplication(data);
break;
}
}
}
//---------------------分割线------------------------//
private void handleBindApplication(AppBindData data) {
//...
//创建LoadedApk对象并保存在data.info
data.info = getPackageInfoNoCheck(data.appInfo, data.compatInfo);
//...
if (ii != null) {
//...
try {
final ClassLoader cl = instrContext.getClassLoader();
//通过反射获取Instrumentation
mInstrumentation = (Instrumentation)
cl.loadClass(data.instrumentationName.getClassName()).newInstance();
//...
}
//...
Application app;
try {
//重要！
//在这里创建Application
app = data.info.makeApplication(data.restrictedBackupMode, null);
......
try {
//这里调用了Application的onCreate
mInstrumentation.callApplicationOnCreate(app);
} catch (Exception e) {
......
}
}
......
}
LoadedApk
1、makeApplication
创建
ContextImpl，然后通过Instrumentation去调用newApplication创建Application
public Application makeApplication(boolean forceDefaultAppClass,
Instrumentation instrumentation) {
Application app = null;
String appClass = mApplicationInfo.className;
try {
java.lang.ClassLoader cl = getClassLoader();
//...
ContextImpl appContext = ContextImpl.createAppContext(mActivityThread, this);
app = mActivityThread.mInstrumentation.newApplication(
cl, appClass, appContext);
appContext.setOuterContext(app);
} catch (Exception e) {
}
mActivityThread.mAllApplications.add(app);
mApplication = app;
return app;
}
Instrumetaion
1、newApplication
通过反射创建
Application，然后调用Application的attach，并在里面处理Context，我另外一篇文章有专门讲Context的，这里不再赘述。然后在handleBindApplication通过Instrumentation回调了Application的onCreate。但其实在回调Application的onCreate之前会先回调ContentProvider的onCreate，同样在我Context那篇文章里面讲到。
public Application newApplication(ClassLoader cl, String className, Context context)
throws InstantiationException, IllegalAccessException,
ClassNotFoundException {
Application app = getFactory(context.getPackageName())
.instantiateApplication(cl, className);
//调用Application的attach
//makeApplication()方法创建Application的过程。注意
//makeApplication()传入的instrumentation为null，
//Application的实例化也是通过反射。
//attach里面调用了attachBaseContext(context);
app.attach(context);
return app;
}
分支2
ActivityTaskManagerService
1、attachApplication
public boolean attachApplication(WindowProcessController wpc) throws RemoteException {
synchronized (mGlobalLockWithoutBoost) {
return mRootActivityContainer.attachApplication(wpc);
}
}
RootActivityContainer
1、attachApplication
调用我们刚刚因为进程不存在而不调用的方法
realStartActivityLocked
boolean attachApplication(WindowProcessController app) throws RemoteException {
try {
//调用mStackSupervisor.realStartActivityLocked
if (mStackSupervisor.realStartActivityLocked(activity, app,top == activity, true)) {
didSomething = true;
}
} catch (RemoteException e) {
//...
}
......
return didSomething;
}
ActivityStackSupervisor
1、realStartActivityLocked（重要）
从这里开始做真正启动
Activity的事情，主要是处理绑定生命周期的事情，这里做了两件重要的事
- 1、添加
LaunchActivityItem事务- 2、添加
ResumeActivityItem事务
每一个生命周期都被封装成了一个
ClientTransactionItem，例如
onCreate对应LaunchActivityItemonStart ：无onResume对应ResumeActivityItemonPause对应PauseActivityItemonStop对应StopActivityItemonDestroy对应DestroyActivityItemonRestart：无
ActivityLifecycleItem定义了生命周期对应的状态常量。
注：要留意添加这两种事务的方式：addCallback、scheduleTransaction
boolean realStartActivityLocked(...) throws RemoteException {
//...
try {
try {
//系统将生命周期都当作事务处理
final ClientTransaction clientTransaction = ClientTransaction.obtain(
proc.getThread(), r.appToken);
//这是第一个重点，添加了LaunchActivityItem事务，也就是启动Activity的事务
clientTransaction.addCallback(LaunchActivityItem.obtain(new Intent(r.intent),
//第二个重点，这里还添加了resume事务
final ActivityLifecycleItem lifecycleItem;
if (andResume) {
lifecycleItem = ResumeActivityItem.obtain(dc.isNextTransitionForward());
} else {
lifecycleItem = PauseActivityItem.obtain();
}
//这一行影响到后续的start逻辑
clientTransaction.setLifecycleStateRequest(lifecycleItem);
mService.getLifecycleManager().scheduleTransaction(clientTransaction);
} catch (RemoteException e) {
}
} finally {
}
......
return true;
}
ClientLifecycleManager
1、scheduleTransaction
void scheduleTransaction(ClientTransaction transaction) throws RemoteException {
final IApplicationThread client = transaction.getClient();
transaction.schedule();
if (!(client instanceof Binder)) {
transaction.recycle();
}
}
ClientTransaction
1、schedule
看这个
RemoteException就可以知道接下来又是一次IPC过程了，从系统服务进程转回应用进程
public void schedule() throws RemoteException {
//从这里开始从系统进程回到了应用进程
mClient.scheduleTransaction(this);
}
ActivityThread # ApplicationThread
1、scheduleTransaction
因为
ActivityThread是继承自ClientTransactionHandler，所以这里是调用ClientTransactionHandler的方法
public void scheduleTransaction(ClientTransaction transaction) throws RemoteException {
ActivityThread.this.scheduleTransaction(transaction);
}
ClientTransactionHandler
1、scheduleTransaction
通过
ActivityThread的Handler发送EXECUTE_TRANSACTION消息
void scheduleTransaction(ClientTransaction transaction) {
transaction.preExecute(this);
//发送消息
sendMessage(ActivityThread.H.EXECUTE_TRANSACTION, transaction);
}
ActivityThread # H
1、handleMessage
class H extends Handler {
public void handleMessage(Message msg) {
switch (msg.what) {
case EXECUTE_TRANSACTION:
final ClientTransaction transaction = (ClientTransaction) msg.obj;
mTransactionExecutor.execute(transaction);
break;
}
}
}
TransactionExecutor
1、execute
还记得上面添加的两个事务吗，这里分成了两条分支，一个是处理
onCreate，另一个是处理onStart和onResume，我们先看分支1
public void execute(ClientTransaction transaction) {
......
//1、处理LaunchActivityItem
executeCallbacks(transaction);
//2、处理ResumeActivityItem
executeLifecycleState(transaction);
mPendingActions.clear();
}
分支1 —— onCreate
1、executeCallbacks
这里调用
LaunchActivityItem.execute
public void executeCallbacks(ClientTransaction transaction) {
final List<ClientTransactionItem> callbacks = transaction.getCallbacks();
......
final int size = callbacks.size();
for (int i = 0; i < size; ++i) {
final ClientTransactionItem item = callbacks.get(i);
......
//LaunchActivityItem.execute
item.execute(mTransactionHandler, token, mPendingActions);
item.postExecute(mTransactionHandler, token, mPendingActions);
......
}
}
LaunchActivityItem
1、execute
终于调用了
handleLaunchActivity，这就是我们平时经常看到的方法
public void execute(ClientTransactionHandler client, IBinder token,
PendingTransactionActions pendingActions) {
Trace.traceBegin(TRACE_TAG_ACTIVITY_MANAGER, "activityStart");
ActivityClientRecord r = new ActivityClientRecord(token, mIntent, mIdent, mInfo,
mOverrideConfig, mCompatInfo, mReferrer, mVoiceInteractor, mState, mPersistentState,
mPendingResults, mPendingNewIntents, mIsForward,
mProfilerInfo, client, mAssistToken);
//这里的client就是ActivityThread。所以走到了ActivityThread的handleLaunchActivity()。
client.handleLaunchActivity(r, pendingActions, null);
Trace.traceEnd(TRACE_TAG_ACTIVITY_MANAGER);
}
ActivityThread
1、handleLaunchActivity
这里的主要方法还是调用
performLaunchActivity
public Activity handleLaunchActivity(...) {
//重点1
handleConfigurationChanged(null, null);
//重点2，初始化WindowManagerGlobal
WindowManagerGlobal.initialize();
//重点3
final Activity a = performLaunchActivity(r, customIntent);
return a;
}
2、performLaunchActivity
在这里主要做了几件事情：
- 1、为
Activity创建ContextImpl- 2、通过
Instrumentation创建Activity- 3、调用
Activity的attach- 4、调用
Activity的onCreate，到这里整个onCreate流程就结束了，接着我们再回去看onStart和onResume的逻辑
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
//存储Activity所有信息
ActivityInfo aInfo = r.activityInfo;
//组件名
ComponentName component = r.intent.getComponent();
//创建属于Activity的ContextImpl
ContextImpl appContext = createBaseContextForActivity(r);
Activity activity = null;
try {
//类加载器
java.lang.ClassLoader cl = appContext.getClassLoader();
//从Instrumentation生成
activity = mInstrumentation.newActivity(
cl, component.getClassName(), r.intent);
} catch (Exception e) {
//...
}
try {
//这个方法里面有判空，所以并不是创建，只是获取而已
Application app = r.packageInfo.makeApplication(false, mInstrumentation);
if (activity != null) {
//...
appContext.setOuterContext(activity);
//调用了attach，并将ContextImpl保存在ContextWrapper的mBase里面
activity.attach(...);
//...
//重要！！！！
//分发Activity的onCreate生命周期
if (r.isPersistable()) {
mInstrumentation.callActivityOnCreate(activity, r.state,
r.persistentState);
} else {
mInstrumentation.callActivityOnCreate(activity,
r.state);
}
r.activity = activity;
}
//状态已经是onCreate了
r.setState(ON_CREATE);
}catch (Exception e) {
}
return activity;
}
分支2 —— onStart和onResume
3、executeLifecycleState
这里做了两件事：
- 1、调用
cycleToPath处理onStart的逻辑- 2、调用
ResumeActivityItem.execute回调onResume
我们先看
cycleToPath：
- 首先根据
ActivityStackSuperVisor的clientTransaction.setLifecycleStateRequest(lifecycleItem)可以知道lifecycleItem是一个ResumeActivityItem，而mTransactionHandler是在构造函数里面被初始化的，它的构造函数在ActivityThread被调用，接着进入cycleToPath
private void executeLifecycleState(ClientTransaction transaction) {
//这个lifecycItem其实就是ResumeActivityItem
final ActivityLifecycleItem lifecycleItem = transaction.getLifecycleStateRequest();
final ActivityClientRecord r = mTransactionHandler.getActivityClient(token);
//处理Start
cycleToPath(r, lifecycleItem.getTargetState(), true /* excludeLastState */, transaction);
//ResumeActivityItem.execute
lifecycleItem.execute(mTransactionHandler, token, mPendingActions);
lifecycleItem.postExecute(mTransactionHandler, token, mPendingActions);
}
分支2 —— onStart
1、cycleToPath
由于上面已经结束了
onCreate逻辑，在performLaunchActivity的最后调用了r.setState(ON_CREATE)，所以这里是start是ON_CREATE，finish是ON_RESUME，通过ActivityLifecycleItem类可以直到这两个值分别对应1和3，接着进入mHelper.getLifecyclePath
private void cycleToPath(ActivityClientRecord r, int finish, boolean excludeLastState,
ClientTransaction transaction) {
final int start = r.getLifecycleState();
final IntArray path = mHelper.getLifecyclePath(start, finish, excludeLastState);
performLifecycleSequence(r, path, transaction);
}
2、getLifecyclePath
进入这个方法后，由上面的分析可以得知
finish >= start成立，所以进入for循环（要注意这里的i = start + 1，也就是从2开始），最终for循环执行了2次add，然后进入performLifecycleSequence
@VisibleForTesting
public IntArray getLifecyclePath(int start, int finish, boolean excludeLastState) {
mLifecycleSequence.clear();
if (finish >= start) {
// just go there
for (int i = start + 1; i <= finish; i++) {
mLifecycleSequence.add(i);
}
} else {
...
}
return mLifecycleSequence;
}
3、performLifecycleSequence
由上一个方法我们可以知道
size长度为2，根据ActivityLifecycleItem类可以得到2对应着ON_START，也就是这个方法会执行handleStartActivity
private void performLifecycleSequence(ActivityClientRecord r, IntArray path,
ClientTransaction transaction) {
final int size = path.size();
for (int i = 0, state; i < size; i++) {
state = path.get(i);
switch (state) {
...
case ON_START:
mTransactionHandler.handleStartActivity(r, mPendingActions);
break;
...
}
}
}
ActivityThread
1、handleStartActivity
进入
handleStartActivity，可以看到通过调用activity.performStart去触发onStart，到这里我们的onStart流程就走完了，接着我们再回去看onResume
public void handleStartActivity(ActivityClientRecord r,
PendingTransactionActions pendingActions) {
final Activity activity = r.activity;
// Start
activity.performStart("handleStartActivity");
r.setState(ON_START);
...
}
分支2 —— onResume
1、handleResumeActivity
通过我们的分支起点可以得知调用了
ResumeActivityItem.execute，而ResumeActivityItem.execute调用了handleResumeActivity，因此我们直接进入ActivityThread.handleResumeActivity，这里做了几件重要的事：
- 1、调用
performResumeActivity，这个方法逻辑并不多，主要在里面触发performResume，因此这里不再赘述- 2、调用
wm.addView添加布局，具体可看addWindow过程- 3、设置
activity可见
public void handleResumeActivity(IBinder token, boolean finalStateRequest, boolean isForward,
String reason) {
final ActivityClientRecord r = performResumeActivity(token, finalStateRequest, reason);
final Activity a = r.activity;
if (r.window == null && !a.mFinished && willBeVisible) {
...
if (a.mVisibleFromClient) {
if (!a.mWindowAdded) {
wm.addView(decor, l);
}
}
}
if (...) {
if (r.activity.mVisibleFromClient) {
r.activity.makeVisible();
}
}
}
总结
总体流程：
- 1、通过
Instrumentation调用到ATMS服务的启动方法- 2、通过
ActivityStarter创建ActivityRecord- 3、通过
ActivityStack将Activity放到对应的栈中，并调用上一个resume组件的onPause- 4、在
ActivitySuperVisor里面调用创建进程的方法- 5、通过
Zygotefork出一个进程后，进入程序的入口函数ActivityThread.main- 6、创建
Application并回调attach和onCreate生命周期- 7、创建完进程和
Application后，进入ATMS调用realStartActivity继续启动组件- 8、绑定
Activity生命周期后，调用ActivityThread.performLaunchActivity- 9、创建
Activity并回调onCreate生命周期- 10、调用
ActivityThread.performStartActivity和ActivityThread.performResumeActivity回调onStart和onResume
时序图
欠着先，没时间做…
流程图
扫一扫
984
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
