現在我們來梳理下 Android 系統的啟動過程。Android 啟動過程還是比較重要的，因為在這個過程中除了要完成 Linux 系統的初始化工作還要完成 Android 的基礎服務和啟動界面的初始化工作。
在這篇文章中，我們不打算過多深入源碼。因為 Android 中任何一個功能子產品在 Framework 層都涉及大量的代碼調用。過多深入源碼隻會讓我們迷失在一層層的調用棧中。相比之下，我更傾向于隻出一些核心代碼，另外梳理下調用棧的流程。當我們需要深入研究這方面的内容的時候，知道去哪裡找答案就夠了。
1、系統啟動
按下電源之後，首先加載引導程式 BootLoader 到 RAM；然後，執行引導程式 BootLoader 以把系統 OS 拉起來；接着，啟動 Linux 核心；核心中啟動的第一個使用者程序是 init 程序，init 程序會通過解析 init.rc 來啟動 zygote 服務；Zygote 又會進一步的啟動 SystemServer；在 SystemServer 中，Android 會啟動一系列的系統服務供使用者調用。
Android 系統中 init 程式對應的
Android.mk
位于
system/core/init/Android.mk
，是一種 Makefile 檔案，用來向編譯系統描述我們的源代碼。我們可以使用 make 工具來執行該檔案。是以，mk 檔案就像是 Shell 腳本一樣。
1.1 執行 init 程式
Linux 核心加載完成後，首先啟動 init 程序。在 8.0 的源碼中系統啟動的第一個階段是建立啟動所需的各種目錄。而在最新的源碼中，這部分代碼被包含在了
init_first_stage
中：
// platform/system/core/init/init_first_stage.cpp
int main(int argc, char** argv) {
if (REBOOT_BOOTLOADER_ON_PANIC) {
InstallRebootSignalHandlers();
}
boot_clock::time_point start_time = boot_clock::now();
std::vector<std::pair<std::string, int>> errors;
#define CHECKCALL(x) \
if (x != 0) errors.emplace_back(#x " failed", errno);
umask(0);
CHECKCALL(clearenv());
CHECKCALL(setenv("PATH", _PATH_DEFPATH, 1));
// 建立目錄
CHECKCALL(mount("tmpfs", "/dev", "tmpfs", MS_NOSUID, "mode=0755"));
CHECKCALL(mkdir("/dev/pts", 0755));
CHECKCALL(mkdir("/dev/socket", 0755));
// ...
#undef CHECKCALL
auto reboot_bootloader = [](const char*) { RebootSystem(ANDROID_RB_RESTART2, "bootloader"); };
InitKernelLogging(argv, reboot_bootloader);
// ...
const char* path = "/system/bin/init";
const char* args[] = {path, nullptr};
execv(path, const_cast<char**>(args));
return 1;
}
在系統啟動過程中會多次調用
execv()
，每次調用該方法時會重新執行 main() 方法。該方法如下：
int execv(const char *progname, char *const argv[]); //#include <unistd.h>
execv() 會停止執行目前的程序，并且以 progname 應用程序替換被停止執行的程序，程序 ID 不會改變。
然後是
init.cpp
程序的入口函數 main:
// platform/system/core/init/init.cpp
int main(int argc, char** argv) {
if (!strcmp(basename(argv[0]), "ueventd")) {
return ueventd_main(argc, argv);
}
if (argc > 1 && !strcmp(argv[1], "subcontext")) {
android::base::InitLogging(argv, &android::base::KernelLogger);
const BuiltinFunctionMap function_map;
return SubcontextMain(argc, argv, &function_map);
}
if (REBOOT_BOOTLOADER_ON_PANIC) {
// 初始化重新開機系統的處理信号
InstallRebootSignalHandlers();
}
// ...
property_init(); // 初始化屬性服務
// ...
Epoll epoll; // 建立 epoll 句柄
if (auto result = epoll.Open(); !result) {
PLOG(FATAL) << result.error();
}
InstallSignalFdHandler(&epoll);
// ...
StartPropertyService(&epoll); // 啟動屬性服務
// ...
ActionManager& am = ActionManager::GetInstance();
ServiceList& sm = ServiceList::GetInstance();
LoadBootScripts(am, sm); // 加載啟動腳本
// ...
// 充電模式不啟動系統，否則啟動系統
std::string bootmode = GetProperty("ro.bootmode", "");
if (bootmode == "charger") {
am.QueueEventTrigger("charger");
} else {
am.QueueEventTrigger("late-init");
}
// ...
return 0;
}
這裡會在
LoadBootScripts()
方法中解析
init.rc
檔案。關于該檔案指令的含義可以參考 AOSP 中的文檔：《Android Init Language》. 完成解析相關的類是
ActionManager
、
Parser
和
XXParser
，均位于
system/core/init
目錄下面。除此之外，還有
Action
和
Service
等類。它們的作用是，各種
Parser
用來解析 rc 檔案中的指令。解析出的指令會被封裝成
Action
和
Service
等對象。
打開該檔案我們可以看到其中包含了下面兩行代碼，這裡使用了占位符，也就是說，它會根據目前的環境變量加載目前目錄下對應的檔案。并且，我們可以看到在
system/core/rootdir
目錄下面确實存在着
init.zygote64.rc
和
init.zygote32.rc
等檔案。
import /init.${ro.hardware}.rc
import /init.${ro.zygote}.rc
以
rinit.zygote64.rc
為例，它表示通知 init 程序建立名為 zygote 的程序。執行路徑是
/system/bin/app_process64
，
// platform/system/core/rootdir/init.zygote64.rc
service zygote /system/bin/app_process64 -Xzygote /system/bin --zygote --start-system-server
class main
// ...
我們可以看出它使用了 service 指令，是以它将被解析成 Service.
注意到在
init.cpp
的 main() 方法的最後，如果非充電模式将觸發
late-init
. 在
rc
中配置了對
late-init
事件的監聽，通過
on
來實作的。同時，它又使用
trigger
觸發了其他的指令。這些指令也都是通過
on
來監聽的。（當然，rc 隻是一種配置檔案，而實際的邏輯是被解析之後在程式中完成的。）
在
late-init
事件觸發的事件當中包含了
zygote-start
事件. 而
zygote-start
監聽實作又根據監聽條件又多種。不過，它們都會調用
start zygote
方法。這裡的 start 會被映射到 builtins 類的
do_start()
方法。該方法會調用 Service 的
start()
方法。該方法主要是調用 clone 或 fork 建立子程序，然後調用 execve 執行配置的二進制檔案，另外根據之前在 rc 檔案中的配置，去執行這些配置。是以程式将開始執行 app_process64.
// platform/system/core/init/service.cpp
Result<Success> Service::Start() {
// ...
pid_t pid = -1;
if (namespace_flags_) {
pid = clone(nullptr, nullptr, namespace_flags_ | SIGCHLD, nullptr);
} else {
pid = fork();
}
if (pid == 0) {
umask(077);
// ...
// 内部調用 execv() 來執行
if (!ExpandArgsAndExecv(args_, sigstop_)) {
PLOG(ERROR) << "cannot execve('" << args_[0] << "')";
}
_exit(127);
}
// ...
return Success();
}
映射關系參考源碼：system/core/init/builtins.cpp
關于 rc 檔案的指令的解析，可以參考《Android 8.0 系統啟動流程之init.rc解析與service流程(七)》
上述 rc 檔案的
/system/bin/app_process64
對應的 mk 檔案位于
/base/cmds/app_process/Android.mk
目錄下面。從該檔案中我們可以看出，不論 app_process、app_process32 還是 app_process64，對應的源檔案都是
app_main.cpp
. 于是程式将進入
app_main.cpp
的 main() 方法。
進入 main() 方法之後先要進行指令的參數的解析，
// platform/frameworks/base/cmds/app_process/app_main.cpp
int main(int argc, char* const argv[])
{
// ...
bool zygote = false;
bool startSystemServer = false;
bool application = false;
String8 niceName;
String8 className;
++i; // Skip unused "parent dir" argument.
while (i < argc) {
const char* arg = argv[i++];
if (strcmp(arg, "--zygote") == 0) {
zygote = true;
niceName = ZYGOTE_NICE_NAME;
} else if (strcmp(arg, "--start-system-server") == 0) {
startSystemServer = true;
} else if (strcmp(arg, "--application") == 0) {
application = true;
} else if (strncmp(arg, "--nice-name=", 12) == 0) {
niceName.setTo(arg + 12);
} else if (strncmp(arg, "--", 2) != 0) {
className.setTo(arg);
break;
} else {
--i;
break;
}
}
// ...
if (zygote) {
runtime.start("com.android.internal.os.ZygoteInit", args, zygote);
} else if (className) {
runtime.start("com.android.internal.os.RuntimeInit", args, zygote);
} else {
app_usage();
}
}
我們從之前的 rc 檔案中可以看出，參數為
--zygote
，是以将調用
ZygoteInit
的 main() 方法繼續執行。這裡的 runtime 是
AndroidRuntime
，這裡的
start()
方法是一種 JNI 調用。這裡将會調用 Java 中的靜态 main() 方法繼續執行。 這種調用方式還是比較重要的，我們經常在 Java 中調用 C++ 的方法，而這裡是在 C++ 中調用 Java 的方法。它的源碼位于
base\core\jni\AndroidRuntime.cpp
.
// platform/frameworks/base/core/jni/AndroidRuntime.cpp
void AndroidRuntime::start(const char* className, const Vector<String8>& options, bool zygote)
{
// ...
// 擷取ANDROID_ROOT環境變量
const char* rootDir = getenv("ANDROID_ROOT");
if (rootDir == NULL) {
rootDir = "/system";
if (!hasDir("/system")) {
return;
}
setenv("ANDROID_ROOT", rootDir, 1);
}
// 啟動虛拟機
JniInvocation jni_invocation;
jni_invocation.Init(NULL);
JNIEnv* env;
if (startVm(&mJavaVM, &env, zygote) != 0) {
return;
}
onVmCreated(env);
// ... 解析 main 函數以在下面進行觸發
// 啟動線程，目前線程将會變成虛拟機的主線程，并且直到虛拟機退出的時候才結束。
char* slashClassName = toSlashClassName(className != NULL ? className : "");
jclass startClass = env->FindClass(slashClassName);
if (startClass == NULL) {
ALOGE("JavaVM unable to locate class '%s'\n", slashClassName);
} else {
jmethodID startMeth = env->GetStaticMethodID(startClass, "main",
"([Ljava/lang/String;)V");
if (startMeth == NULL) {
ALOGE("JavaVM unable to find main() in '%s'\n", className);
} else {
env->CallStaticVoidMethod(startClass, startMeth, strArray);
}
}
// ...
}
在上面的方法中，我們可以看出啟動虛拟機的時候需要調用
startVM()
方法來啟動。當虛拟機啟動完成之後使用句柄函數 env 來執行 ZygoteInit 的靜态
main()
方法。
1.2 啟動 Zygote
根據上面的分析，系統已經啟動了虛拟機。并且在虛拟機啟動完成之後，程式進入了
ZygoteInit
中
main()
方法中，
// platform/framework/base/core/java/com/android/internal/os/ZygoteInit.java
public static void main(String argv[]) {
// ...
try {
// ...
boolean startSystemServer = false;
String socketName = "zygote";
String abiList = null;
boolean enableLazyPreload = false;
for (int i = 1; i < argv.length; i++) {
if ("start-system-server".equals(argv[i])) {
startSystemServer = true;
} else if ("--enable-lazy-preload".equals(argv[i])) {
enableLazyPreload = true;
} else if (argv[i].startsWith(ABI_LIST_ARG)) {
abiList = argv[i].substring(ABI_LIST_ARG.length());
} else if (argv[i].startsWith(SOCKET_NAME_ARG)) {
socketName = argv[i].substring(SOCKET_NAME_ARG.length());
} else {
throw new RuntimeException("Unknown command line argument: " + argv[i]);
}
}
// 注冊名為 zygote 的 Socket
zygoteServer.registerServerSocketFromEnv(socketName);
// 決定是否進行資源的預加載
if (!enableLazyPreload) {
// ... 記錄日志資訊
preload(bootTimingsTraceLog);
// ... 記錄日志資訊
} else {
Zygote.resetNicePriority();
}
gcAndFinalize(); // 進行 GC 清理空間
// ...
if (startSystemServer) {
// 啟動 SystemServer 程序，如果 r 為 null 則處于父程序，否則是子程序
Runnable r = forkSystemServer(abiList, socketName, zygoteServer);
if (r != null) {
r.run();
return;
}
}
// 等待 AMS 連接配接請求
caller = zygoteServer.runSelectLoop(abiList);
} catch (Throwable ex) {
throw ex;
} finally {
zygoteServer.closeServerSocket();
}
if (caller != null) {
caller.run();
}
}
這裡主要做了幾件事情：
首先，建立 Server 端的 Socket. 這裡建立的是 ZygoteServer 對象。它提供了等待 UNIX 套接字的指令，并且提供了 fork 虛拟機的方法。
然後，進行資源預加載。
接着，啟動 SystemServer. 這裡通過調用 forkSystemServer() 來進行。這裡先會建構一個指令參數，然後調用 Zygote 的靜态方法來 Fork 一個子程序。該方法内部又會調用 JNI 層的
nativeForkSystemServer
方法最終完成 Fork 操作。
// platform/framework/base/core/java/com/android/internal/os/Zygote.java
private static Runnable forkSystemServer(String abiList, String socketName, ZygoteServer zygoteServer) {
// ...
/* 寫死的指令行來啟動 System Server */
String args[] = {
"--setuid=1000",
"--setgid=1000",
"--setgroups=1001,1002,1003,1004,1005,1006,1007,1008,1009,1010,1018,1021,1023,1024,1032,1065,3001,3002,3003,3006,3007,3009,3010",
"--capabilities=" + capabilities + "," + capabilities,
"--nice-name=system_server",
"--runtime-args",
"--target-sdk-version=" + VMRuntime.SDK_VERSION_CUR_DEVELOPMENT,
"com.android.server.SystemServer",
};
ZygoteConnection.Arguments parsedArgs = null;
int pid;
try {
parsedArgs = new ZygoteConnection.Arguments(args);
ZygoteConnection.applyDebuggerSystemProperty(parsedArgs);
ZygoteConnection.applyInvokeWithSystemProperty(parsedArgs);
boolean profileSystemServer = SystemProperties.getBoolean(
"dalvik.vm.profilesystemserver", false);
if (profileSystemServer) {
parsedArgs.runtimeFlags |= Zygote.PROFILE_SYSTEM_SERVER;
}
/* 請求 fork System Server 程序 */
pid = Zygote.forkSystemServer(
parsedArgs.uid, parsedArgs.gid,
parsedArgs.gids,
parsedArgs.runtimeFlags,
null,
parsedArgs.permittedCapabilities,
parsedArgs.effectiveCapabilities);
} catch (IllegalArgumentException ex) {
throw new RuntimeException(ex);
}
/* 對于子進行進行處理 */
if (pid == 0) {
if (hasSecondZygote(abiList)) {
waitForSecondaryZygote(socketName);
}
zygoteServer.closeServerSocket();
// 為新 fork 的 system server 程序停止剩下的工作
return handleSystemServerProcess(parsedArgs);
}
return null;
}
最後啟動 select 循環，等待新的連接配接。下面是這個方法的定義，代碼中的注釋已經比較全了，我們就不多解釋了。
// platform/framework/base/core/java/com/android/internal/os/ZygoteServer.java
Runnable runSelectLoop(String abiList) {
// ...
while (true) { // 使用無限循環進行監聽
// ...
for (int i = pollFds.length - 1; i >= 0; --i) {
if ((pollFds[i].revents & POLLIN) == 0) {
continue;
}
if (i == 0) { // 周遊到最後一個
ZygoteConnection newPeer = acceptCommandPeer(abiList);
peers.add(newPeer);
fds.add(newPeer.getFileDesciptor());
} else { // 正在等待連接配接
try {
ZygoteConnection connection = peers.get(i);
// processOneCommand() 從指令 socket 中讀取一個指令，如果讀取成功，将會fork子程序，并傳回子程序的 main 方法. 如果是父程序，那麼應該始終傳回 null
final Runnable command = connection.processOneCommand(this);
if (mIsForkChild) {
// 子程序，需要至少一個指令
if (command == null) {
throw new IllegalStateException("command == null");
}
return command;
} else {
// server 程序，不應該存在要執行的指令
if (command != null) {
throw new IllegalStateException("command != null");
}
if (connection.isClosedByPeer()) { // 關閉請求
connection.closeSocket();
peers.remove(i);
fds.remove(i);
}
}
} catch (Exception e) {
if (!mIsForkChild) {
// 中間發生錯誤，關閉請求，告知請求端請求結束
ZygoteConnection conn = peers.remove(i);
conn.closeSocket();
fds.remove(i);
} else {
throw e;
}
} finally {
mIsForkChild = false;
}
}
}
}
}
當使用
acceptCommandPeer()
從 socket 中讀取到了指令之後，會 fork 子程序并傳回一個 Runnable，用來啟動子程序的 main() 方法。這部分邏輯在
acceptCommandPeer()
方法中。它會調用 Zygote 類的靜态方法
forkAndSpecialize()
來建立子程序。（與 SystemServer 程序建立時的靜态方法不同）然後将調用
handleChildProc()
方法傳回用來啟動子程序的 main() 方法。其定義如下，
// platform/framework/base/core/java/com/android/internal/os/ZygoteConnection.java
private Runnable handleChildProc(Arguments parsedArgs, FileDescriptor[] descriptors,
FileDescriptor pipeFd, boolean isZygote) {
// ...
if (parsedArgs.invokeWith != null) {
throw new IllegalStateException("WrapperInit.execApplication unexpectedly returned");
} else {
if (!isZygote) {
return ZygoteInit.zygoteInit(parsedArgs.targetSdkVersion, parsedArgs.remainingArgs,
null /* classLoader */);
} else {
return ZygoteInit.childZygoteInit(parsedArgs.targetSdkVersion,
parsedArgs.remainingArgs, null /* classLoader */);
}
}
}
這裡的 isZygote 的含義是，是否以目前程序的子程序的形式來啟動一個程序，使用
--start-child-zygote
參數來指定。因為目前我們啟動的程序是父 Zygote 程序，是以将會調用
ZygoteInit.zygoteInit()
方法繼續處理。該方法的核心代碼隻有兩行，
// platform/framework/base/core/java/com/android/internal/os/ZygoteInit.java
public static final Runnable zygoteInit(int targetSdkVersion, String[] argv, ClassLoader classLoader) {
// ...
ZygoteInit.nativeZygoteInit();
return RuntimeInit.applicationInit(targetSdkVersion, argv, classLoader);
}
nativeZygoteInit()
是一個 native 方法，用來啟動 Binder 線程池。它對應的 native 方法定義在
AndroidRuntime.cpp
中。這裡的
gCurRuntime
是 AppRumtime，定義在
app_main.cpp
中。
// platform/frameworks/base/cmds/app_process/app_main.cpp
static void com_android_internal_os_ZygoteInit_nativeZygoteInit(JNIEnv* env, jobject clazz)
{
gCurRuntime->onZygoteInit();
}
applicationInit()
方法主要用來觸發 SystemServer 的 main() 方法。在最新的代碼中，會将要觸發的方法和參數封裝到一個 Runnable 中，并在它的
run()
方法中調用反射觸發方法。是以，我們将進入 SystemServer 的
main()
方法。該類位于
base\services\java\com\android\server
下面。其方法定義如下，
// platform/frameworks/base/service/java/com/android/server/SystemServer.java
public static void main(String[] args) {
new SystemServer().run();
}
// platform/frameworks/base/service/java/com/android/server/SystemServer.java
private void run() {
try {
// ...
Looper.prepareMainLooper(); // 建立主線程消息循環
System.loadLibrary("android_servers"); // 加載 so 庫
performPendingShutdown();
// 建立系統的 context
createSystemContext();
// ServiceManager!!! 用來管理系統服務中的服務的建立、啟動等生命周期
mSystemServiceManager = new SystemServiceManager(mSystemContext);
mSystemServiceManager.setStartInfo(mRuntimeRestart,
mRuntimeStartElapsedTime, mRuntimeStartUptime);
LocalServices.addService(SystemServiceManager.class, mSystemServiceManager);
SystemServerInitThreadPool.get();
} finally {
traceEnd(); // InitBeforeStartServices
}
// 啟動服務
try {
traceBeginAndSlog("StartServices");
startBootstrapServices(); // 啟動引導服務
startCoreServices(); // 啟動核心服務
startOtherServices(); // 啟動其他服務
SystemServerInitThreadPool.shutdown();
} catch (Throwable ex) {
throw ex;
} finally {
traceEnd();
}
// ...
Looper.loop();
throw new RuntimeException("Main thread loop unexpectedly exited");
}
從上面可以看出，這個方法中的主要邏輯是對系統中各種服務進行管理。建立了
SystemServiceManager
之後，借助它來實作對各種服務的建立、啟動等生命周期進行管理。比如在
startBootstrapServices()
中會啟動大名鼎鼎的 PMS 和 AMS 等. 啟動服務的操作是通過調用
SystemServiceManager
的
startService()
方法完成的。該方法有 3 個重載的方法。但是，不論調用哪個方法，最終都會調用到下面的方法。
// platform/frameworks/base/services/core/com/android/server/SystemServiceManager.java
public void startService(@NonNull final SystemService service) {
mServices.add(service);
long time = SystemClock.elapsedRealtime();
try {
service.onStart();
} catch (RuntimeException ex) {
throw new RuntimeException("Failed to start service " + service.getClass().getName()
+ ": onStart threw an exception", ex);
}
}
在該方法中除了回調 service 的
onStart()
之外，還要将其注冊到
mServices
中，它是
ArrayList<SystemService>
類型的變量，用來存儲啟動的服務。
此外，我們還注意到在
run()
方法中啟動了一個 Looper 循環。這表明該系統服務主線程将會一直運作下去。關于 Looper 的内容可以參考我的另一篇文章：
《Android 消息機制：Handler、MessageQueue 和 Looper》
1.3 啟動 Launcher
系統啟動過程中必不可少的一個環節就是啟動 Launcher，就是所謂的 Android 桌面程式。在上面的方法中，系統會啟動所需的各種服務，在其中的
startOtherServices()
方法中，會調用啟動的服務的
systemReady()
方法來做系統啟動準備就緒之後的邏輯。這其中就包括 AMS.
startOtherServices()
方法比較長，我們就不貼代碼了。我們直接看下 AMS 的
systemReady()
方法。這個方法也比較長，我們隻截取其中的一部分方法，
// platform/frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java
public void systemReady(final Runnable goingCallback, TimingsTraceLog traceLog) {
// ...
synchronized (this) {
// ...
startHomeActivityLocked(currentUserId, "`");
// ...
}
}
這裡會調用
startHomeActivityLocked()
方法來繼續操作以完成桌面的啟動，
// platform/frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java
boolean startHomeActivityLocked(int userId, String reason) {
// ...
// 建構一個用于啟動桌面程式的 Intent，這個 Intent 包含一個 Category android.intent.category.HOME 類型的 Cateogry
Intent intent = getHomeIntent();
// 周遊安裝包檢查是否存在 Cateogry 為 android.intent.category.HOME 的 Activity
ActivityInfo aInfo = resolveActivityInfo(intent, STOCK_PM_FLAGS, userId);
if (aInfo != null) {
// 将上述得到的應用資訊傳遞給 Intent
intent.setComponent(new ComponentName(aInfo.applicationInfo.packageName, aInfo.name));
aInfo = new ActivityInfo(aInfo);
aInfo.applicationInfo = getAppInfoForUser(aInfo.applicationInfo, userId);
ProcessRecord app = getProcessRecordLocked(aInfo.processName,
aInfo.applicationInfo.uid, true);
if (app == null || app.instr == null) {
intent.setFlags(intent.getFlags() | FLAG_ACTIVITY_NEW_TASK);
final int resolvedUserId = UserHandle.getUserId(aInfo.applicationInfo.uid);
final String myReason = reason + ":" + userId + ":" + resolvedUserId;
// 繼續啟動 Launcher 的程序
mActivityStartController.startHomeActivity(intent, aInfo, myReason);
}
}
return true;
}
然後方法将進入 ActivityStartController 的
startHomeActivity()
方法繼續進行，
// platform/frameworks/base/services/core/java/com/android/server/am/ActivityStartController.java
void startHomeActivity(Intent intent, ActivityInfo aInfo, String reason) {
// 把 Launcher 的堆棧移到頂部
mSupervisor.moveHomeStackTaskToTop(reason);
// obtainStarter() 将傳回一個 ActivityStarter，然後調用它的 execute() 繼續處理
mLastHomeActivityStartResult = obtainStarter(intent, "startHomeActivity: " + reason)
.setOutActivity(tmpOutRecord)
.setCallingUid(0)
.setActivityInfo(aInfo)
.execute();
mLastHomeActivityStartRecord = tmpOutRecord[0];
if (mSupervisor.inResumeTopActivity) {
mSupervisor.scheduleResumeTopActivities();
}
}
這裡通過
obtainStarter()
将傳回一個 ActivityStarter，然後調用它的 execute() 繼續處理，顯然這裡使用的是建構者設計模式。剩下的流程就是 Activity 的啟動流程。我們不做更多說明了，可以在随後介紹 Activity 啟動的時候來繼續梳理。
2、總結
上面我們梳理了 Android 系統啟動的主流程，這裡我們總結一下。
推薦資料：
- Android 8.0 系統啟動流程之zygote程序(八)
- Android 8.0 系統啟動流程之init.rc解析與service流程(七)
![android SQLite事務和kotlin協程[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)