Android啟動過程深入解析

當按下Android設備電源鍵時究竟發(fā)生了什么？

10多年的麻栗坡網站建設經驗，針對設計、前端、開發(fā)、售后、文案、推廣等六對一服務，響應快，48小時及時工作處理。全網營銷推廣的優(yōu)勢是能夠根據(jù)用戶設備顯示端的尺寸不同，自動調整麻栗坡建站的顯示方式，使網站能夠適用不同顯示終端，在瀏覽器中調整網站的寬度，無論在任何一種瀏覽器上瀏覽網站，都能展現(xiàn)優(yōu)雅布局與設計，從而大程度地提升瀏覽體驗。成都創(chuàng)新互聯(lián)公司從事“麻栗坡網站設計”,“麻栗坡網站推廣”以來，每個客戶項目都認真落實執(zhí)行。

Android的啟動過程是怎么樣的？

什么是Linux內核？

桌面系統(tǒng)linux內核與Android系統(tǒng)linux內核有什么區(qū)別？

什么是引導裝載程序？

什么是Zygote？

什么是X86以及ARM linux？

什么是init.rc?

什么是系統(tǒng)服務？

當我們想到Android啟動過程時，腦海中總是冒出很多疑問。本文將介紹Android的啟動過程，希望能幫助你找到上面這些問題的答案。

Android是一個基于Linux的開源操作系統(tǒng)。x86（x86是一系列的基于intel 8086 CPU的計算機微處理器指令集架構）是linux內核部署最常見的系統(tǒng)。然而，所有的Android設備都是運行在ARM處理器（ARM 源自進階精簡指令集機器，源自ARM架構）上，除了英特爾的Xolo設備()。Xolo來源自凌動1.6GHz x86處理器。Android設備或者嵌入設備或者基于linux的ARM設備的啟動過程與桌面版本相比稍微有些差別。這篇文章中，我將解釋Android設備的啟動過程。深入linux啟動過程是一篇講桌面linux啟動過程的好文。

當你按下電源開關后Android設備執(zhí)行了以下步驟。

此處圖片中step2中的一個單詞拼寫錯了，Boot Loaeder應該為Boot Loader（多謝@jameslast 提醒）

第一步：啟動電源以及系統(tǒng)啟動

當電源按下，引導芯片代碼開始從預定義的地方（固化在ROM）開始執(zhí)行。加載引導程序到RAM，然后執(zhí)行。

第二步：引導程序

引導程序是在Android操作系統(tǒng)開始運行前的一個小程序。引導程序是運行的第一個程序，因此它是針對特定的主板與芯片的。設備制造商要么使用很受歡迎的引導程序比如redboot、uboot、qi bootloader或者開發(fā)自己的引導程序，它不是Android操作系統(tǒng)的一部分。引導程序是OEM廠商或者運營商加鎖和限制的地方。

引導程序分兩個階段執(zhí)行。第一個階段，檢測外部的RAM以及加載對第二階段有用的程序；第二階段，引導程序設置網絡、內存等等。這些對于運行內核是必要的，為了達到特殊的目標，引導程序可以根據(jù)配置參數(shù)或者輸入數(shù)據(jù)設置內核。

Android引導程序可以在bootablebootloaderlegacyusbloader找到。

傳統(tǒng)的加載器包含的個文件，需要在這里說明：

init.s初始化堆棧，清零BBS段，調用main.c的_main()函數(shù)；

main.c初始化硬件（鬧鐘、主板、鍵盤、控制臺），創(chuàng)建linux標簽。

更多關于Android引導程序的可以在這里了解。

第三步：內核

Android內核與桌面linux內核啟動的方式差不多。內核啟動時，設置緩存、被保護存儲器、計劃列表，加載驅動。當內核完成系統(tǒng)設置，它首先在系統(tǒng)文件中尋找”init”文件，然后啟動root進程或者系統(tǒng)的第一個進程。

第四步：init進程

init是第一個進程，我們可以說它是root進程或者說有進程的父進程。init進程有兩個責任，一是掛載目錄，比如/sys、/dev、/proc，二是運行init.rc腳本。

init進程可以在/system/core/init找到。

