概述
本文的內(nèi)容緊接著上一篇文章Android源碼探究：Activity啟動(dòng)流程完全解析(上)，繼續(xù)介紹Activity的啟動(dòng)流程。
主流程分析
8-1、ActivityManagerService#activityPaused(token)
經(jīng)過(guò)客戶端的跨進(jìn)程調(diào)用，AMS的activityPaused(token)被調(diào)用了。
@Override
public final void activityPaused(IBinder token) {
final long origId = Binder.clearCallingIdentity();
synchronized(this) {
ActivityStack stack = ActivityRecord.getStackLocked(token);
if (stack != null) {
stack.activityPausedLocked(token, false);
}
}
Binder.restoreCallingIdentity(origId);
}
根據(jù)token來(lái)獲取Activity所在的ActivityStack，進(jìn)一步調(diào)用activityPausedLocked(params..)
8-2、ActivityStack#activityPausedLocked(params..)
final void activityPausedLocked(IBinder token, boolean timeout) {
//先從ActivityStack根據(jù)token取出對(duì)應(yīng)的ActivityRecord
final ActivityRecord r = isInStackLocked(token);
if (r != null) {
mHandler.removeMessages(PAUSE_TIMEOUT_MSG, r);
//如果二者相等，表示記錄的需要暫停的Activity已經(jīng)暫停完畢
if (mPausingActivity == r) {
mService.mWindowManager.deferSurfaceLayout();
try {
completePauseLocked(true /* resumeNext */, null /* resumingActivity */);
} finally {
mService.mWindowManager.continueSurfaceLayout();
}
return;
} else {
//省略...
}
}
mStackSupervisor.ensureActivitiesVisibleLocked(null, 0, !PRESERVE_WINDOWS);
}
這里沒(méi)什么好說(shuō)的，我們繼續(xù)看completePauseLocked(params..)。
8-3、ActivityStack#completePauseLocked(params..)
private void completePauseLocked(boolean resumeNext, ActivityRecord resuming) {
ActivityRecord prev = mPausingActivity;
//省略大部分的代碼...
if (resumeNext) {
final ActivityStack topStack = mStackSupervisor.getFocusedStack();
if (!topStack.shouldSleepOrShutDownActivities()) {
mStackSupervisor.resumeFocusedStackTopActivityLocked(topStack, prev, null);
} else {
//...
}
}
}
當(dāng)代碼執(zhí)行到這里的時(shí)候，讀者應(yīng)該對(duì)這個(gè)方法resumeFocusedStackTopActivityLocked(params..)有點(diǎn)眼熟吧？上面已經(jīng)執(zhí)行過(guò)該方法了，接下來(lái)的調(diào)用鏈都是一樣的了，最終會(huì)執(zhí)行到ActivityStackSupervisor#startSpecificActivityLocked(params..)這個(gè)方法，進(jìn)行Activity的真正啟動(dòng)過(guò)程。
8-4、ActivityStackSupervisor#startSpecificActivityLocked(params..)
void startSpecificActivityLocked(ActivityRecord r,
boolean andResume, boolean checkConfig) {
//獲取Activity所對(duì)應(yīng)的進(jìn)程記錄
ProcessRecord app = mService.getProcessRecordLocked(r.processName,
r.info.applicationInfo.uid, true);
getLaunchTimeTracker().setLaunchTime(r);
//如果該進(jìn)程已經(jīng)啟動(dòng)了，那么直接開(kāi)始啟動(dòng)Activity
if (app != null && app.thread != null) {
try {
//若該Activity的flag不包含多進(jìn)程標(biāo)志位 或 不是安卓框架的組件
if ((r.info.flags&ActivityInfo.FLAG_MULTIPROCESS) == 0
|| !"android".equals(r.info.packageName)) {
// Don't add this if it is a platform component that is marked
// to run in multiple processes, because this is actually
// part of the framework so doesn't make sense to track as a
// separate apk in the process.
// 如果它是一個(gè)標(biāo)記為多進(jìn)程運(yùn)行的平臺(tái)組件，則不要添加該項(xiàng)，
// 因?yàn)檫@實(shí)際上是安卓框架的一部分，因此在進(jìn)程中作為單獨(dú)的apk進(jìn)行跟蹤是沒(méi)有意義的。
app.addPackage(r.info.packageName, r.info.applicationInfo.longVersionCode,
mService.mProcessStats);
}
//真正地啟動(dòng)一個(gè)Activity
realStartActivityLocked(r, app, andResume, checkConfig);
return;
} catch (RemoteException e) {
//...
}
// If a dead object exception was thrown -- fall through to
// restart the application.
}
//代碼9-1：否則，先啟動(dòng)一個(gè)新的進(jìn)程，然后再啟動(dòng)Activity
mService.startProcessLocked(r.processName, r.info.applicationInfo, true, 0,
"activity", r.intent.getComponent(), false, false, true);
}
代碼的邏輯很清晰明了，主要是先判斷Activity所對(duì)應(yīng)的進(jìn)程是否已經(jīng)存在，如果存在了那就直接去執(zhí)行真正的啟動(dòng)Activity過(guò)程；如果該進(jìn)程還不存在，那么就要去啟動(dòng)一個(gè)進(jìn)程。接下來(lái)的分析有兩條路可以走，一是沿著Activity啟動(dòng)進(jìn)行分析；二是沿著進(jìn)程的啟動(dòng)進(jìn)行分析。實(shí)際上進(jìn)程的啟動(dòng)完畢之后也還是要進(jìn)行Activity的啟動(dòng)的。也就是說(shuō)調(diào)用了mService.startProcessLocked(params)后，會(huì)啟動(dòng)新的進(jìn)程，然后ActivityStackSupervisor再次調(diào)用realStartActivityLocked(params..)在進(jìn)程內(nèi)啟動(dòng)Activity。
其實(shí)，這個(gè)調(diào)用順序符合這一種情況：在進(jìn)程A的ActivityA內(nèi)啟動(dòng)了進(jìn)程B的ActivityB，此時(shí)先暫停進(jìn)程A的ActivityA，然后進(jìn)程B還沒(méi)有啟動(dòng)，那么先啟動(dòng)進(jìn)程B，然后再啟動(dòng)ActivityB。
因此，接下來(lái)我們先來(lái)看怎樣啟動(dòng)一個(gè)新的進(jìn)程。
9-1、ActivityManagerService#startProcessLocked(params..)
final ProcessRecord startProcessLocked(String processName,
ApplicationInfo info, boolean knownToBeDead, int intentFlags,
String hostingType, ComponentName hostingName, boolean allowWhileBooting,
boolean isolated, boolean keepIfLarge) {
return startProcessLocked(processName, info, knownToBeDead, intentFlags, hostingType,
hostingName, allowWhileBooting, isolated, 0 /* isolatedUid */, keepIfLarge,
null /* ABI override */, null /* entryPoint */, null /* entryPointArgs */,
null /* crashHandler */);
}
private final boolean startProcessLocked(ProcessRecord app, String hostingType,
String hostingNameStr, boolean disableHiddenApiChecks, String abiOverride) {
//省略大部分代碼...
final String entryPoint = "android.app.ActivityThread";
return startProcessLocked(hostingType, hostingNameStr, entryPoint, app, uid, gids,
runtimeFlags, mountExternal, seInfo, requiredAbi, instructionSet, invokeWith,
startTime);
}
}
//一系列startProcessLocked(params..)重載方法的調(diào)用
//最終會(huì)調(diào)用下面的startProcess(params..)方法
private ProcessStartResult startProcess(String hostingType, String entryPoint,
ProcessRecord app, int uid, int[] gids, int runtimeFlags, int mountExternal,
String seInfo, String requiredAbi, String instructionSet, String invokeWith,
long startTime) {
try {
final ProcessStartResult startResult;
if (hostingType.equals("webview_service")) {
startResult = startWebView(entryPoint,
app.processName, uid, uid, gids, runtimeFlags, mountExternal,
app.info.targetSdkVersion, seInfo, requiredAbi, instructionSet,
app.info.dataDir, null,
new String[] {PROC_START_SEQ_IDENT + app.startSeq});
} else {
startResult = Process.start(entryPoint,
app.processName, uid, uid, gids, runtimeFlags, mountExternal,
app.info.targetSdkVersion, seInfo, requiredAbi, instructionSet,
app.info.dataDir, invokeWith,
new String[] {PROC_START_SEQ_IDENT + app.startSeq});
}
return startResult;
}
}
中間省略了大部分的重載方法的調(diào)用，最后來(lái)到了Process.start(params..)，把一系列進(jìn)程有關(guān)的信息都傳遞了進(jìn)去，根據(jù)這些信息來(lái)創(chuàng)建一個(gè)進(jìn)程。
9-2、Process#start(params..)
這個(gè)類的源碼在Android SDK內(nèi)可以找到，我們直接看它的代碼：
public static final ProcessStartResult start(final String processClass,
final String niceName,
int uid, int gid, int[] gids,
int runtimeFlags, int mountExternal,
int targetSdkVersion,
String seInfo,
String abi,
String instructionSet,
String appDataDir,
String invokeWith,
String[] zygoteArgs) {
return zygoteProcess.start(processClass, niceName, uid, gid, gids,
runtimeFlags, mountExternal, targetSdkVersion, seInfo,
abi, instructionSet, appDataDir, invokeWith, zygoteArgs);
}
這里我們需要關(guān)注一個(gè)參數(shù)processClass，當(dāng)一個(gè)進(jìn)程被啟動(dòng)后，以processClass為類名的類的main(args)函數(shù)會(huì)被調(diào)用。而這里的processClass是代碼9-1中傳遞進(jìn)來(lái)的“android.app.ActivityThread”。那么也就是說(shuō)，一個(gè)新的進(jìn)程啟動(dòng)后，它的ActivityThread的main()函數(shù)會(huì)最先得到執(zhí)行。所以，ActivityThread#main()是整個(gè)應(yīng)用程序的入口。
9-3、zygoteProcess#start(params..)
代碼執(zhí)行到了zygoteProcess的start(params..)方法，我們先來(lái)看一下代碼的執(zhí)行：
public final Process.ProcessStartResult start(final String processClass,
final String niceName,int uid, int gid, int[] gids,
int runtimeFlags, int mountExternal,int targetSdkVersion,
String seInfo,String abi,String instructionSet,String appDataDir,
String invokeWith,String[] zygoteArgs) {
try {
return startViaZygote(processClass, niceName, uid, gid, gids,
runtimeFlags, mountExternal, targetSdkVersion, seInfo,
abi, instructionSet, appDataDir, invokeWith, false /* startChildZygote */,
zygoteArgs);
} catch{
//...
}
}
private Process.ProcessStartResult startViaZygote(params...)throws ZygoteStartFailedEx {
ArrayList<String> argsForZygote = new ArrayList<String>();
//為zygote進(jìn)程添加各種參數(shù)...
argsForZygote.add("--runtime-args");
argsForZygote.add("--setuid=" + uid);
argsForZygote.add("--setgid=" + gid);
//省略...
//這里加了鎖，同一時(shí)間內(nèi)只允許一條線程執(zhí)行創(chuàng)建進(jìn)程的操作
synchronized(mLock) {
return zygoteSendArgsAndGetResult(openZygoteSocketIfNeeded(abi), argsForZygote);
}
}
/**
* 把新進(jìn)程的參數(shù)發(fā)給zygote進(jìn)程，它會(huì)創(chuàng)建一個(gè)子進(jìn)程，并返回子進(jìn)程的pid
*
*/
@GuardedBy("mLock")
private static Process.ProcessStartResult zygoteSendArgsAndGetResult(
ZygoteState zygoteState, ArrayList<String> args)
throws ZygoteStartFailedEx {
try {
//這里的跨進(jìn)程通信，使用的是socket通信機(jī)制
//由于這里都是在鎖的機(jī)制下執(zhí)行，所以不會(huì)出現(xiàn)并發(fā)錯(cuò)誤
final BufferedWriter writer = zygoteState.writer;
final DataInputStream inputStream = zygoteState.inputStream;
//把所有新進(jìn)程的參數(shù)都寫(xiě)入緩沖區(qū)
writer.write(Integer.toString(args.size()));
writer.newLine();
for (int i = 0; i < sz; i++) {
String arg = args.get(i);
writer.write(arg);
writer.newLine();
}
writer.flush();
// Should there be a timeout on this?
Process.ProcessStartResult result = new Process.ProcessStartResult();
//讀取zygote進(jìn)程返回的值，這就是新進(jìn)程的pid
result.pid = inputStream.readInt();
result.usingWrapper = inputStream.readBoolean();
if (result.pid < 0) {
throw new ZygoteStartFailedEx("fork() failed");
}
return result;
}
}
zygote到底是何方神圣呢？其實(shí)在安卓系統(tǒng)啟動(dòng)的過(guò)程中，zygote進(jìn)程就會(huì)被啟動(dòng)，它負(fù)責(zé)了整個(gè)frameworks層和application層的所有進(jìn)程的創(chuàng)建和啟動(dòng)工作。也就是說(shuō)，所有的進(jìn)程都是它孕育出來(lái)的，都是它的子進(jìn)程。同時(shí)，zygote的中文意思受精卵剛好與它的行為相符合。
需要注意的是，上面的代碼都是運(yùn)行在AMS內(nèi)，只不過(guò)最后通過(guò)socket跨進(jìn)程通信的方式通知了zygote進(jìn)程來(lái)fork一個(gè)子進(jìn)程，并且獲取到了子進(jìn)程的pid。該子進(jìn)程創(chuàng)建、啟動(dòng)完畢之后，ActivityThread#main()方法就得到了調(diào)用。
10-1、ActivityThread#main()
ActivityThread的main()方法可以說(shuō)是我們應(yīng)用程序的開(kāi)端，它運(yùn)行在一個(gè)新的進(jìn)程空間內(nèi)。當(dāng)一個(gè)新的進(jìn)程啟動(dòng)完畢開(kāi)始運(yùn)行后，它首先要做的是通知AMS它被啟動(dòng)了，因?yàn)榇藭r(shí)AMS還等著它去執(zhí)行啟動(dòng)Activity的后續(xù)流程呢。我們來(lái)看看main()方法做了什么工作：
public static void main(String[] args) {
//初始化環(huán)境
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>");
//為主線程準(zhǔn)備Looper
Looper.prepareMainLooper();
//從命令行參數(shù)中獲取序列號(hào)
long startSeq = 0;
if (args != null) {
for (int i = args.length - 1; i >= 0; --i) {
if (args[i] != null && args[i].startsWith(PROC_START_SEQ_IDENT)) {
startSeq = Long.parseLong(
args[i].substring(PROC_START_SEQ_IDENT.length()));
}
}
}
//創(chuàng)建ActivityThread的實(shí)例
ActivityThread thread = new ActivityThread();
thread.attach(false, startSeq); //通知AMS進(jìn)行綁定操作
if (sMainThreadHandler == null) {
sMainThreadHandler = thread.getHandler();
}
Looper.loop(); //開(kāi)啟主線程的消息循環(huán)
throw new RuntimeException("Main thread loop unexpectedly exited");
}
代碼的邏輯很清晰，關(guān)鍵的地方上面也有注釋?？梢钥闯?，在main()函數(shù)的最后，開(kāi)啟了主線程的消息循環(huán)，通過(guò)Handler和Looper的組合，可以不斷地處理AMS、WMS發(fā)過(guò)來(lái)的消息請(qǐng)求等，有關(guān)主線程消息循環(huán)的內(nèi)容，有興趣的可以自行查閱相關(guān)的信息，這里不做展開(kāi)講述。我們的關(guān)注點(diǎn)放在thread.attach(false,startSeq)這行代碼內(nèi)，我們看看它做了什么工作吧。
10-2、ActivityThread#attach(params..)
private void attach(boolean system, long startSeq) {
sCurrentActivityThread = this;
mSystemThread = system;
if (!system) {
//獲取AMS在客戶端的代理對(duì)象
final IActivityManager mgr = ActivityManager.getService();
try {
//進(jìn)行跨進(jìn)程通信，通知AMS進(jìn)行綁定操作
//這里的mAppThread就是ApplicationThread，在ActivityThread
//被實(shí)例化的時(shí)候，它也被實(shí)例化了。
mgr.attachApplication(mAppThread, startSeq);
} catch (RemoteException ex) {
throw ex.rethrowFromSystemServer();
}
} else {
//...
}
//...
}
上面的代碼出現(xiàn)了ApplicationThread對(duì)象，它在前面已經(jīng)出現(xiàn)過(guò)很多次了，它是一個(gè)Binder對(duì)象，用于AMS來(lái)跨進(jìn)程與APP進(jìn)行消息通信。這里通過(guò)Binder跨進(jìn)程通信，調(diào)用了AMS的attachApplication(params..)方法。我們?cè)俅未蜷_(kāi)AMS的代碼，找到該方法。（需要注意的是：應(yīng)用程序的主線程執(zhí)行完該方法之后，繼續(xù)進(jìn)行消息循環(huán)，以等待下一次AMS的消息。）
10-3、ActivityManagerService#attachApplication(params..)
@Override
public final void attachApplication(IApplicationThread thread, long startSeq) {
synchronized (this) {
//..
attachApplicationLocked(thread, callingPid, callingUid, startSeq);
}
}
private final boolean attachApplicationLocked(IApplicationThread thread,
int pid, int callingUid, long startSeq) {
ProcessRecord app;
long startTime = SystemClock.uptimeMillis();
//根據(jù)pid來(lái)獲取進(jìn)程記錄
if (pid != MY_PID && pid >= 0) {
synchronized (mPidsSelfLocked) {
app = mPidsSelfLocked.get(pid);
}
} else {
app = null;
}
//ProcessRecord保存了當(dāng)前的IApplicationThread，即保存了客戶端的一個(gè)代理對(duì)象
//AMS能根據(jù)該Binder對(duì)象快速找到所指的應(yīng)用
app.makeActive(thread, mProcessStats);
//省略大部分代碼...
if (app.isolatedEntryPoint != null) {
//...
} else if (app.instr != null) {
//代碼11-1、跨進(jìn)程調(diào)用ApplicationThread的方法，告訴APP端有關(guān)該進(jìn)程的信息
thread.bindApplication(processName, appInfo, providers,
app.instr.mClass,
profilerInfo, app.instr.mArguments,
app.instr.mWatcher,
app.instr.mUiAutomationConnection, testMode,
mBinderTransactionTrackingEnabled, enableTrackAllocation,
isRestrictedBackupMode || !normalMode, app.persistent,
new Configuration(getGlobalConfiguration()), app.compat,
getCommonServicesLocked(app.isolated),
mCoreSettingsObserver.getCoreSettingsLocked(),
buildSerial, isAutofillCompatEnabled);
} else {
//...
}
}
// See if the top visible activity is waiting to run in this process...
if (normalMode) {
try {
//代碼12-1、告訴ActivityStackSupervisor，該app已經(jīng)完成了綁定操作，可以啟動(dòng)一個(gè)Activity了
if (mStackSupervisor.attachApplicationLocked(app)) {
didSomething = true;
}
}
}
return true;
}
上面已經(jīng)省略了大部分的代碼，很多都是異常狀態(tài)的處理以及初始化等邏輯，核心在于thread.bindApplication(params..)和mStackSupervisor.attachApplicationLocked(app)這兩個(gè)方法的調(diào)用上。前一行代碼通過(guò)IApplicationThread跨進(jìn)程通信，調(diào)用了APP端的相應(yīng)方法，把有關(guān)進(jìn)程的重要信息傳遞了過(guò)去。這樣便完成從客戶端到服務(wù)端的綁定操作。后一行代碼，通過(guò)ActivityStackSupervisor來(lái)找到對(duì)應(yīng)的ActivityStack，然后進(jìn)行綁定，這樣便完成了從服務(wù)端到客戶端的綁定操作。通過(guò)這兩個(gè)操作，客戶端的應(yīng)用程序知道了自己的應(yīng)用信息、進(jìn)程信息等；而服務(wù)端則知道了客戶端的Binder代理對(duì)象，方便之后的跨進(jìn)程操作。
11-1、ApplicationThread#bindApplication(params..)
我們先來(lái)看該方法的調(diào)用，我們又從AMS進(jìn)程回到了應(yīng)用進(jìn)程：
public final void bindApplication(params..) {
if (services != null) {
// Setup the service cache in the ServiceManager
ServiceManager.initServiceCache(services);
}
setCoreSettings(coreSettings);
AppBindData data = new AppBindData();
data.processName = processName;
data.appInfo = appInfo;
data.providers = providers;
//省略賦值代碼..
//通過(guò)Handler發(fā)送消息
sendMessage(H.BIND_APPLICATION, data);
}
由此可見(jiàn)，App的有關(guān)信息從AMS傳遞了過(guò)來(lái)，并保存在了AppBindData這個(gè)對(duì)象內(nèi)。接著，就是我們熟悉的發(fā)送消息過(guò)程，通過(guò)Handler切換到主線程，在主線程內(nèi)處理這個(gè)消息。代碼如下：
public void handleMessage(Message msg) {
switch (msg.what) {
case BIND_APPLICATION:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "bindApplication");
AppBindData data = (AppBindData)msg.obj;
handleBindApplication(data);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
break;
}
Object obj = msg.obj;
if (obj instanceof SomeArgs) {
((SomeArgs) obj).recycle();
}
}
得益于主線程的消息循環(huán)，當(dāng)H接受到BIND_APPLICATION的消息時(shí)，就能馬上開(kāi)始處理這個(gè)消息，處理完畢后繼續(xù)消息循環(huán)。
11-2、ActivityThread#handleBindApplication(data)
private void handleBindApplication(AppBindData data) {
//省略大部分代碼...
//創(chuàng)建上下文環(huán)境context
final ContextImpl appContext = ContextImpl.createAppContext(this, data.info);
Application app;
try {
app = data.info.makeApplication(data.restrictedBackupMode, null);
//....
try {
mInstrumentation.callApplicationOnCreate(app);
}
}
}
以上省略了絕大部分的代碼，很多都是初始化代碼，比如加載各種庫(kù)等。當(dāng)Application初始化完畢之后，調(diào)用了mInstrumentation.callApplicationOnCreate(app)。
11-3、Instrumentation#callApplicationOnCreate(app)
public void callApplicationOnCreate(Application app) {
app.onCreate();
}
很簡(jiǎn)單，調(diào)用了Application#onCreate()方法，也就是我們業(yè)務(wù)層常重寫(xiě)的方法之一，代碼執(zhí)行到這里，應(yīng)用程序的初始化已經(jīng)完成了。下面就是在應(yīng)用程序的基礎(chǔ)上啟動(dòng)一個(gè)Activity了。
12-1、ActivityStackSupervisor#attachApplicationLocked(app)
回到10-3的代碼，繼續(xù)往下執(zhí)行，接著AMS就會(huì)調(diào)用mStackSupervisor.attachApplicationLocked(app)方法，可想而知，在方法的內(nèi)部，應(yīng)該是要啟動(dòng)一個(gè)Activity了。因?yàn)橐磺械臏?zhǔn)備工作都已經(jīng)完成了。
boolean attachApplicationLocked(ProcessRecord app) throws RemoteException {
final String processName = app.processName;
boolean didSomething = false;
for (...) {
for (...) {
for (int i = 0; i < size; i++) {
final ActivityRecord activity = mTmpActivityList.get(i);
//如果該ActivityRecord的進(jìn)程字段為空 并且進(jìn)程uid與Activity的進(jìn)程id相同
//并且 進(jìn)程名字與Activity的進(jìn)程名字相同
if (activity.app == null && app.uid == activity.info.applicationInfo.uid
&& processName.equals(activity.processName)) {
try {
//啟動(dòng)該Activity
if (realStartActivityLocked(activity, app,
top == activity /* andResume */, true /* checkConfig */)) {
didSomething = true;
}
}
}
}
}
}
return didSomething;
}
上面代碼的邏輯主要是遍歷所有的任務(wù)棧，找到活躍的任務(wù)棧后，再在其中找到需要啟動(dòng)的Activity，將它啟動(dòng)。啟動(dòng)的邏輯放在了realStartActivityLocked(params..)，終于，我們又看到了這個(gè)方法，殊途同歸。
12-2、ActivityStackSupervisor#realStartActivityLocked(params..)
final boolean realStartActivityLocked(ActivityRecord r, ProcessRecord app,
boolean andResume, boolean checkConfig) throws RemoteException {
//這里進(jìn)行了判斷，如果有Activity處于未暫停的狀態(tài)，則不能啟動(dòng)一個(gè)新的Activity
//由于我們是從客戶端通知server來(lái)啟動(dòng)一個(gè)Activity的，因此已經(jīng)不存在未暫停的Activity了
if (!allPausedActivitiesComplete()) {
return false;
}
final TaskRecord task = r.getTask();
final ActivityStack stack = task.getStack();
try {
//創(chuàng)建一個(gè)客戶端的事務(wù)
final ClientTransaction clientTransaction = ClientTransaction.obtain(app.thread,
r.appToken);
//添加callback，留意這里的添加了LaunchActivityItem
clientTransaction.addCallback(LaunchActivityItem.obtain(new Intent(r.intent),
System.identityHashCode(r), r.info,
mergedConfiguration.getGlobalConfiguration(),
mergedConfiguration.getOverrideConfiguration(), r.compat,
r.launchedFromPackage, task.voiceInteractor, app.repProcState, r.icicle,
r.persistentState, results, newIntents, mService.isNextTransitionForward(),
profilerInfo));
//為該事務(wù)的目標(biāo)設(shè)置為ResumeActivityItem，即啟動(dòng)一個(gè)Activity，并改變它
//的生命周期到Resumed狀態(tài)
final ActivityLifecycleItem lifecycleItem;
if (andResume) {
lifecycleItem = ResumeActivityItem.obtain(mService.isNextTransitionForward());
}
clientTransaction.setLifecycleStateRequest(lifecycleItem);
//通過(guò)事務(wù)管理器執(zhí)行一個(gè)事務(wù)
mService.getLifecycleManager().scheduleTransaction(clientTransaction);
}
return true;
}
可以看到，我們?cè)俅斡龅搅耸煜さ?code>ClientTransaction，前面解析暫停Activity時(shí)也遇到它，那么接下來(lái)的邏輯應(yīng)該就是與暫停的邏輯差不多了，只不過(guò)現(xiàn)在的ActivityLifecycleItem變成了ResumeActivityItem，即Activity的目標(biāo)狀態(tài)是resumed。接下來(lái)的調(diào)用鏈與前面見(jiàn)過(guò)的是一致的，即：ClientLifecycleManager#scheduleTransaction(clientTransaction)
——>ClientTransaction.schedule()
——>IApplicationThread.scheduleTransaction(this)
——>ActivityThread#scheduleTransaction(transaction)
——>H#handleMessage(msg)
——>TransactionExecutor#execute(transaction)
其中，通過(guò)IApplicationThread這個(gè)Binder對(duì)象進(jìn)行了跨進(jìn)程調(diào)用，調(diào)用了APP端的方法，此時(shí)從AMS進(jìn)程切換到了我們的應(yīng)用進(jìn)程。緊接著，通過(guò)Handler機(jī)制切換到了主線程，并在主線程處理EXECUTE_TRANSACTION這個(gè)消息，接著進(jìn)一步交給TransactionExecutor來(lái)處理這個(gè)事務(wù)。
13-1、TransactionExecutor#execute(transaction)
在代碼7-1已經(jīng)介紹過(guò)這個(gè)方法了，我們?cè)賮?lái)簡(jiǎn)單看一下就行：
public void execute(ClientTransaction transaction) {
final IBinder token = transaction.getActivityToken();
log("Start resolving transaction for client: " + mTransactionHandler + ", token: " + token);
executeCallbacks(transaction);
executeLifecycleState(transaction);
mPendingActions.clear();
log("End resolving transaction");
}
在代碼12-2中，我們有留意到初始化clientTransaction時(shí)，為它添加了一個(gè)callback，即LaunchActivityItem，那么這里首先會(huì)執(zhí)行executeCallbacks(transaction)方法。
13-2、TransactionExecutor#executeCallbacks(transaction)
public void executeCallbacks(ClientTransaction transaction) {
final List<ClientTransactionItem> callbacks = transaction.getCallbacks();
if (callbacks == null) {
// No callbacks to execute, return early.
return;
}
log("Resolving callbacks");
final IBinder token = transaction.getActivityToken();
ActivityClientRecord r = mTransactionHandler.getActivityClient(token);
//根據(jù)前面的代碼，這里的size為1
final int size = callbacks.size();
for (int i = 0; i < size; ++i) {
final ClientTransactionItem item = callbacks.get(i);
log("Resolving callback: " + item);
//這里的Item實(shí)際上就是LaunchActivityItem.
item.execute(mTransactionHandler, token, mPendingActions);
item.postExecute(mTransactionHandler, token, mPendingActions);
//...
}
}
在方法內(nèi)部調(diào)用了LaunchActivityItem的相關(guān)方法，其中關(guān)鍵是LaunchActivityItem#execute(params..)
13-3、LaunchActivityItem#execute(params..)
public void execute(ClientTransactionHandler client, IBinder token,
PendingTransactionActions pendingActions) {
Trace.traceBegin(TRACE_TAG_ACTIVITY_MANAGER, "activityStart");
//實(shí)例化一個(gè)ActivityClientRecord
ActivityClientRecord r = new ActivityClientRecord(token, mIntent, mIdent, mInfo,
mOverrideConfig, mCompatInfo, mReferrer, mVoiceInteractor, mState, mPersistentState,
mPendingResults, mPendingNewIntents, mIsForward,
mProfilerInfo, client);
//實(shí)際上調(diào)用的是ActivityThread的handleLaunchActivity方法
client.handleLaunchActivity(r, pendingActions, null /* customIntent */);
Trace.traceEnd(TRACE_TAG_ACTIVITY_MANAGER);
}
這里的ClientTransactionHandler是ActivityThread的父類，而ActivityThread重寫(xiě)了該方法，因此我們到ActivityThread尋找該方法。
13-4、ActivityThread#handleLaunchActivity(params..)
public Activity handleLaunchActivity(ActivityClientRecord r,
PendingTransactionActions pendingActions, Intent customIntent) {
//....
final Activity a = performLaunchActivity(r, customIntent);
//...
return a;
}
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
//省略部分代碼..
ActivityInfo aInfo = r.activityInfo;
ContextImpl appContext = createBaseContextForActivity(r); //創(chuàng)建Context
Activity activity = null;
try {
java.lang.ClassLoader cl = appContext.getClassLoader();
activity = mInstrumentation.newActivity(
cl, component.getClassName(), r.intent); //創(chuàng)建一個(gè)新的Activity
StrictMode.incrementExpectedActivityCount(activity.getClass());
r.intent.setExtrasClassLoader(cl);
r.intent.prepareToEnterProcess();
if (r.state != null) {
r.state.setClassLoader(cl);
}
}
try {
Application app = r.packageInfo.makeApplication(false, mInstrumentation);
if (activity != null) {
appContext.setOuterContext(activity);
//activity綁定application
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);
if (r.isPersistable()) {
//前面創(chuàng)建了Activity，接下來(lái)觸發(fā)它的生命周期方法
mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);
} else {
mInstrumentation.callActivityOnCreate(activity, r.state);
}
r.activity = activity;
}
r.setState(ON_CREATE); //設(shè)置Activity此時(shí)的狀態(tài)為onCreate
mActivities.put(r.token, r);
return activity;
}
經(jīng)過(guò)一系列的創(chuàng)建、初始化過(guò)程，終于到了Instrumentation#callActivityOnCreate(params..)，顯然，這里就是觸發(fā)Activity生命周期方法的地方了。
13-5、Instrumentation#callActivityOnCreate(params..)
public void callActivityOnCreate(Activity activity, Bundle icicle) {
prePerformCreate(activity);
activity.performCreate(icicle);
postPerformCreate(activity);
}
沒(méi)什么好說(shuō)的，下一步就是Activity#performCreate(bundle)：
final void performCreate(Bundle icicle) {
performCreate(icicle, null);
}
final void performCreate(Bundle icicle, PersistableBundle persistentState) {
mCanEnterPictureInPicture = true;
restoreHasCurrentPermissionRequest(icicle);
if (persistentState != null) {
onCreate(icicle, persistentState);
} else {
onCreate(icicle); //onCreate()生命周期方法調(diào)用
}
writeEventLog(LOG_AM_ON_CREATE_CALLED, "performCreate");
mActivityTransitionState.readState(icicle);
mVisibleFromClient = !mWindow.getWindowStyle().getBoolean(
com.android.internal.R.styleable.Window_windowNoDisplay, false);
mFragments.dispatchActivityCreated(); //告訴Fragment分發(fā)create事件
mActivityTransitionState.setEnterActivityOptions(this, getActivityOptions());
}
最后，終于來(lái)到了Activity#onCreate()方法，也這就是我們應(yīng)用Activity默認(rèn)重寫(xiě)的一個(gè)方法。到了這一步，一個(gè)Activity終于真正地創(chuàng)建、啟動(dòng)成功了。但還沒(méi)有完成，因?yàn)槲覀兊哪繕?biāo)狀態(tài)是resumed，所以我們還要把Activity的狀態(tài)逐步切換到onResume狀態(tài)。
讓我們回到代碼13-1的executeLifecycleState(transaction)，這個(gè)方法讀者應(yīng)該也是熟悉的了，因?yàn)樵谔幚?code>pause狀態(tài)時(shí)也曾經(jīng)遇到過(guò)了。那么接下來(lái)的邏輯就顯而易見(jiàn)了，具體的邏輯就在代碼7-2處，只不過(guò)現(xiàn)在的狀態(tài)路徑變成了：onStart和onResume，也就是會(huì)分別調(diào)用ActivityThread#handleStartActivity和ActivityThread#handleResumeActivity；接著進(jìn)一步調(diào)用到Activity#performStart()和Activity#performResume()。最后，我們熟悉的生命周期方法onStart()和onResume()都會(huì)得到調(diào)用。
本文到這里就告一段落了，整篇文章很長(zhǎng)，為耐心看到這里的你點(diǎn)贊~希望這篇文章能對(duì)您有所裨益，謝謝閱讀！
