如今咱們來梳理下 Android 系統的啓動過程。Android 啓動過程仍是比較重要的,由於在這個過程當中除了要完成 Linux 系統的初始化工做還要完成 Android 的基礎服務和啓動界面的初始化工做。java
在這篇文章中,咱們不打算過多深刻源碼。由於 Android 中任何一個功能模塊在 Framework 層都涉及大量的代碼調用。過多深刻源碼只會讓咱們迷失在一層層的調用棧中。相比之下,我更傾向於只出一些核心代碼,另外梳理下調用棧的流程。當咱們須要深刻研究這方面的內容的時候,知道去哪裏找答案就夠了。android
按下電源以後,首先加載引導程序 BootLoader 到 RAM;而後,執行引導程序 BootLoader 以把系統 OS 拉起來;接着,啓動 Linux 內核;內核中啓動的第一個用戶進程是 init 進程,init 進程會經過解析 init.rc 來啓動 zygote 服務;Zygote 又會進一步的啓動 SystemServer;在 SystemServer 中,Android 會啓動一系列的系統服務供用戶調用。c++
Android 系統中 init 程序對應的 Android.mk
位於 system/core/init/Android.mk
,是一種 Makefile 文件,用來向編譯系統描述咱們的源代碼。咱們可使用 make 工具來執行該文件。因此,mk 文件就像是 Shell 腳本同樣。git
Linux 內核加載完成後,首先啓動 init 進程。在 8.0 的源碼中系統啓動的第一個階段是建立啓動所需的各類目錄。而在最新的源碼中,這部分代碼被包含在了 init_first_stage
中:github
// 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 不會改變。bash
而後是 init.cpp
進程的入口函數 main:app
// 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
等對象。socket
打開該文件咱們能夠看到其中包含了下面兩行代碼,這裏使用了佔位符,也就是說,它會根據當前的環境變量加載當前目錄下對應的文件。而且,咱們能夠看到在 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()
方法。
根據上面的分析,系統已經啓動了虛擬機。而且在虛擬機啓動完成以後,程序進入了 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》
系統啓動過程當中必不可少的一個環節就是啓動 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 啓動的時候來繼續梳理。
上面咱們梳理了 Android 系統啓動的主流程,這裏咱們總結一下。