init.rc文件可以在/system/core/rootdir/init.rc找到。

readme.txt可以在/system/core/init/readme.txt找到。

對于init.rc文件，Android中有特定的格式以及規(guī)則。在Android中，我們叫做Android初始化語言。

Action（動作）：動作是以命令流程命名的，有一個觸發(fā)器決定動作是否發(fā)生。

語法

1

2

3

4

5

; html-script: false ]

on trigger

command

command

command

Service（服務）：服務是init進程啟動的程序、當服務退出時init進程會視情況重啟服務。

語法

1

2

3

4

5

; html-script: false ]

service name pathname [argument]*

option

option

...

Options（選項）

選項是對服務的描述。它們影響init進程如何以及何時啟動服務。

咱們來看看默認的init.rc文件。這里我只列出了主要的事件以及服務。

Table

Action/Service

描述

on early-init

設置init進程以及它創(chuàng)建的子進程的優(yōu)先級，設置init進程的安全環(huán)境

on init

設置全局環(huán)境，為cpu accounting創(chuàng)建cgroup(資源控制)掛載點

on fs

掛載mtd分區(qū)

on post-fs

改變系統(tǒng)目錄的訪問權限

on post-fs-data

改變/data目錄以及它的子目錄的訪問權限

on boot

基本網絡的初始化，內存管理等等

service servicemanager

啟動系統(tǒng)管理器管理所有的本地服務，比如位置、音頻、Shared preference等等…

service zygote

啟動zygote作為應用進程

在這個階段你可以在設備的屏幕上看到“Android”logo了。

第五步

在Java中，我們知道不同的虛擬機實例會為不同的應用分配不同的內存。假如Android應用應該盡可能快地啟動，但如果Android系統(tǒng)為每一個應用啟動不同的Dalvik虛擬機實例，就會消耗大量的內存以及時間。因此，為了克服這個問題，Android系統(tǒng)創(chuàng)造了”Zygote”。Zygote讓Dalvik虛擬機共享代碼、低內存占用以及最小的啟動時間成為可能。Zygote是一個虛擬器進程，正如我們在前一個步驟所說的在系統(tǒng)引導的時候啟動。Zygote預加載以及初始化核心庫類。通常，這些核心類一般是只讀的，也是Android SDK或者核心框架的一部分。在Java虛擬機中，每一個實例都有它自己的核心庫類文件和堆對象的拷貝。

Zygote加載進程

加載ZygoteInit類，源代碼：/frameworks/base/core/java/com/android/internal/os/ZygoteInit.java

registerZygoteSocket()為zygote命令連接注冊一個服務器套接字。

preloadClassed “preloaded-classes”是一個簡單的包含一系列需要預加載類的文本文件，你可以在/frameworks/base找到“preloaded-classes”文件。

preloadResources() preloadResources也意味著本地主題、布局以及android.R文件中包含的所有東西都會用這個方法加載。

在這個階段，你可以看到啟動動畫。

第六步：系統(tǒng)服務或服務

完成了上面幾步之后，運行環(huán)境請求Zygote運行系統(tǒng)服務。系統(tǒng)服務同時使用native以及java編寫，系統(tǒng)服務可以認為是一個進程。同一個系統(tǒng)服務在Android SDK可以以System Services形式獲得。系統(tǒng)服務包含了所有的System Services。

Zygote創(chuàng)建新的進程去啟動系統(tǒng)服務。你可以在ZygoteInit類的”startSystemServer”方法中找到源代碼。

核心服務：

啟動電源管理器；

創(chuàng)建Activity管理器；

啟動電話注冊；

啟動包管理器；

設置Activity管理服務為系統(tǒng)進程；

啟動上下文管理器；

啟動系統(tǒng)Context Providers；

啟動電池服務；

啟動定時管理器；

啟動傳感服務；

啟動窗口管理器；

啟動藍牙服務；

啟動掛載服務。

其他服務：

啟動狀態(tài)欄服務；

啟動硬件服務；

啟動網絡狀態(tài)服務；

啟動網絡連接服務；

啟動通知管理器；

啟動設備存儲監(jiān)視服務；

