「这是我参与2022首次更文挑战的第28天，活动详情查看：2022首次更文挑战」。
Launcher应用Activity启动流程（启动篇）
在 Launcher应用Activity启动流程（初始篇）中分析过，ActivityThread的main函数启动后，会初始化一个ActivityThread对象并调用其attach函数，并最终调用的AMS的attachApplicationLocked函数 在这个函数中，主要做了：
- 启动Application对象
- 启动Activity对象 如下，我们接着上篇分析
Application启动流程分析
在初始篇中，我们分析过，在AMS的attachApplicationLocked函数中，会调用ApplicationThread对象的bindApplication函数
ApplicationThread.java
public final void bindApplication(String processName, ApplicationInfo appInfo,
ProviderInfoList providerList, ComponentName instrumentationName,
ProfilerInfo profilerInfo, Bundle instrumentationArgs,
IInstrumentationWatcher instrumentationWatcher,
IUiAutomationConnection instrumentationUiConnection, int debugMode,
boolean enableBinderTracking, boolean trackAllocation,
boolean isRestrictedBackupMode, boolean persistent, Configuration config,
CompatibilityInfo compatInfo, Map services, Bundle coreSettings,
String buildSerial, AutofillOptions autofillOptions,
ContentCaptureOptions contentCaptureOptions, long[] disabledCompatChanges) {
if (services != null) {
// ......
// Setup the service cache in the ServiceManager
// 将AMS需要的对应服务添加到ServiceManager缓存中，这样在后续的工作中，
// 就可以直接从ServiceManager中获取到对应的服务
ServiceManager.initServiceCache(services);
}
setCoreSettings(coreSettings);
// 初始化AppBindData对象，并设置其对应的参数
// 这个对象保存有启动应用的应用信息
AppBindData data = new AppBindData();
data.processName = processName;
data.appInfo = appInfo;
data.providers = providerList.getList();
data.instrumentationName = instrumentationName;
data.instrumentationArgs = instrumentationArgs;
data.instrumentationWatcher = instrumentationWatcher;
data.instrumentationUiAutomationConnection = instrumentationUiConnection;
data.debugMode = debugMode;
data.enableBinderTracking = enableBinderTracking;
data.trackAllocation = trackAllocation;
data.restrictedBackupMode = isRestrictedBackupMode;
data.persistent = persistent;
data.config = config;
data.compatInfo = compatInfo;
data.initProfilerInfo = profilerInfo;
data.buildSerial = buildSerial;
data.autofillOptions = autofillOptions;
data.contentCaptureOptions = contentCaptureOptions;
data.disabledCompatChanges = disabledCompatChanges;
// 发送消息，最终会在ActivityThread.H类对象中进行处理
sendMessage(H.BIND_APPLICATION, data);
}
可以看到，此处主要初始化一个AppBindData对象，然后通过发送消息给到ActivityThread.H对象，并处理
ActivityThread.H类
public void handleMessage(Message msg) {
switch (msg.what) {
case BIND_APPLICATION:
AppBindData data = (AppBindData)msg.obj;
// 调用handleBindApplication函数
handleBindApplication(data);
break;
// ......
}
}
private void handleBindApplication(AppBindData data) {
// ......
// 初始化一个Instrumentation对象
mInstrumentation = new Instrumentation();
mInstrumentation.basicInit(this);
// ......
try {
// If the app is being launched for full backup or restore, bring it up in
// a restricted environment with the base application class.
// 初始化Application对象
// 如果应用的AndroidManifest.xml文件中定义有对应的继承Application类的应用类，此处就会初始化该类对象
// 反之，则初始化一个Application基类对象
// 此处以AOSP的Launcher3应用为例，此处初始化Application对象
// 值得提一句，这个函数同时会将当前的Application对象添加到ActivityThread的mAllApplications参数中
app = data.info.makeApplication(data.restrictedBackupMode, null);
// ......
mInitialApplication = app;
// 运行对应的应用的所有ContentProvider
if (!data.restrictedBackupMode) {
if (!ArrayUtils.isEmpty(data.providers)) {
installContentProviders(app, data.providers);
}
}
// ......
try {
// 这边会调用对应的ApplicationInfo应用信息的Application对象的onCreate函数
// 当然在我们的Launcher应用中，此处调用Application的默认onCreate，不做任何操作
mInstrumentation.callApplicationOnCreate(app);
}
// ......
}
// ......
}
如上代码和备注，针对于Launcher应用来说，此处的Application的onCreate函数并未做任何操作，但是如果有其他应用在AndroidManifest.xml中定义了Application子类对象，此处会调用其onCreate函数做一些应用级的初始化操作，启动一些关键性的服务等，例如AOSP Dialer应用。
如此，Application应用的启动流程，我们就分析完毕了。
注：在Application应用启动流程分析完毕后，会调用ProcessRecord的makeActive函数，此函数会设置对应的ProcessRecord的thread参数为当前的ApplicationThread对象，且设置其mWindowProcessController参数的mThread参数值为该对象，由于代码相对简单，此处不做分析
Activity启动流程分析
此后，从代码分析可知，会通过ATMS.LocalService对象的attachApplication函数来启动Activity的声明周期
ActivityManagerService.java
if (normalMode) {
try {
// mAtmInternal是一个ATMS.LocalService对象，该类继承自ActivityTaskManagerInternal类
didSomething = mAtmInternal.attachApplication(app.getWindowProcessController());
} catch (Exception e) {
Slog.wtf(TAG, "Exception thrown launching activities in " + app, e);
badApp = true;
}
}
public boolean attachApplication(WindowProcessController wpc) throws RemoteException {
// ......
return mRootWindowContainer.attachApplication(wpc);
// ......
}
boolean attachApplication(WindowProcessController app) throws RemoteException {
boolean didSomething = false;
for (int displayNdx = getChildCount() - 1; displayNdx >= 0; --displayNdx) {
// ......
final DisplayContent display = getChildAt(displayNdx);
for (int areaNdx = display.getTaskDisplayAreaCount() - 1; areaNdx >= 0; --areaNdx) {
final TaskDisplayArea taskDisplayArea = display.getTaskDisplayAreaAt(areaNdx);
for (int taskNdx = taskDisplayArea.getStackCount() - 1; taskNdx >= 0; --taskNdx) {
// 获取此前创建的ActivityStack对象，这里面保存有此前添加到顶层的ActivityRecord对象
final ActivityStack rootTask = taskDisplayArea.getStackAt(taskNdx);
// ......
// PooledLambda此前我们有接触过，此处最终会调用第一个参数应用所对应的函数
final PooledFunction c = PooledLambda.obtainFunction(
RootWindowContainer::startActivityForAttachedApplicationIfNeeded, this,
PooledLambda.__(ActivityRecord.class), app,
rootTask.topRunningActivity());
rootTask.forAllActivities(c);
// ......
}
}
didSomething |= mTmpBoolean;
}
// ......
return didSomething;
}
由于PooledLambda类对象的obtainFunction函数最终会初始化PooledFunction对象，并最终会运行该对象的对应函数引用，因此
rivate boolean startActivityForAttachedApplicationIfNeeded(ActivityRecord r, WindowProcessController app, ActivityRecord top) {
// ......
// ActivityStackSupervisor对象的realStartActivityLocked函数
if (mStackSupervisor.realStartActivityLocked(r, app,
top == r && r.isFocusable() /*andResume*/, true /*checkConfig*/)) {
mTmpBoolean = true;
}
// ......
return false;
}
boolean realStartActivityLocked(ActivityRecord r, WindowProcessController proc,
boolean andResume, boolean checkConfig) throws RemoteException {
// ......
// Create activity launch transaction.
// 此处会初始化一个ClientTransaction对象
final ClientTransaction clientTransaction = ClientTransaction.obtain(
proc.getThread(), r.appToken);
final DisplayContent dc = r.getDisplay().mDisplayContent;
// 添加当前ClientTransaction对象的回调callback，
// 事实上是将此处的LaunchActivityItem添加到ClientTransaction对象的mActivityCallbacks参数中
clientTransaction.addCallback(/* ...... 此处参数暂时不看，需要的时候再行分析 */);
// ......
final ActivityLifecycleItem lifecycleItem;
if (andResume) {
// 此处会初始化一个ResumeActivityItem对象
lifecycleItem = ResumeActivityItem.obtain(dc.isNextTransitionForward());
} else {
lifecycleItem = PauseActivityItem.obtain();
}
// 设置ClientTransaction对象的lifecycle request
clientTransaction.setLifecycleStateRequest(lifecycleItem);
// Schedule transaction.
// 最后通过获取的ClientLifecycleManager对象的scheduleTransaction函数
mService.getLifecycleManager().scheduleTransaction(clientTransaction);
// ......
}
如上代码和注释，可以看到，此处初始化一个ClientTransaction对象，然后设置其Callback和Lifecycle state request后，调用ClientListcycleManager的scheduleTransaction函数计划业务流程
在继续分析代码流程之前，我们有必要先对ClientTransaction类和ClientTransactionItem类的结构进行梳理一下，如下
classDiagram
Parcelable <|-- ClientTransactionItem
ClientTransactionItem <|-- LaunchActivityItem
ClientTransactionItem <|-- ActivityLifecycleItem
BaseClientRequest <|-- ClientTransactionItem
ObjectPoolItem <|-- BaseClientRequest
ActivityLifecycleItem <|-- ResumeActivityItem
ActivityLifecycleItem <|-- PauseActivityItem
ActivityLifecycleItem <|-- StopActivityItem
ActivityLifecycleItem <|-- DestroyActivityItem
ActivityLifecycleItem <|-- StartActivityItem
ClientTransaction <-- ClientTransactionItem
Parcelable <|-- ClientTransaction
ObjectPoolItem <|-- ClientTransaction
ClientTransaction <-- ActivityLifecycleItem
class BaseClientRequest {
+preExecute(ClientTransactionHandler, IBinder) void default
+execute(ClientTransactionHandler, IBinder, PendingTransactionActions) void
+postExecute(ClientTransactionHandler, IBinder, PendingTransactionActions) void default
}
class ClientTransaction {
+schedule() void
}
class ObjectPoolItem {
#recycle() void
}
class ClientTransactionItem {
+getPostExecutionState() int
+describeContents() int
}
class LaunchActivityItem {
+preExecute(ClientTransactionHandler, IBinder) void
+execute(ClientTransactionHandler, IBinder, PendingTransactionActions) void
+postExecute(ClientTransactionHandler, IBinder, PendingTransactionActions) void
-LaunchActivityItem()
+recycle()
+obtain(......) LaunchActivityItem
-LaunchActivityItem(Parcel in)
-setValues(......) void
}
<<interface>> ObjectPoolItem
<<interface>> BaseClientRequest
<<interface>> Parcelable
<<abstract>> ClientTransactionItem
<<abstract>> ActivityLifecycleItem
从这个结构图上可以看到
- ClientTransaction 和 ClientTransactionItem均实现了Parcelable接口，这至少表明这两个对象均能通过Message消息携带
- ActivityLifecycleItem 和 LaunchActivityItem均是继承自ClientTransactionItem，而同时跟ClientTransaction关联
- ActivityLifecycleItem 类包含有五个子类，从子类名称来看，似乎对应了Activity启动的各个阶段
接下来继续我们的代码流程分析 ClientLifecycleManager对象的scheduleTransaction函数
void scheduleTransaction(ClientTransaction transaction) throws RemoteException {
// ......
transaction.schedule();
// .......
}
public void schedule() throws RemoteException {
// mClient参数是在调用ClientTransaction对象的obtain函数初始化的时候传入的
// 而其通过WindowProcessController的mThread参数传入，其参数是通过ProcessRecord的makeActive函数设置的
// 因此，此处的mClient为ActivityThread类中的内部类ApplicationThread对象
mClient.scheduleTransaction(this);
}
public void scheduleTransaction(ClientTransaction transaction) throws RemoteException {
// 调用ActivityThread的scheduleTransaction函数，而ActivityThread并未有重写该函数
// 因此调用其父类ClientTransactionHandler的scheduleTransaction函数
ActivityThread.this.scheduleTransaction(transaction);
}
void scheduleTransaction(ClientTransaction transaction) {
// 此处会先调用ClientTransaction对象的preExecute函数
transaction.preExecute(this);
// 发送消息后在ActivityThread.H中处理
sendMessage(ActivityThread.H.EXECUTE_TRANSACTION, transaction);
}
上述代码可以看到，此处做了两个操作
- 先调用ClientTransaction对象的preExecute函数,先将此处标注为a标识
- 发送消息后在ActivityThread.H中处理 上述第一个操作，暂时我们先不看，先看第二个操作
public void handleMessage(Message msg) {
switch (msg.what) {
case EXECUTE_TRANSACTION:
// -_-
final ClientTransaction transaction = (ClientTransaction) msg.obj;
// 调用TransactionExecutor对象的execute函数
mTransactionExecutor.execute(transaction);
// ......
}
}
public void execute(ClientTransaction transaction) {
// ......
// 1. 先调用executeCallbacks函数
executeCallbacks(transaction);
// 2. 再调用executeLifecycleState函数
executeLifecycleState(transaction);
// ......
}
调用executeCallbacks函数
依照上述代码，我们先看下备注中的第一点
public void executeCallbacks(ClientTransaction transaction) {
// 获取ClientTransaction对象中的Callbacks，
// 还记得在上面的代码中，我们通过addCallback函数将对应的一个LaunchActivityItem对象
// 添加到ClientTransaction对象mActivityCallbacks参数中的么？
final List<ClientTransactionItem> callbacks = transaction.getCallbacks();
// 不为空
if (callbacks == null || callbacks.isEmpty()) {
// No callbacks to execute, return early.
return;
}
// ......
final IBinder token = transaction.getActivityToken();
ActivityClientRecord r = mTransactionHandler.getActivityClient(token);
// ......
final int size = callbacks.size();
for (int i = 0; i < size; ++i) {
// 从ClientTransaction中获取对应的LaunchActivityItem对象
final ClientTransactionItem item = callbacks.get(i);
// ......
// 调用LaunchActivityItem对象的execute函数，此处我们暂时标注为b
item.execute(mTransactionHandler, token, mPendingActions);
// 调用LaunchActivityItem对象的postExecute函数，此处我们暂时标注为c
item.postExecute(mTransactionHandler, token, mPendingActions);
// ......
}
}
如上代码和注释，我们继续标注 b 和 c 标识
调用executeLifecycleState函数
我们继续来分析上述的第二点，executeLifecycleState函数
private void executeLifecycleState(ClientTransaction transaction) {
// 获取ClientTransaction对象的 Lifecycle request
// 在此前分析的代码中，设置了一个ResumeActivityItem对象
final ActivityLifecycleItem lifecycleItem = transaction.getLifecycleStateRequest();
// ......
// Cycle to the state right before the final requested state.
// 调用cycleToPath函数
// 这个函数的最主要的作用是，获取当前Activity的运行状态标识，和Lifecycle Request对象的状态标识比较
// 确认其间是否还有其他的状态，若有则进行对应的状态函数运行
// 此处我们暂时将其标识为d
cycleToPath(r, lifecycleItem.getTargetState(), true /* excludeLastState */, transaction);
// Execute the final transition with proper parameters.
// 运行上述的ResumeActivityItem对象的execute函数，此处我们暂时将其标识为e
lifecycleItem.execute(mTransactionHandler, token, mPendingActions);
// 运行上述的ResumeActivityItem对象的postExecute函数，此处我们暂时将其标识为f
lifecycleItem.postExecute(mTransactionHandler, token, mPendingActions);
}
如上代码和注释，我们继续标注 e 和 f
汇总
如上整体代码分析，我们的标识有：
- a 调用ClientTransaction对象的preExecute函数
- b 调用LaunchActivityItem对象的execute函数
- c 调用LaunchActivityItem对象的postExecute函数
- d 调用TransactionExecutor的cycleToPath函数
- e 调用ResumeActivityItem对象的execute函数
- f 调用ResumeActivityItem对象的postExecute函数 上述的这几个标识代表的代码，也组成了Activity运行的生命周期，这个我们将在下一篇中进行展开分析
