Android系統的啓動流程
Android系統的啓動流程可以分三部分來分析,
Android系統有哪些主要的系統進程?
這些系統進程是怎麼啓動的?
啓動之後都做了什麼事?
首先看下圖,分三個階段介紹Android系統的啓動流程:
第一階段:Android設備上電後,首先會從處理器芯片上ROM的啓動引導代碼開始執行,芯片上ROM會尋找Bootloader代碼,並加載到內存。(這一步由“芯片廠商”負責設計和實現)
第二階段:Bootloader開始執行,首先負責完成硬件的初始化,然後找到Linux內核代碼,並加載到內存。(這一步由“設備廠商”負責設計和實現)
第三階段:Linux內核開始啓動,初始化各種軟硬件環境,加載驅動程序,掛載根文件系統,並執行init程序,由此開啓Android的世界。(這一步則是Android內核開發過程中需要涉及的地方)
Android系統以及各大Linux的發行版,他們的Linux內核部分啓動過程都是差不多的,他們之間最大的區別就在於init程序的不同,因爲init程序決定了系統在啓動過程中,究竟會啓動哪些守護進程和服務,以及呈現出怎樣的一個用戶UI界面。
因此,init程序是分析Android啓動過程中最核心的程序。
對應的代碼位於:system/core/init/init.c,
init程序最核心的工作主要有三點:
(1) 創建和掛載一些系統目錄/設備節點,設置權限,如:/dev, /proc, and /sys。
(2) 解析 init.rc 和 init..rc,並啓動屬性服務,以及一系列的服務和進程。
(3) 顯示boot logo,默認是“Android”字樣。
其中,最重要的步驟是第二步,一系列的Android服務在這時被啓動起來,其實Android系統的啓動最重要的過程也就是各個系統服務的啓動,因爲系統所有的功能都是依賴這些服務來完成的,比如啓動應用程序,撥打電話,使用WIFI或者藍牙,播放音視頻等等,只要這些服務都能正常地啓動起來並且正常工作,整個Android系統也就完成了自己的啓動。
這些服務包含兩部分,一部分是本地服務,另一部分是Android系統服務,所有的這些服務都會向ServiceManager進程註冊,由它統一管理,這些服務的啓動過程介紹如下:
(1)本地服務
本地服務是指運行在C++層的系統守護進程,一部分本地服務是init進程直接啓動的,它們定義在init.rc腳本和init..rc中,如 ueventd、servicemanager、debuggerd、rild、mediaserver等。還有一部分本地服務,是由這些本地服務進一步創建的,如mediaserver服務會啓動AudioFlinger, MediaPlayerService, 以及 CameraService 等本地服務。
我們可以通過查看init.rc和init..rc文件找出具體有哪些本地服務被init進程直接啓動了,這些文件的位置:system/core/rootdir/ 或者在各服務模塊的根目錄下,其在rc腳本文件的配置如下:
service zygote /system/bin/app_process
service servicemanager /system/bin/servicemanager
service surfacelinger /system/bin/surfaceflinger
service media /system/bin/mediaserver
注意,每一個由init直接啓動的本地服務都是一個獨立的Linux進程,在系統啓動以後,我們通過adb shell ps命令,可以查看所有進程信息。
(2)Android的系統服務
Android的系統服務是指運行在Dalvik虛擬機進程中的服務,這些服務的創建過程描述如下:
init進程會執行app_process程序,創建Zygote進程,它是Android系統最重要的進程,所有後續的Android應用程序都是由它fork出來的。
Zygote進程會首先fork出"SystemServer"進程,"SystemServer"進程的全部任務就是將所有的Android核心服務啓動起來,這些服務包括:
當所有的服務都啓動完畢後,SystemServer會打印出“Making services ready”,然後通過ActivityManager啓動Home界面,併發送“ACTION_BOOT_COMPLETED”廣播消息。
注意,這些Android的系統服務並沒有各自運行在獨立的進程中,它們由SystemServer以線程的方式創建,所以都運行在同一個進程中,即SystemServer進程中。
(3)詳細分析Zygote進程和SystemServer進程的啓動
Zygote的啓動流程:
init進程fork出zyogte進程
啓動虛擬機,註冊jni函數,爲進入java層做準備
預加載系統資源,如系統主題資源,類等
啓動system server,非常重要,裏面跑了很多系統服務
進入socket Loop,不斷接受socket消息並處理
zygote工作流程:
啓動的最後,進入了socket loop循環,有消息進入runOnce()函數,如下:
boolean runOnce() throws ZygoteInit.MethodAndArgsCaller {
String[] args = readArgumentList(); //讀取參數列表
int pid = Zygote.forkAndSpecialize(parsedArgs.uid, parsedArgs.gid, parsedArgs.gids,
parsedArgs.debugFlags, rlimits, parsedArgs.mountExternal, parsedArgs.seInfo,
parsedArgs.niceName, fdsToClose, parsedArgs.instructionSet,
parsedArgs.appDataDir);; //根據參數啓動子進程
if(pid == 0){
//in child
handleChildProc(args, ...);
//在子進程裏面幹活,其實執行的就是java類得main函數(入口函數),java類名來自上面讀取的參數列表。
//參數列表是AMS跨進程發過來的,類名就是ActivityThread.main(),
//也就是說,應用程序進程執行後會馬上執行ActivityThread.main()函數
return true;
}
}
system_server的啓動流程:
private static boolean startSystemServer(String abiList, String socketName)
throws MethodAndArgsCaller, RuntimeException {
long capabilities = posixCapabilitiesAsBits(
OsConstants.CAP_IPC_LOCK,
OsConstants.CAP_KILL,
OsConstants.CAP_NET_ADMIN,
OsConstants.CAP_NET_BIND_SERVICE,
OsConstants.CAP_NET_BROADCAST,
OsConstants.CAP_NET_RAW,
OsConstants.CAP_SYS_MODULE,
OsConstants.CAP_SYS_NICE,
OsConstants.CAP_SYS_PTRACE,
OsConstants.CAP_SYS_TIME,
OsConstants.CAP_SYS_TTY_CONFIG
);
/* Containers run without this capability, so avoid setting it in that case */
if (!SystemProperties.getBoolean(PROPERTY_RUNNING_IN_CONTAINER, false)) {
capabilities |= posixCapabilitiesAsBits(OsConstants.CAP_BLOCK_SUSPEND);
}
/* Hardcoded command line to start the system server */
String args[] = {
"--setuid=1000",
"--setgid=1000",
"--setgroups=1001,1002,1003,1004,1005,1006,1007,1008,1009,1010,1018,1021,1032,3001,3002,3003,3006,3007,3009,3010",
"--capabilities=" + capabilities + "," + capabilities,
"--nice-name=system_server",
"--runtime-args",
"com.android.server.SystemServer",
};
ZygoteConnection.Arguments parsedArgs = null;
int pid;
try {
parsedArgs = new ZygoteConnection.Arguments(args);
ZygoteConnection.applyDebuggerSystemProperty(parsedArgs);
ZygoteConnection.applyInvokeWithSystemProperty(parsedArgs);
/* Request to fork the system server process */
pid = Zygote.forkSystemServer(
parsedArgs.uid, parsedArgs.gid,
parsedArgs.gids,
parsedArgs.debugFlags,
null,
parsedArgs.permittedCapabilities,
parsedArgs.effectiveCapabilities);
//創建system_server進程,zygote fork出來
} catch (IllegalArgumentException ex) {
throw new RuntimeException(ex);
}
/* For child process */
if (pid == 0) {
if (hasSecondZygote(abiList)) {
waitForSecondaryZygote(socketName);
}
//子進程,走進system_server啓動的具體邏輯了
handleSystemServerProcess(parsedArgs);
}
return true;
}
private static void handleSystemServerProcess(
ZygoteConnection.Arguments parsedArgs)
throws ZygoteInit.MethodAndArgsCaller {
closeServerSocket();
// set umask to 0077 so new files and directories will default to owner-only permissions.
Os.umask(S_IRWXG | S_IRWXO);
if (parsedArgs.niceName != null) {
Process.setArgV0(parsedArgs.niceName);
}
final String systemServerClasspath = Os.getenv("SYSTEMSERVERCLASSPATH");
if (systemServerClasspath != null) {
performSystemServerDexOpt(systemServerClasspath);
}
if (parsedArgs.invokeWith != null) {
String[] args = parsedArgs.remainingArgs;
// If we have a non-null system server class path, we'll have to duplicate the
// existing arguments and append the classpath to it. ART will handle the classpath
// correctly when we exec a new process.
if (systemServerClasspath != null) {
String[] amendedArgs = new String[args.length + 2];
amendedArgs[0] = "-cp";
amendedArgs[1] = systemServerClasspath;
System.arraycopy(parsedArgs.remainingArgs, 0, amendedArgs, 2, parsedArgs.remainingArgs.length);
}
WrapperInit.execApplication(parsedArgs.invokeWith,
parsedArgs.niceName, parsedArgs.targetSdkVersion,
VMRuntime.getCurrentInstructionSet(), null, args);
} else {
ClassLoader cl = null;
if (systemServerClasspath != null) {
cl = createSystemServerClassLoader(systemServerClasspath,
parsedArgs.targetSdkVersion);
Thread.currentThread().setContextClassLoader(cl);
}
/*
* Pass the remaining arguments to SystemServer.
*/
RuntimeInit.zygoteInit(parsedArgs.targetSdkVersion, parsedArgs.remainingArgs, cl);
}
/* should never reach here */
}
RuntimeInit中的zygoteInit:
//初始化分三步
public static final void zygoteInit(int targetSdkVersion, String[] argv, ClassLoader classLoader)
throws ZygoteInit.MethodAndArgsCaller {
if (DEBUG) Slog.d(TAG, "RuntimeInit: Starting application from zygote");
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "RuntimeInit");
redirectLogStreams();
commonInit();//通用化初始化
nativeZygoteInit();//jni調用底層app_main.cpp中的onZygoteInit方法
applicationInit(targetSdkVersion, argv, classLoader);
}
//nativeZygoteInit(),這裏啓動了binder機制,binder線程,因爲system_server裏很多系統服務需要和其他進程通信
//如跟應用進程通訊,或者和service manager進程通信
virtual void onZygoteInit(){
sp<ProcessState> proc = ProcessState::self();
proc->startThreadPool();
}
private static void applicationInit(int targetSdkVersion, String[] argv, ClassLoader classLoader)
throws ZygoteInit.MethodAndArgsCaller {
// If the application calls System.exit(), terminate the process
// immediately without running any shutdown hooks. It is not possible to
// shutdown an Android application gracefully. Among other things, the
// Android runtime shutdown hooks close the Binder driver, which can cause
// leftover running threads to crash before the process actually exits.
nativeSetExitWithoutCleanup(true);
// We want to be fairly aggressive about heap utilization, to avoid
// holding on to a lot of memory that isn't needed.
VMRuntime.getRuntime().setTargetHeapUtilization(0.75f);
VMRuntime.getRuntime().setTargetSdkVersion(targetSdkVersion);
final Arguments args;
try {
args = new Arguments(argv);
} catch (IllegalArgumentException ex) {
Slog.e(TAG, ex.getMessage());
// let the process exit
return;
}
// The end of of the RuntimeInit event (see #zygoteInit).
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
// Remaining arguments are passed to the start class's static main
invokeStaticMain(args.startClass, args.startArgs, classLoader);
//調用java類的入口函數,就是system server的java類
}
//SystemServer的類的main函數
public static void main(String[] args){
new SystemServer().run(); //new了一個SystemServer對象,執行了它的run函數
}
private void run(){
Looper.prepareMainLooper(); //爲主線程創建Looper
System.loadLibrary("android_servers"); //加載共享庫,就是system server裏的系統服務的native 層的代碼,都在共享庫
createSystemContext(); //創建系統上下文,system server可以看成是應用進程,因爲它也有context,application,Activity thread
//系統服務分3批次,分別啓動
startBootstrapServices();
startCoreServices();
startOtherServices();
//不管這個loop是不是真的在處理消息,但這個主線程不可以退出,主線程退出進程就退出了
Looper.loop();
}
(4)問題思考
1. 系統服務怎麼發佈?
//就是系統服務把binder註冊到ServiceManager裏面,統一管理
void publishBinderService(String name, IBinder service){
publishBinderService(name, service, false);
}
void publishBinderService(String name, IBinder service,...){
ServiceManager.addService(name, service, allowlsolated);
}
2. 系統服務跑在什麼線程?
有的系統服務有自己的工作線程,例如AMS、PMS 等。
還有大家共用的工作線程:DisplayThread, FgTHread, IoThread, UiThread。
DisplayThread是顯示用的
FgThread是前臺任務
IoThread是Io任務
UiThread是Ui顯示的,UiThread並不是主線程,而是一個子線程,所以說明UI的刷新不必一定在主線程,子線程也行。
這些工作線程系統服務都會跑,當然還有binder線程,因爲應用跨進程調過來肯定先在binder線程裏面。
3. 爲什麼系統服務不都跑在binder線程?
binder線程是大家一起共享的,如果系統負載很重,binder線程池忙碌,可能影響系統服務響應的實時性,另外如果任務太耗時,長時間佔用binder線程也不妥。
4. 爲什麼系統服務不都跑在自己私有的工作線程?
不可能每個服務都啓動一個工作線程,一共上百個系統服務,線程開太多了會內存溢出的。而且太多線程之間切換對性能不利。
5. 跑在binder線程和跑在工作線程,如何取捨?
總的來說,對於實時性要求不那麼高,並且處理起來不太耗時的任務可以就放在binder線程裏。另外啓動工作線程也可以避免同步的問題,因爲應用程序跨進程調用過來是在binder線程池,通過切到工作線程可以讓binder調用序列化,不用到處上鎖。
6. 怎麼解決系統服務啓動的互相依賴?
例如system_server進程裏,系統服務有上百個,解決複雜的依賴關係並不容易:
1)分批次啓動,基礎的先啓動,例如AMS PMS PKMS,很多service都依賴於他們所以要先啓動。
2)分階段啓動,通知已啓動的service到了什麼階段,哪些資源可以用了,這些service就可以做這個階段可以做的初始化了。
7. 桌面的啓動
AMS服務就緒時會調用systemReady函數,裏面會啓動桌面:
public void systemReady(final Runnable goingCallback){
...
startHomeActivityLocked(mCurrentUserId, "systemReady");
...
}
桌面可以看成單獨的系統級應用,這裏只啓動了桌面的Activity,Activity的onCreate裏面會啓動LoaderTask:
mLoaderTask = new LoaderTask(mApp.getContext(), loadFlags);
//loaderTask會向packageManagerService查詢所有當前已經安裝的應用,把圖標顯示到桌面上,點擊圖標,就會啓動應用的LauncherActivity
mPm.queryIntentActivitiesAsUser