啟動定位管理器；

啟動搜索服務；

啟動剪切板服務；

啟動登記服務；

啟動壁紙服務；

啟動音頻服務；

啟動耳機監(jiān)聽；

啟動AdbSettingsObserver（處理adb命令）。

第七步：引導完成

一旦系統(tǒng)服務在內存中跑起來了，Android就完成了引導過程。在這個時候“ACTION_BOOT_COMPLETED”開機啟動廣播就會發(fā)出去。

Android 10.0 Activity的啟動流程

本文主要學習記錄，基于Android 10的源碼，有錯誤歡迎指正，主要目的是梳理流程圖。

以進程為單位的調用棧圖如下：

1.activity中的startActivity方法最終都會通過拿到ATSM的代理IActivityTaskManager調用的startActivity；

2.之后進入system server進程中的ATMS startActivity，ATMS 經過收集Intent信息，然后使用ActivityStackSupervisor.startSpecificActivityLocked，如果進程已經存在，則直接使用realStartActivityLocked，通過App的binder客戶端的代理ApplicationThread調用回到bindApplication，走入Activity的啟動流程；如果進程不存在則通過socket鏈接Zygote，請求fork新的進程；

3.App進程創(chuàng)建完成后，進程啟動會調用ActivityThread.main方法，初始化主線程Handler,接著走入attach方法，然后通過AMS的代理調用AMS的attachApplication方法，并將App進程的通信代理ApplicationThread傳入AMS；

4.AMS獲取到ATMS調用ApplicationThread的bindApplication回到App進程的ActivityThread.ApplicationThread.bindApplication方法中，然后使用Handler切換到主線程執(zhí)行handleBindApplication，這里初始化了App的進程名字、時間，用戶的硬件配置，包括App的文件系統(tǒng)，創(chuàng)建了App的Context實例，Instrumentation實例，調用App的onCreate回調方法，同時告訴AMS APP初始化工作完畢；

5.AMS接著會調用ATMS的attachApplication，最后調用ClientLifecycleManager的scheduleTransaction方法，通過App的Binder代理ApplicationThread回到ActivityThread；

6.進入ActivityThread.ApplicationThread.scheduleTransaction方法之后就進入了Activity的onStart、onResume回調

創(chuàng)建進程之前的過程主要是AMS的內部信息收集的判斷的過程，下面主要看一下App進程啟動的源碼流程

從應用進程被創(chuàng)建開始，ActivityThread.main被執(zhí)行

調用ActivityThread的attach方法，然后將activity和AMS通信的Binder代理IApplicationThread實例傳入AMS

接著進入AMS進程，ActivityManagerService.attachApplicationLocked

1.thread.bindApplication ：該方法主要講App進程的配置信息通過IApplicationThread Binder通信回傳到ActivityThread中

2.mAtmInternal.attachApplication ：mAtmInternal實際就是ActivityTaskManager的實例，通過LocalServices加載

那么這里相當于走到了ActivityTaskManagerServer的attachApplication中

先看第一條：

注意：ActivityThread中存在于Binder通信的代理--》ApplicationThread extends IApplicationThread.Stub

ActivityThread--》ApplicationThread--》bindApplication

這里的bindApplication主要初始化了AppBindData，然后發(fā)送BIND_APPLICATION給APP的主線程BIND_APPLICATION，最后執(zhí)行了handleBindApplication

handleBindApplication如下：

ActivityThread--》class H extends Handler

該方法主要在App進程中對App的一些硬件資源配置申請的屬性、App的文件夾等完成App基本信息的初始化

接著看第二條：mAtmInternal.attachApplication

mAtmInternal.attachApplication最終會調用mRootActivityContainer.attachApplication(wpc)

RootActivityContainer.attachApplication

接著調用ActivityStackSupervisor.realStartActivityLocked開始創(chuàng)建Activity

ActivityStackSupervisor.realStartActivityLocked

創(chuàng)建ClientLifecycleManager和ClientTransactionHandler來輔助管理Activity的生命周期

注意

clientTransaction.addCallback是LaunchActivityItem

lifecycleItem是ResumeActivityItem

