基于Android Q，之前的版本思路也是一样只是又部分不同。
- Activity.startActivity
- Activity.startActivityForResult
- Instrumentation.execStartActivity
- IActivityTaskManager.startActivity (aidl实现binder跨进程通讯，通讯的客户端，以上部分在应用进程）
- ActivityTaskManagerService.startActivity (实现IActivityTaskManager.Stub，跨进程通讯的服务端，这部分在系统进程)
- ActivityTaskManagerService.startActivityAsUser
- ActivityStarter.execute
- ActivityStarter.startActivityMayWait
- ActivityStarter.startActivity(有几个该重载方法)
- ActivityStarter.startActivityUnchecked
- ActivityStack.ensureActivitiesVisibleLocked
- ActivityRecord.makeClientVisible
- ActivityRecord.makeActiveIfNeeded
- ActivityStack.resumeTopActivityUncheckedLocked
- ActivityStack.resumeTopActivityInnerLocked
- ActivityStackSupervisor.startSpecificActivityLocked
- ActivityStackSupervisor.realStartActivityLocked { mService.getLifecycleManager().scheduleTransaction(clientTransaction); }
- ClientLifecycleManager.scheduleTransaction
- ClientTransaction.schedule(ClientTransaction中的mActivityCallbacks就是LaunchActivityItem)
- IApplicationThread.scheduleTransaction(这里也是使用aidl通过binder通讯，这是通讯的客户端，这部分在系统进程)
- ApplicationThread.scheduleTransaction(实现IApplicationThread.Stub，跨进程通讯的服务端，这部分在应用进程)
- ClientTransactionHandler.scheduleTransaction
- ActivityThread.sendMessage (what = EXECUTE_TRANSACTION)
- ActivityThread$H.handleMessage
- TransactionExecutor.execute
- TransactionExecutor.executeCallbacks
- ClientTransactionItem.execute(ClientTransactionItem就是LaunchActivityItem)
*ClientTransactionHandler.handleLaunchActivity(ClientTransactionHandler的实现其实就是ActivityThread) - ActivityThread.performLaunchActivity {Instrumentation.newActivity创建activity实例 -> activity.attach -> activity.mIntent = customIntent -> activity.setTheme}
- Instrumentation.callActivityOnCreate
- Activity.performCreate
- Activity.onCreate
到这里activity就被启动起来了
总体来说，不管是哪个版本都是：
- 首先startActivity
- 通过Instrumentation调用ActivityManagerService（后文简称AMS）通过跨进程通讯，从应用进程调用到系统进程，并在系统进程中进行一些列操作
- 在系统进程处理完成后，通过IApplicationThread也进行跨进程通讯，从系统进程回到应用进程，通过ActivityThread中的Handler处理消息
- 最后又通过Instrumentation创建要启动的Activity，并调用创建的activity的onCreate方法
也就是说启动Activity其实是经过了两次跨进程通讯才将Activity启动起来的。
其他生命周期的调用
onResume和onPause
如果启动另一个activity，以前就知道会先调用当前activity的onPause方法之后再调用启动的Activity的onResume方法，而这个原因也能在上边分析启动流程中找到，在ActivityStack.resumeTopActivityInnerLocked方法中可以看到会先执行上一个Activity的onPause再去执行当前activity的onResume方法。
//2744行
boolean pausing = getDisplay().pauseBackStacks(userLeaving, next, false);
if (mResumedActivity != null) {
if (DEBUG_STATES) Slog.d(TAG_STATES,
"resumeTopActivityLocked: Pausing " + mResumedActivity);
pausing |= startPausingLocked(userLeaving, false, next, false);
}
//2983行
transaction.setLifecycleStateRequest(
ResumeActivityItem.obtain(next.app.getReportedProcState(),
getDisplay().mDisplayContent.isNextTransitionForward()));
mService.getLifecycleManager().scheduleTransaction(transaction);
final boolean startPausingLocked(boolean userLeaving, boolean uiSleeping,
ActivityRecord resuming, boolean pauseImmediately) {
//其他代码...
mService.getLifecycleManager().scheduleTransaction(prev.app.getThread(),
prev.appToken, PauseActivityItem.obtain(prev.finishing, userLeaving,
prev.configChangeFlags, pauseImmediately));
//其他代码...
}
可以看到onResume和onPause的执行都是和onCreate一样，都通过继承的ClientTransactionItem，最终被TransactionExecutor.executeCallbacks时调用对应item.execute方法，然后调用到ActivityThread里的对应方法，然后通过Instrumentation与Activity交互。
onStart和onStop调用的地方又有点不一样。
onStart是在onResume方法执行TransactionExecutor.execute方法中调用executeLifecycleState方法中调用到的。然后调用cycleToPath -> performLifecycleSequence -> ActivityThread.handleStartActivity，之后也是通过Instrumentation执行Activity.onStart方法
onStop是在调用ActivityThread.handleResumeActivity方法的最后通过闲置Handler调用idler，循环调用AMS的activityIdle方法，然后调用ActivityStackSupervisor的activityIdleInternalLocked方法，再通过processStoppingActivitiesLocked方法得到需要stop的Activity信息，如果这些需要stop的activity中不是被finish的那么就执行ActivityStack的stopActivityLocked方法，然后和其他之前一样也是使用
mService.getLifecycleManager().scheduleTransaction(r.app.getThread(), r.appToken,
StopActivityItem.obtain(r.visible, r.configChangeFlags));
这样的方式在Activity中执行对应的方法，最后再通过Instrumentation执行Activity.onStop方法。