Activity 啟動流程聽起來非常復雜，但實際上很多東西我們沒必要完全掌握，只需要去大概理解原理和流程就行。
名詞解釋
zygote 意思為受精卵 為所有進程的父進程
1. 流程的發起
從startActivity開始看起
@Override
public void startActivity(Intent intent, @Nullable Bundle options) {
if (options != null) {
startActivityForResult(intent, -1, options);
} else {
// Note we want to go through this call for compatibility with
// applications that may have overridden the method.
startActivityForResult(intent, -1);
}
}
最終調用的是 startActivityForResult
public void startActivityForResult(@RequiresPermission Intent intent, int requestCode,
@Nullable Bundle options) {
if (mParent == null) {
options = transferSpringboardActivityOptions(options);
Instrumentation.ActivityResult ar =
mInstrumentation.execStartActivity(
this, mMainThread.getApplicationThread(), mToken, this,
intent, requestCode, options);
if (ar != null) {
mMainThread.sendActivityResult(
mToken, mEmbeddedID, requestCode, ar.getResultCode(),
ar.getResultData());
}
...
}
}
在這個方法里看到了久仰大名的Instrumentation 這個類是Application和Activity生命周期的關鍵，然后去看 execStartActivity
int result = ActivityTaskManager.getService()
.startActivity(whoThread, who.getBasePackageName(), intent,
intent.resolveTypeIfNeeded(who.getContentResolver()),
token, target != null ? target.mEmbeddedID : null,
requestCode, 0, null, options);
只挑了里面的關鍵部分，又看到了不得了的東西 ActivityTaskManager.getService()，看著好像另一個大名鼎鼎的ActivityManagerService 啊，看一下getService方法
public static IActivityTaskManager getService() {
return IActivityTaskManagerSingleton.get();
}
@UnsupportedAppUsage(trackingBug = 129726065)
private static final Singleton<IActivityTaskManager> IActivityTaskManagerSingleton =
new Singleton<IActivityTaskManager>() {
@Override
protected IActivityTaskManager create() {
final IBinder b = ServiceManager.getService(Context.ACTIVITY_TASK_SERVICE);
return IActivityTaskManager.Stub.asInterface(b);
}
};
但是這里拿到的不是ActivityManagerService
而是**ActivityTaskManagerService **，然后再去調用它的 startActivityAsUser
private int startActivityAsUser(IApplicationThread caller, String callingPackage,
@Nullable String callingFeatureId, Intent intent, String resolvedType,
IBinder resultTo, String resultWho, int requestCode, int startFlags,
ProfilerInfo profilerInfo, Bundle bOptions, int userId, boolean validateIncomingUser) {
assertPackageMatchesCallingUid(callingPackage);
enforceNotIsolatedCaller("startActivityAsUser");
userId = getActivityStartController().checkTargetUser(userId, validateIncomingUser,
Binder.getCallingPid(), Binder.getCallingUid(), "startActivityAsUser");
// TODO: Switch to user app stacks here.
return getActivityStartController().obtainStarter(intent, "startActivityAsUser")
.setCaller(caller)
.setCallingPackage(callingPackage)
.setCallingFeatureId(callingFeatureId)
.setResolvedType(resolvedType)
.setResultTo(resultTo)
.setResultWho(resultWho)
.setRequestCode(requestCode)
.setStartFlags(startFlags)
.setProfilerInfo(profilerInfo)
.setActivityOptions(bOptions)
.setUserId(userId)
.execute();
}
到了這一層感覺就看不懂了，不知道的東西太多，就不深入探究了
這就是第一步過程，應用進程調用ATMS系統進程發起打開Activity的請求，ATMS 是10.0才有的，分擔了一些AMS的工作，其內部也有很多是調用AMS完成的。用一張圖表示
image.png
從先在開始啟動流程就進入到系統進程中了。
2. 系統進程對創建Activity的處理
2.1 ATMS 發起打開Activity或者是創建進程的請求
image.png
ActivityTaskManagerService 最終會執行 ActivityStarter.execute方法
int execute() {
try {
// TODO(b/64750076): Look into passing request directly to these methods to allow
// for transactional diffs and preprocessing.
if (mRequest.mayWait) {
return startActivityMayWait(mRequest.caller, mRequest.callingUid,
mRequest.callingPackage, mRequest.realCallingPid, mRequest.realCallingUid,
mRequest.intent, mRequest.resolvedType,
mRequest.voiceSession, mRequest.voiceInteractor, mRequest.resultTo,
mRequest.resultWho, mRequest.requestCode, mRequest.startFlags,
mRequest.profilerInfo, mRequest.waitResult, mRequest.globalConfig,
mRequest.activityOptions, mRequest.ignoreTargetSecurity, mRequest.userId,
mRequest.inTask, mRequest.reason,
mRequest.allowPendingRemoteAnimationRegistryLookup,
mRequest.originatingPendingIntent, mRequest.allowBackgroundActivityStart);
} else {
return startActivity(mRequest.caller, mRequest.intent, mRequest.ephemeralIntent,
mRequest.resolvedType, mRequest.activityInfo, mRequest.resolveInfo,
mRequest.voiceSession, mRequest.voiceInteractor, mRequest.resultTo,
mRequest.resultWho, mRequest.requestCode, mRequest.callingPid,
mRequest.callingUid, mRequest.callingPackage, mRequest.realCallingPid,
mRequest.realCallingUid, mRequest.startFlags, mRequest.activityOptions,
mRequest.ignoreTargetSecurity, mRequest.componentSpecified,
mRequest.outActivity, mRequest.inTask, mRequest.reason,
mRequest.allowPendingRemoteAnimationRegistryLookup,
mRequest.originatingPendingIntent, mRequest.allowBackgroundActivityStart);
}
} finally {
onExecutionComplete();
}
}
上面這個分叉最終都會走到 startActivity
里面又調用了startActivityUnchecked方法，之后調用RootActivityContainer的resumeFocusedStacksTopActivities方法。RootActivityContainer是Android10新增的類，分擔了之前ActivityStackSupervisor的部分功能。接著跳轉到ActivityStack的resumeTopActivityUncheckedLocked方法然后又調用resumeTopActivityInnerLocked，中間沒有什么邏輯需要看的，所以就跳過了，直接看resumeTopActivityInnerLocked：
private boolean resumeTopActivityInnerLocked(ActivityRecord prev, ActivityOptions options) {
...
boolean pausing = getDisplay().pauseBackStacks(userLeaving, next, false);
if (mResumedActivity != null) {
if (DEBUG_STATES) Slog.d(TAG_STATES,
"resumeTopActivityLocked: Pausing " + mResumedActivity);
// 暫停上一個Activity
pausing |= startPausingLocked(userLeaving, false, next, false);
}
...
//這里next.attachedToProcess()，只有啟動了的Activity才會返回true
if (next.attachedToProcess()) {
...
try {
final ClientTransaction transaction =
ClientTransaction.obtain(next.app.getThread(), next.appToken);
...
//啟動了的Activity就發送ResumeActivityItem事務給客戶端了，后面會講到
transaction.setLifecycleStateRequest(
ResumeActivityItem.obtain(next.app.getReportedProcState(),
getDisplay().mDisplayContent.isNextTransitionForward()));
mService.getLifecycleManager().scheduleTransaction(transaction);
....
} catch (Exception e) {
....
mStackSupervisor.startSpecificActivityLocked(next, true, false);
return true;
}
....
} else {
....
if (SHOW_APP_STARTING_PREVIEW) {
//這里就是 冷啟動時 出現白屏 的原因了：取根activity的主題背景 展示StartingWindow
next.showStartingWindow(null , false ,false);
}
// 繼續當前Activity，普通activity的正常啟動 關注這里即可
mStackSupervisor.startSpecificActivityLocked(next, true, true);
}
return true;
}
這里先暫停上個Activity，然后再進入到 ActivityStackSupervisor.startSpecificActivityLocked方法中
void startSpecificActivityLocked(ActivityRecord r, boolean andResume, boolean checkConfig) {
// Is this activity's application already running?
final WindowProcessController wpc =
mService.getProcessController(r.processName, r.info.applicationInfo.uid);
boolean knownToBeDead = false;
if (wpc != null && wpc.hasThread()) {
try {
realStartActivityLocked(r, wpc, andResume, checkConfig);
return;
} catch (RemoteException e) {
Slog.w(TAG, "Exception when starting activity "
+ r.intent.getComponent().flattenToShortString(), e);
}
knownToBeDead = true;
}
...
try {
if (Trace.isTagEnabled(TRACE_TAG_ACTIVITY_MANAGER)) {
Trace.traceBegin(TRACE_TAG_ACTIVITY_MANAGER, "dispatchingStartProcess:"
+ r.processName);
}
// 上面的wpc != null && wpc.hasThread()不滿足的話，說明沒有進程，就會取創建進程
final Message msg = PooledLambda.obtainMessage(
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);
}
}
這里 會先判斷進程有沒創建，創建的話會進入 realStartActivityLocked，沒開啟的話會調用 ActivityManagerInternal.startProgress，下面我們先看進程以已經創建的情況
2.2 在當前進程開啟Activity
當前進程指的是APP進程，不是系統進程
進入realStartActivityLocked
boolean realStartActivityLocked(ActivityRecord r, WindowProcessController proc,
boolean andResume, boolean checkConfig) throws RemoteException {
...
// Create activity launch transaction.
final ClientTransaction clientTransaction = ClientTransaction.obtain(
proc.getThread(), r.appToken);
final DisplayContent dc = r.getDisplay().mDisplayContent;
clientTransaction.addCallback(LaunchActivityItem.obtain(new Intent(r.intent),
System.identityHashCode(r), r.info,
// TODO: Have this take the merged configuration instead of separate global
// and override configs.
mergedConfiguration.getGlobalConfiguration(),
mergedConfiguration.getOverrideConfiguration(), r.compat,
r.launchedFromPackage, task.voiceInteractor, proc.getReportedProcState(),
r.icicle, r.persistentState, results, newIntents,
dc.isNextTransitionForward(), proc.createProfilerInfoIfNeeded(),
r.assistToken));
// Set desired final state.
final ActivityLifecycleItem lifecycleItem;
if (andResume) {
lifecycleItem = ResumeActivityItem.obtain(dc.isNextTransitionForward());
} else {
lifecycleItem = PauseActivityItem.obtain();
}
clientTransaction.setLifecycleStateRequest(lifecycleItem);
// Schedule transaction.
mService.getLifecycleManager().scheduleTransaction(clientTransaction);
...
return true;
}
中間有段代碼如上，通過 ClientTransaction.obtain( proc.getThread(), r.appToken)獲取了clientTransaction，其中參數proc.getThread()是IApplicationThread，就是前面提到的ApplicationThread在系統進程的代理。
ClientTransaction是包含一系列的待客戶端處理的事務的容器，客戶端接收后取出事務并執行。
接著看，使用clientTransaction.addCallback添加了LaunchActivityItem實例：
//都是用來發送到客戶端的
private List<ClientTransactionItem> mActivityCallbacks;
public void addCallback(ClientTransactionItem activityCallback) {
if (mActivityCallbacks == null) {
mActivityCallbacks = new ArrayList<>();
}
mActivityCallbacks.add(activityCallback);
}
LaunchActivityItem看名字就像是啟動Activity的，走到這里只是把
LaunchActivityItem保存了起來，那再回到realStartActivityLocked 中，接著調用了mService.getLifecycleManager().scheduleTransaction(clientTransaction)，mService是ActivityTaskManagerService，getLifecycleManager()方法獲取的是ClientLifecycleManager實例，它的scheduleTransaction方法如下：
void scheduleTransaction(ClientTransaction transaction) throws RemoteException {
final IApplicationThread client = transaction.getClient();
transaction.schedule();
if (!(client instanceof Binder)) {
transaction.recycle();
}
}
看一下 ClientTransaction.schedule();
public void schedule() throws RemoteException {
mClient.scheduleTransaction(this);
}
這個Client 就是ApplicationThread 下面啟動進程的時候會講到這個東西就是系統進程給APP進程通信的媒介，所以這一步就又回到APP進程了。
2.3 回到APP進程 進行創建Activity的后續操作
ApplicationThread 的scheduleTransaction 調用的是ActivityThread 的scheduleTransaction，是在它的父類ClientTransactionHandler中實現的：
void scheduleTransaction(ClientTransaction transaction) {
transaction.preExecute(this);
sendMessage(ActivityThread.H.EXECUTE_TRANSACTION, transaction);
}
這里發送了一個消息，最終由ActivityThread的H(一個Handler)處理，為什么要使用Handler呢，因為scheduleTransaction方法是被系統進程調用的，跨進程的方法調用都發生在Binder的線程池中
所以在這里要發送到主線程執行
最終是這樣執行的：
case EXECUTE_TRANSACTION:
final ClientTransaction transaction = (ClientTransaction) msg.obj;
mTransactionExecutor.execute(transaction);
if (isSystem()) {
// Client transactions inside system process are recycled on the client side
// instead of ClientLifecycleManager to avoid being cleared before this
// message is handled.
transaction.recycle();
}
break;
又交給了mTransactionExecutor這個對象處理，但是最終還是交給了ActivityThread 的 handleLaunchActivity。
下面就進入到另一個核心部分，創建Activity和Activity生命周期的管理
2.4 創建Activity以及Activity生命周期的管理
進入handleLaunchActivity
public Activity handleLaunchActivity(ActivityClientRecord r,
PendingTransactionActions pendingActions, Intent customIntent) {
...
final Activity a = performLaunchActivity(r, customIntent);
...
return a;
}
繼續跟performLaunchActivity方法，這里就是activity 啟動的核心實現了：
/** activity 啟動的核心實現. */
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
//1、從ActivityClientRecord獲取待啟動的Activity的組件信息
ActivityInfo aInfo = r.activityInfo;
if (r.packageInfo == null) {
r.packageInfo = getPackageInfo(aInfo.applicationInfo, r.compatInfo,
Context.CONTEXT_INCLUDE_CODE);
}
ComponentName component = r.intent.getComponent();
if (component == null) {
component = r.intent.resolveActivity(
mInitialApplication.getPackageManager());
r.intent.setComponent(component);
}
if (r.activityInfo.targetActivity != null) {
component = new ComponentName(r.activityInfo.packageName,
r.activityInfo.targetActivity);
}
//創建ContextImpl對象
ContextImpl appContext = createBaseContextForActivity(r);
Activity activity = null;
try {
//2、創建activity實例
java.lang.ClassLoader cl = appContext.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) {
..
}
try {
//3、創建Application對象（如果沒有的話）
Application app = r.packageInfo.makeApplication(false, mInstrumentation);
...
if (activity != null) {
CharSequence title = r.activityInfo.loadLabel(appContext.getPackageManager());
Configuration config = new Configuration(mCompatConfiguration);
if (r.overrideConfig != null) {
config.updateFrom(r.overrideConfig);
}
Window window = null;
if (r.mPendingRemoveWindow != null && r.mPreserveWindow) {
window = r.mPendingRemoveWindow;
r.mPendingRemoveWindow = null;
r.mPendingRemoveWindowManager = null;
}
appContext.setOuterContext(activity);
//4、attach方法為activity關聯上下文環境
activity.attach(appContext, this, getInstrumentation(), r.token,
r.ident, app, r.intent, r.activityInfo, title, r.parent,
r.embeddedID, r.lastNonConfigurationInstances, config,
r.referrer, r.voiceInteractor, window, r.configCallback,
r.assistToken);
if (customIntent != null) {
activity.mIntent = customIntent;
}
r.lastNonConfigurationInstances = null;
checkAndBlockForNetworkAccess();
activity.mStartedActivity = false;
int theme = r.activityInfo.getThemeResource();
if (theme != 0) {
activity.setTheme(theme);
}
activity.mCalled = false;
//5、調用生命周期onCreate
if (r.isPersistable()) {
mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);
} else {
mInstrumentation.callActivityOnCreate(activity, r.state);
}
if (!activity.mCalled) {
throw new SuperNotCalledException(
"Activity " + r.intent.getComponent().toShortString() +
" did not call through to super.onCreate()");
}
r.activity = activity;
}
r.setState(ON_CREATE);
synchronized (mResourcesManager) {
mActivities.put(r.token, r);
}
}
...
return activity;
}
performLaunchActivity主要完成以下事情：
從ActivityClientRecord獲取待啟動的Activity的組件信息
通過mInstrumentation.newActivity方法使用類加載器創建activity實例
通過LoadedApk的makeApplication方法創建Application對象，內部也是通過mInstrumentation使用類加載器，創建后就調用了instrumentation.callApplicationOnCreate方法，也就是Application的onCreate方法。
創建ContextImpl對象并通過activity.attach方法對重要數據初始化，關聯了Context的具體實現ContextImpl，attach方法內部還完成了window創建，這樣Window接收到外部事件后就能傳遞給Activity了。
調用Activity的onCreate方法，是通過 mInstrumentation.callActivityOnCreate方法完成，Activity就創建完成了。
那onStart 和 onResume是什么時候調用的呢
我們再來重新看看在ActivityStackSupervisor的realStartActivityLocked方法：
boolean realStartActivityLocked(ActivityRecord r, WindowProcessController proc,
boolean andResume, boolean checkConfig) throws RemoteException {
...
// Create activity launch transaction.
final ClientTransaction clientTransaction = ClientTransaction.obtain(
proc.getThread(), r.appToken);
final DisplayContent dc = r.getDisplay().mDisplayContent;
clientTransaction.addCallback(LaunchActivityItem.obtain(new Intent(r.intent),
System.identityHashCode(r), r.info,
mergedConfiguration.getGlobalConfiguration(),
mergedConfiguration.getOverrideConfiguration(), r.compat,
r.launchedFromPackage, task.voiceInteractor, proc.getReportedProcState(),
r.icicle, r.persistentState, results, newIntents,
dc.isNextTransitionForward(), proc.createProfilerInfoIfNeeded(),
r.assistToken));
// Set desired final state.
final ActivityLifecycleItem lifecycleItem;
//這里ResumeActivityItem
if (andResume) {
lifecycleItem = ResumeActivityItem.obtain(dc.isNextTransitionForward());
} else {
lifecycleItem = PauseActivityItem.obtain();
}
clientTransaction.setLifecycleStateRequest(lifecycleItem);
// Schedule transaction.
mService.getLifecycleManager().scheduleTransaction(clientTransaction);
...
return true;
}
可以看到里面有一個 ResumeActivityItem 然后調用了mService.getLifecycleManager().scheduleTransaction，這個剛才說了會調用到ActivityThread里的方法，其實最后調用了ActivityThread的handleResumeActivity方法：
@Override
public void handleResumeActivity(IBinder token, boolean finalStateRequest, boolean isForward,
String reason) {
...
// performResumeActivity內部會走onStart、onResume
final ActivityClientRecord r = performResumeActivity(token, finalStateRequest, reason);
if (r == null) {
// We didn't actually resume the activity, so skipping any follow-up actions.
return;
}
...
if (r.window == null && !a.mFinished && willBeVisible) {
r.window = r.activity.getWindow();
View decor = r.window.getDecorView();
decor.setVisibility(View.INVISIBLE);
ViewManager wm = a.getWindowManager();
WindowManager.LayoutParams l = r.window.getAttributes();
a.mDecor = decor;
l.type = WindowManager.LayoutParams.TYPE_BASE_APPLICATION;
l.softInputMode |= forwardBit;
if (r.mPreserveWindow) {
a.mWindowAdded = true;
r.mPreserveWindow = false;
ViewRootImpl impl = decor.getViewRootImpl();
if (impl != null) {
impl.notifyChildRebuilt();
}
}
...
if (!r.activity.mFinished && willBeVisible && r.activity.mDecor != null && !r.hideForNow) {
if (r.newConfig != null) {
performConfigurationChangedForActivity(r, r.newConfig);
if (DEBUG_CONFIGURATION) {
Slog.v(TAG, "Resuming activity " + r.activityInfo.name + " with newConfig "
+ r.activity.mCurrentConfig);
}
r.newConfig = null;
}
if (localLOGV) Slog.v(TAG, "Resuming " + r + " with isForward=" + isForward);
WindowManager.LayoutParams l = r.window.getAttributes();
if ((l.softInputMode
& WindowManager.LayoutParams.SOFT_INPUT_IS_FORWARD_NAVIGATION)
!= forwardBit) {
l.softInputMode = (l.softInputMode
& (~WindowManager.LayoutParams.SOFT_INPUT_IS_FORWARD_NAVIGATION))
| forwardBit;
if (r.activity.mVisibleFromClient) {
ViewManager wm = a.getWindowManager();
View decor = r.window.getDecorView();
wm.updateViewLayout(decor, l);
}
}
r.activity.mVisibleFromServer = true;
mNumVisibleActivities++;
if (r.activity.mVisibleFromClient) {
//添加window、設置可見
r.activity.makeVisible();
}
}
r.nextIdle = mNewActivities;
mNewActivities = r;
if (localLOGV) Slog.v(TAG, "Scheduling idle handler for " + r);
Looper.myQueue().addIdleHandler(new Idler());
}
handleResumeActivity主要做了以下事情：
- 調用生命周期：通過performResumeActivity方法，內部調用生命周期onStart、onResume方法
- 設置視圖可見：通過activity.makeVisible方法，添加window、設置可見。（所以視圖的真正可見是在onResume方法之后）
到這里一個Activity就真正顯示出來了
3 創建進程
下面開始看進程不存在的情況，會調用ActivityManagerInternal::startProcess ActivityManagerInternal 是一個抽象類，具體的實現類時 AMS 中的 LocalService，具體代碼就不看了，很復雜，最后AMS 會通過socket與Zygote進行通信去創建APP進程**，Zygote會fork一個進程出來
為什么這里使用Socket與zygote進行通信呢，可以參考這篇文章為什么systemServer進程與zygote進程的通信是使用socket而不是binder？
APP進程創建好之后 就會執行ActivityThread的main方，這就是Android 每個進程的入口方法
public static void main(String[] args) {
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "ActivityThreadMain");
SamplingProfilerIntegration.start();
// CloseGuard defaults to true and can be quite spammy. We
// disable it here, but selectively enable it later (via
// StrictMode) on debug builds, but using DropBox, not logs.
CloseGuard.setEnabled(false);
Environment.initForCurrentUser();
// Set the reporter for event logging in libcore
EventLogger.setReporter(new EventLoggingReporter());
// Make sure TrustedCertificateStore looks in the right place for CA certificates
final File configDir = Environment.getUserConfigDirectory(UserHandle.myUserId());
TrustedCertificateStore.setDefaultUserDirectory(configDir);
Process.setArgV0("<pre-initialized>");
Looper.prepareMainLooper();
ActivityThread thread = new ActivityThread();
thread.attach(false);
if (sMainThreadHandler == null) {
sMainThreadHandler = thread.getHandler();
}
if (false) {
Looper.myLooper().setMessageLogging(new
LogPrinter(Log.DEBUG, "ActivityThread"));
}
// End of event ActivityThreadMain.
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
Looper.loop();
throw new RuntimeException("Main thread loop unexpectedly exited");
}
這里面有很多內容，最重要的兩個是：
1. 執行了Looper.prepareMainLooper()，這會在主線程中創建一個Looper，然后調用Looper.loop 開啟無限循環，這就是Android 中消息機制的核心
2. 創建了一個ActivityThread，并調用attach方法
里面又創建了一個ActivityThread對象，因為main方法是static的，所以在調用的時候是不存在ActivityThread對象的，之前包括之后使用的所有ActivityThread都是在這創建出來的。然后調用了它的attach：
image.png
這個方法的主要目的是將APP進程中的 ApplicationThread 傳遞給AMS，之后AMS進程與APP進程的通信就靠它了。
下面是ActivityManagerService的attachApplicationLocked：
private final boolean attachApplicationLocked(IApplicationThread thread,
int pid, int callingUid, long startSeq) {
...
//1、IPC操作，創建綁定Application
thread.bindApplication(processName, appInfo, providers, null, profilerInfo,
null, null, null, testMode,
mBinderTransactionTrackingEnabled, enableTrackAllocation,
isRestrictedBackupMode || !normalMode, app.isPersistent(),
new Configuration(app.getWindowProcessController().getConfiguration()),
app.compat, getCommonServicesLocked(app.isolated),
mCoreSettingsObserver.getCoreSettingsLocked(),
buildSerial, autofillOptions, contentCaptureOptions);
...
// 2、賦值IApplicationThread
app.makeActive(thread, mProcessStats);
...
// See if the top visible activity is waiting to run in this process...
if (normalMode) {
try {
//3、通過ATMS啟動 根activity
didSomething = mAtmInternal.attachApplication(app.getWindowProcessController());
} catch (Exception e) {
Slog.wtf(TAG, "Exception thrown launching activities in " + app, e);
badApp = true;
}
}
...
}
AMS的attachApplicationLocked方法主要三件事：
- 調用IApplicationThread的bindApplication方法，IPC操作，創建綁定Application；
- 通過makeActive方法賦值IApplicationThread
- 通過ATMS啟動 根activity
先看一下第一個ApplicationThread.bindApplication：
image.png
image.png
初始化了一大堆東西，最后發送了一條消息
image.png
ActivityThread 內部的Handler在收到這條消息之后調用了handleBindApplication方法創建了Instrumentation
image.png
然后又創建了Application
image.png
Application 最終還是在 Instrumentation中創建的
public Application newApplication(ClassLoader cl, String className, Context context)
throws InstantiationException, IllegalAccessException,
ClassNotFoundException {
Application app = getFactory(context.getPackageName())
.instantiateApplication(cl, className);
app.attach(context);
return app;
}
創建完Application 會將外部創建的 ContextImpl 作為baseContext傳遞給Application，然后又通過Instrumentation 調用了 callApplicationOnCreate
image.png
第二件事就是將APP進程內的ApplicationThread保存下來
再來看 根activity 的啟動，回到上面AMS的attachApplicationLocked方法，調用了mAtmInternal.attachApplication方法，mAtmInternal是ActivityTaskManagerInternal實例，具體實現是在ActivityTaskManagerService的內部類LocalService，去看看：
//ActivityTaskManagerService#LocalService
public boolean attachApplication(WindowProcessController wpc) throws RemoteException {
synchronized (mGlobalLockWithoutBoost) {
return mRootActivityContainer.attachApplication(wpc);
}
}
mRootActivityContainer是RootActivityContainer實例，看下它的attachApplication方法：
boolean attachApplication(WindowProcessController app) throws RemoteException {
final String processName = app.mName;
boolean didSomething = false;
for (int displayNdx = mActivityDisplays.size() - 1; displayNdx >= 0; --displayNdx) {
final ActivityDisplay display = mActivityDisplays.get(displayNdx);
final ActivityStack stack = display.getFocusedStack();
if (stack != null) {
stack.getAllRunningVisibleActivitiesLocked(mTmpActivityList);
final ActivityRecord top = stack.topRunningActivityLocked();
final int size = mTmpActivityList.size();
for (int i = 0; i < size; i++) {
final ActivityRecord activity = mTmpActivityList.get(i);
if (activity.app == null && app.mUid == activity.info.applicationInfo.uid
&& processName.equals(activity.processName)) {
try {
if (mStackSupervisor.realStartActivityLocked(activity, app,
top == activity /* andResume */, true /* checkConfig */)) {
didSomething = true;
}
}
...
}
}
}
}
if (!didSomething) {
ensureActivitiesVisible(null, 0, false /* preserve_windows */);
}
return didSomething;
}
眼神好的人看到了realStartActivityLocked，這不又回到了2.2小節了嗎，后面的流程就一樣了。
至此Activity啟動流程就完成了
總結
Activity的啟動總體是職責與操作系統中的進程管理和調度模塊相類似，因此它在Android中非常一波三折，流程還是很長的
先解釋一下幾個比較重要的類：
- **Instrumentation **負責 Application 和 四大組件生命周期調用
- ActivityTaskManagerService & ActivityMangerService 也就是常說的 ATMS 和 AMS， 是在系統進程中的實例，Android中最核心的服務之一，負責系統中四大組件的啟動、切換、調度及應用進程的管理和調度等工作，其重要，它本身也是一個Binder的實現類。
- ApplicationThread 是ActivityThread的內部類，繼承IApplicationThread.Stub，是一個IBinder，是ActiivtyThread和AMS通信的橋梁，AMS則通過代理調用此App進程的本地方法，運行在Binder線程池
- ActivityThread 應用的入口類，系統通過調用main函數，開啟消息循環隊列。ActivityThread所在線程被稱為應用的主線程（UI線程）
整個流程可以分為下面幾部
- Activity調用startActivity 走到了 Instrumentation，然后Instrumentation 拿到ATMS 調用ATMS 的startActivity 進入了系統進程內
- 然后ATMS 和 AMS 一連串的調用到了ActivityStackSupervisor 的
startSpecificActivityLocked，在這里先判斷Activity所在的進程有沒有被創建，如果沒創建就走到 LocalService.startProgress 創建進程，如果已經創建了進程就直接到第6步 - 創建完進程之后 會通過反射調用ActivityThread的main方法進入Android的主線程 創建無限循環的Looper，然后創建一個ActivityThread 實例，調用attach方法，里面又調用了AMS的 attachApplicationLocked，將APP進程中的ApplicationThread傳遞給AMS 用于兩個進程綁定，從這開始又進入了系統進程（這一步才開始APP進程與系統進程的交互，前面的都是啟動Activity的那個進程和系統進程的交互）
- AMS 進行了一系列準備工作 然后又調用了ActivityThread 的 bindApplication方法，這個方法里會調用Instrumentation創建Application，調用Application的attachBaseContext和onCreate方法，Application就創建完畢了
- 再調用ActivityThread .bindApplication創建完APP進程的Application之后，調用了AMS中的attachApplication，里面又調用了ActivityStackSupervisor.realStartActivityLocked 方法
6.從 realStartActivityLocked 開始真正的開啟Activity啟動，在這之前會先pause上一個Activity,然后創建LacunchActivityItem和 ResumeLauncherActivity，然后將LacunchActivityItem通ApplicationThread發送給APP進程的ActivityThread - 這一步開始又回到了APP進程，ActivityThread通過Handler來處理事件，最后調用到了自己的performLaunchActivity方法，然后通過Instrumentation的newActivity方法反射創建了Activity實例，然后調用activity.attach進行方法關聯Context 初始化window等方法，然后調用Activity的onCreate方法，到這一步Activity就創建完畢了
8.在第6步中創建了ResumeActivityItem，同樣的也會調用到APP進程中的ActivityThread 中的方法，這次調用的是 handleResumeActivity，調用performResumeActivity里面主要是通過Instrumentation調用了onStart和onResume方法，performResumeActivity調用完畢后才將dcorview 添加到window上，所以view真正是的可見是在onResume之后的。對Activity來說，在onResume之前 只是創建了Window并把Window顯示出來了，但是并沒有添加實質性的可以看到的View。所以就不明白官方對生命周期的描述 onStart代表Activity可見，onResume代表Activity已經獲取到焦點
題外話
Activity啟動完成了，但是View的三大流程什么時候開始的呢？
本文參考了大佬的文章
源碼可以在Code Search查看