ClientLifecycleManager.scheduleTransaction最終會調用ClientTransaction的schedule方法

那么這個mClient是IApplicationThread的實例，那么此時也就回到了ActivityThread的ApplicationThread中

ActivityThread的ApplicationThread中

因為ActivityThread繼承ClientTransactionHandler，所以到了ClientTransactionHandler中

通過Handler發(fā)送消息EXECUTE_TRANSACTION到H中

接著TransactionExecutor的execute方法

LaunchActivityItem.execute方法

client其實是在ActivityThread的實例，那么就回到了ActivityThread的handleLaunchActivity

接著調用performLaunchActivity

在performLaunchActivity中，主要是加載App的資源包，然后創(chuàng)建了Activity的context實例，并創(chuàng)建了Activity的實例，接著調用activity.attach方法，attach執(zhí)行完之后調用了onCreate方法。

activity.attach

activity.attach中主要

1.創(chuàng)建了PhoneWindow實例

2.設置了Window接口的監(jiān)聽

3.初始化了成員變量，包括線程和WindowManager

到此Oncreate已經完成，那么OnStart和OnResume去哪了？

TransactionExecutor的execute方法

之前們只分析了executeCallbacks，接著executeLifecycleState方法

TransactionExecutor的executeLifecycleState方法

cycleToPath：lifecycleItem即為ResumeActivityItem

第一點：

int finish = lifecycleItem.getTargetState()

lifecycleItem對應ResumeActivityItem，如下：

ResumeActivityItem的getTargetState方法

對應ActivityLifecycleItem中的枚舉類型：

第二點：ActivityClientRecord中的mLifecycleState，由于在前面已經執(zhí)行了handleLaunchActivity所以mLifecycleState=1

對應ActivityLifecycleItem中的枚舉類型：

PRE_ON_CREATE = 0

所以final int star = 1

接著看getLifecyclePath，此時start=1，finish=3

那么返回的IntArray就是2

接著看performLifecycleSequence

最終執(zhí)行的是handleStartActivity所以最終走到了ActivityThread的handleResumeActivity

兩點：

調用activity.performStart

調用Instrumetation.callActivityOnPostCreate

performStart方法：

調用了Instrumentation.callActivityOnStart方法：

最終到了activity的onStart方法

第二點：Instrumentation.callActivityOnPostCreate

上面主要走了cycleToPath，接著ResumeActivityItem.execute

調用了handleResumeActivity方法

handleResumeActivity最終調用performResumeActivity

調用了Instrumentation.callActivityOnResume，

到了activity.onResume()方法

參考文章：

Android_WMS_啟動流程

本文主要是基于android10.0.0來講述下WMS的啟動流程

WMS作為系統(tǒng)的一個關鍵服務其是在SystemServer.java::startOtherServices中啟動的

WMS主要有下面幾個作用

1：應用程序通過WMS向SurfaceFinger申請surface,surface代表的是繪圖表面，應用程序繪制都必須在繪圖表面上

2：管理窗口的層級，一個窗口一般在WMS端都是一個WindowState，其是有層級區(qū)分的，其有baseLayer和subLayer兩個值共同確定

3：窗口動畫：WindowAnimator

其中上面有一個比較重要的對象PhoneWindowManager,主要是負責窗口管理的各種策略

WindowManagerPolicy mPolicy;----------------對應的實現(xiàn)類PhoneWindowManager,主要是窗口管理的策略和按鍵的處理

final ActivityManagerInternal mAmInternal;------對應的是AMS,持有AMS對象

final ActivityTaskManagerInternal mAtmInternal;---管理Task的，android10.0新增

final ArraySetSession mSessions = new ArraySet();----會話，主要是建立和surfaceFinger的連接

final WindowHashMap mWindowMap = new WindowHashMap();----緩存windowstate

AMS,WMS之間數(shù)據(jù)是對應的，通過token值可以在AMS,WMS,應用程序之后來唯一確定一組Window,token是關聯(lián)著一組窗口的，可能有多個WindowState的token值是相同的

整個啟動過程涉及3個線程: system_server主線程, “android.display”, “android.ui”, 整個過程是采用阻塞方式(利用Handler.runWithScissors)執(zhí)行的. 其中WindowManagerService.mH的Looper運行在 “android.display”進程，也就意味著WMS.H.handleMessage()在該線程執(zhí)行。

Android應用程序啟動流程總結

AMS主要功能：

AMS是Android中最核心的服務，主要負責系統(tǒng)中四大組件的啟動、切換、調度及應用進程的管理和調度等工作。還負責啟動或殺死應用程序的進程。

WMS主要功能：

為所有窗口分配Surface。

管理Surface的顯示順序、尺寸、位置。

管理窗口動畫。

輸入系統(tǒng)相關：WMS是派發(fā)系統(tǒng)按鍵和觸摸消息的最佳人選，當接收到一個觸摸事件，它需要尋找一個最合適的窗口來處理消息。

PWS主要功能：

PMS 用來管理跟蹤所有應用APK，包括安裝，卸載，解析，控制權限等。

SystemServer也是一個進程，包括AMS、PMS、WMS等等。

zygote意為“受精卵“。Android是基于Linux系統(tǒng)的，而在Linux中，所有的進程都是由init進程直接或者是間接fork出來的，zygote進程也不例外。

App進程是用戶點擊桌面icon時，通過Launcher進程請求SystemServer，再調用Zygote孵化的。

①點擊啟動一個App，Launcher進程采用Binder IPC向ActivityManagerService發(fā)起startActivity請求；

②ActivityManagerService接收到請求后，向zygote進程發(fā)送創(chuàng)建進程的請求；

③Zygote進程fork出新的子進程，即App進程；

④App進程通過Binder IPC向sytem_server進程發(fā)起綁定Application請求；

⑤system_server進程在收到請求后，進行一系列準備工作后，再通過binder IPC向App進程發(fā)送scheduleLaunchActivity請求；

⑥App進程的binder線程（ApplicationThread）在收到請求后，通過handler向主線程發(fā)送LAUNCH_ACTIVITY消息；

⑦主線程在收到Message后，通過發(fā)射機制創(chuàng)建目標Activity，并回調Activity.onCreate()等方法。

⑧到此，App便正式啟動，開始進入Activity生命周期，執(zhí)行完onCreate/onStart/onResume方法，UI渲染結束后便可以看到App的主界面。

備注：

Launcher，PMS，Zygote，App進程是三個獨立的進程，相互通信就需要使用進程間通信機制。與Zygote通信是使用的socket通信，Launcher，PMS，App進程間使用的是Binder機制。

Android App安裝以及啟動流程

Android App的安裝可以分為有界面的安裝和無界面的安裝。

有界面的安裝其實就是調用系統(tǒng)App（PackageInstaller）去安裝apk，打開安裝apk應用之后，點擊安裝按鈕執(zhí)行startInstall方法，然后就進入安裝中界面開始安裝，安裝成功或者失敗都會有對應的回調。內部其實也是使用PackageManager的installExistingPackage方法，通過binder機制，調用到PackageManagerService的installExistingPackage方法，最終調用到installExistingPackageAsUser方法安裝，而 安裝的核心原理其實就是將apk文件拷貝到系統(tǒng)可識別的重要的文件目錄 ：

無界面安裝是調用adb命令，執(zhí)行到一個c寫的commandline腳本，調用 install_app 方法，然后再調用 pm_command ，然后執(zhí)行到pm腳本，執(zhí)行 run 方法，調用 runinstall ，然后調用 installPackageAsUser 通過AMS執(zhí)行安裝。

說到App的啟動，就需要從開機開始說起，Android開機會先把所有應用安裝一遍就是把apk拷貝到對應的目錄（這也是Android開機慢的原因）。

整個流程如下：

其實App的啟動，除了剛開機是不一樣之外，正常時候基本與Activity的啟動非常接近。

分享題目：android啟動流程,android啟動流程log
當前鏈接：http://chinadenli.net/article7/dsijsij.html

成都網站建設公司_創(chuàng)新互聯(lián)，為您提供網站建設、靜態(tài)網站、建站公司、搜索引擎優(yōu)化、網站維護、企業(yè)網站制作

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)