當(dāng)按下Android設(shè)備電源鍵時(shí)究竟發(fā)生了什么？
10多年的麻栗坡網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對(duì)設(shè)計(jì)、前端、開發(fā)、售后、文案、推廣等六對(duì)一服務(wù)，響應(yīng)快，48小時(shí)及時(shí)工作處理。全網(wǎng)營(yíng)銷推廣的優(yōu)勢(shì)是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動(dòng)調(diào)整麻栗坡建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無(wú)論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。成都創(chuàng)新互聯(lián)公司從事“麻栗坡網(wǎng)站設(shè)計(jì)”,“麻栗坡網(wǎng)站推廣”以來(lái)，每個(gè)客戶項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。
Android的啟動(dòng)過(guò)程是怎么樣的？
什么是Linux內(nèi)核？
桌面系統(tǒng)linux內(nèi)核與Android系統(tǒng)linux內(nèi)核有什么區(qū)別？
什么是引導(dǎo)裝載程序？
什么是Zygote？
什么是X86以及ARM linux？
什么是init.rc?
什么是系統(tǒng)服務(wù)？
當(dāng)我們想到Android啟動(dòng)過(guò)程時(shí)，腦海中總是冒出很多疑問(wèn)。本文將介紹Android的啟動(dòng)過(guò)程，希望能幫助你找到上面這些問(wèn)題的答案。
Android是一個(gè)基于Linux的開源操作系統(tǒng)。x86（x86是一系列的基于intel 8086 CPU的計(jì)算機(jī)微處理器指令集架構(gòu)）是linux內(nèi)核部署最常見(jiàn)的系統(tǒng)。然而，所有的Android設(shè)備都是運(yùn)行在ARM處理器（ARM 源自進(jìn)階精簡(jiǎn)指令集機(jī)器，源自ARM架構(gòu)）上，除了英特爾的Xolo設(shè)備()。Xolo來(lái)源自凌動(dòng)1.6GHz x86處理器。Android設(shè)備或者嵌入設(shè)備或者基于linux的ARM設(shè)備的啟動(dòng)過(guò)程與桌面版本相比稍微有些差別。這篇文章中，我將解釋Android設(shè)備的啟動(dòng)過(guò)程。深入linux啟動(dòng)過(guò)程是一篇講桌面linux啟動(dòng)過(guò)程的好文。
當(dāng)你按下電源開關(guān)后Android設(shè)備執(zhí)行了以下步驟。
此處圖片中step2中的一個(gè)單詞拼寫錯(cuò)了，Boot Loaeder應(yīng)該為Boot Loader（多謝@jameslast 提醒）
第一步：?jiǎn)?dòng)電源以及系統(tǒng)啟動(dòng)
當(dāng)電源按下，引導(dǎo)芯片代碼開始從預(yù)定義的地方（固化在ROM）開始執(zhí)行。加載引導(dǎo)程序到RAM，然后執(zhí)行。
第二步：引導(dǎo)程序
引導(dǎo)程序是在Android操作系統(tǒng)開始運(yùn)行前的一個(gè)小程序。引導(dǎo)程序是運(yùn)行的第一個(gè)程序，因此它是針對(duì)特定的主板與芯片的。設(shè)備制造商要么使用很受歡迎的引導(dǎo)程序比如redboot、uboot、qi bootloader或者開發(fā)自己的引導(dǎo)程序，它不是Android操作系統(tǒng)的一部分。引導(dǎo)程序是OEM廠商或者運(yùn)營(yíng)商加鎖和限制的地方。
引導(dǎo)程序分兩個(gè)階段執(zhí)行。第一個(gè)階段，檢測(cè)外部的RAM以及加載對(duì)第二階段有用的程序；第二階段，引導(dǎo)程序設(shè)置網(wǎng)絡(luò)、內(nèi)存等等。這些對(duì)于運(yùn)行內(nèi)核是必要的，為了達(dá)到特殊的目標(biāo)，引導(dǎo)程序可以根據(jù)配置參數(shù)或者輸入數(shù)據(jù)設(shè)置內(nèi)核。
Android引導(dǎo)程序可以在bootablebootloaderlegacyusbloader找到。
傳統(tǒng)的加載器包含的個(gè)文件，需要在這里說(shuō)明：
init.s初始化堆棧，清零BBS段，調(diào)用main.c的_main()函數(shù)；
main.c初始化硬件（鬧鐘、主板、鍵盤、控制臺(tái)），創(chuàng)建linux標(biāo)簽。
更多關(guān)于Android引導(dǎo)程序的可以在這里了解。
第三步：內(nèi)核
Android內(nèi)核與桌面linux內(nèi)核啟動(dòng)的方式差不多。內(nèi)核啟動(dòng)時(shí)，設(shè)置緩存、被保護(hù)存儲(chǔ)器、計(jì)劃列表，加載驅(qū)動(dòng)。當(dāng)內(nèi)核完成系統(tǒng)設(shè)置，它首先在系統(tǒng)文件中尋找”init”文件，然后啟動(dòng)root進(jìn)程或者系統(tǒng)的第一個(gè)進(jìn)程。
第四步：init進(jìn)程
init是第一個(gè)進(jìn)程，我們可以說(shuō)它是root進(jìn)程或者說(shuō)有進(jìn)程的父進(jìn)程。init進(jìn)程有兩個(gè)責(zé)任，一是掛載目錄，比如/sys、/dev、/proc，二是運(yùn)行init.rc腳本。
init進(jìn)程可以在/system/core/init找到。
init.rc文件可以在/system/core/rootdir/init.rc找到。
readme.txt可以在/system/core/init/readme.txt找到。
對(duì)于init.rc文件，Android中有特定的格式以及規(guī)則。在Android中，我們叫做Android初始化語(yǔ)言。
Action（動(dòng)作）：動(dòng)作是以命令流程命名的，有一個(gè)觸發(fā)器決定動(dòng)作是否發(fā)生。
語(yǔ)法
1
2
3
4
5
; html-script: false ]
on trigger
command
command
command
Service（服務(wù)）：服務(wù)是init進(jìn)程啟動(dòng)的程序、當(dāng)服務(wù)退出時(shí)init進(jìn)程會(huì)視情況重啟服務(wù)。
語(yǔ)法
1
2
3
4
5
; html-script: false ]
service name pathname [argument]*
option
option
...
Options（選項(xiàng)）
選項(xiàng)是對(duì)服務(wù)的描述。它們影響init進(jìn)程如何以及何時(shí)啟動(dòng)服務(wù)。
咱們來(lái)看看默認(rèn)的init.rc文件。這里我只列出了主要的事件以及服務(wù)。
Table
Action/Service
描述
on early-init
設(shè)置init進(jìn)程以及它創(chuàng)建的子進(jìn)程的優(yōu)先級(jí)，設(shè)置init進(jìn)程的安全環(huán)境
on init
設(shè)置全局環(huán)境，為cpu accounting創(chuàng)建cgroup(資源控制)掛載點(diǎn)
on fs
掛載mtd分區(qū)
on post-fs
改變系統(tǒng)目錄的訪問(wèn)權(quán)限
on post-fs-data
改變/data目錄以及它的子目錄的訪問(wèn)權(quán)限
on boot
基本網(wǎng)絡(luò)的初始化，內(nèi)存管理等等
service servicemanager
啟動(dòng)系統(tǒng)管理器管理所有的本地服務(wù)，比如位置、音頻、Shared preference等等…
service zygote
啟動(dòng)zygote作為應(yīng)用進(jìn)程
在這個(gè)階段你可以在設(shè)備的屏幕上看到“Android”logo了。
第五步
在Java中，我們知道不同的虛擬機(jī)實(shí)例會(huì)為不同的應(yīng)用分配不同的內(nèi)存。假如Android應(yīng)用應(yīng)該盡可能快地啟動(dòng)，但如果Android系統(tǒng)為每一個(gè)應(yīng)用啟動(dòng)不同的Dalvik虛擬機(jī)實(shí)例，就會(huì)消耗大量的內(nèi)存以及時(shí)間。因此，為了克服這個(gè)問(wèn)題，Android系統(tǒng)創(chuàng)造了”Zygote”。Zygote讓Dalvik虛擬機(jī)共享代碼、低內(nèi)存占用以及最小的啟動(dòng)時(shí)間成為可能。Zygote是一個(gè)虛擬器進(jìn)程，正如我們?cè)谇耙粋€(gè)步驟所說(shuō)的在系統(tǒng)引導(dǎo)的時(shí)候啟動(dòng)。Zygote預(yù)加載以及初始化核心庫(kù)類。通常，這些核心類一般是只讀的，也是Android SDK或者核心框架的一部分。在Java虛擬機(jī)中，每一個(gè)實(shí)例都有它自己的核心庫(kù)類文件和堆對(duì)象的拷貝。
Zygote加載進(jìn)程
加載ZygoteInit類，源代碼：/frameworks/base/core/java/com/android/internal/os/ZygoteInit.java
registerZygoteSocket()為zygote命令連接注冊(cè)一個(gè)服務(wù)器套接字。
preloadClassed “preloaded-classes”是一個(gè)簡(jiǎn)單的包含一系列需要預(yù)加載類的文本文件，你可以在/frameworks/base找到“preloaded-classes”文件。
preloadResources() preloadResources也意味著本地主題、布局以及android.R文件中包含的所有東西都會(huì)用這個(gè)方法加載。
在這個(gè)階段，你可以看到啟動(dòng)動(dòng)畫。
第六步：系統(tǒng)服務(wù)或服務(wù)
完成了上面幾步之后，運(yùn)行環(huán)境請(qǐng)求Zygote運(yùn)行系統(tǒng)服務(wù)。系統(tǒng)服務(wù)同時(shí)使用native以及java編寫，系統(tǒng)服務(wù)可以認(rèn)為是一個(gè)進(jìn)程。同一個(gè)系統(tǒng)服務(wù)在Android SDK可以以System Services形式獲得。系統(tǒng)服務(wù)包含了所有的System Services。
Zygote創(chuàng)建新的進(jìn)程去啟動(dòng)系統(tǒng)服務(wù)。你可以在ZygoteInit類的”startSystemServer”方法中找到源代碼。
核心服務(wù)：
啟動(dòng)電源管理器；
創(chuàng)建Activity管理器；
啟動(dòng)電話注冊(cè)；
啟動(dòng)包管理器；
設(shè)置Activity管理服務(wù)為系統(tǒng)進(jìn)程；
啟動(dòng)上下文管理器；
啟動(dòng)系統(tǒng)Context Providers；
啟動(dòng)電池服務(wù)；
啟動(dòng)定時(shí)管理器；
啟動(dòng)傳感服務(wù)；
啟動(dòng)窗口管理器；
啟動(dòng)藍(lán)牙服務(wù)；
啟動(dòng)掛載服務(wù)。
其他服務(wù)：
啟動(dòng)狀態(tài)欄服務(wù)；
啟動(dòng)硬件服務(wù)；
啟動(dòng)網(wǎng)絡(luò)狀態(tài)服務(wù)；
啟動(dòng)網(wǎng)絡(luò)連接服務(wù)；
啟動(dòng)通知管理器；
啟動(dòng)設(shè)備存儲(chǔ)監(jiān)視服務(wù)；
啟動(dòng)定位管理器；
啟動(dòng)搜索服務(wù)；
啟動(dòng)剪切板服務(wù)；
啟動(dòng)登記服務(wù)；
啟動(dòng)壁紙服務(wù)；
啟動(dòng)音頻服務(wù)；
啟動(dòng)耳機(jī)監(jiān)聽；
啟動(dòng)AdbSettingsObserver（處理adb命令）。
第七步：引導(dǎo)完成
一旦系統(tǒng)服務(wù)在內(nèi)存中跑起來(lái)了，Android就完成了引導(dǎo)過(guò)程。在這個(gè)時(shí)候“ACTION_BOOT_COMPLETED”開機(jī)啟動(dòng)廣播就會(huì)發(fā)出去。
本文主要學(xué)習(xí)記錄，基于Android 10的源碼，有錯(cuò)誤歡迎指正，主要目的是梳理流程圖。
以進(jìn)程為單位的調(diào)用棧圖如下：
1.activity中的startActivity方法最終都會(huì)通過(guò)拿到ATSM的代理IActivityTaskManager調(diào)用的startActivity；
2.之后進(jìn)入system server進(jìn)程中的ATMS startActivity，ATMS 經(jīng)過(guò)收集Intent信息，然后使用ActivityStackSupervisor.startSpecificActivityLocked，如果進(jìn)程已經(jīng)存在，則直接使用realStartActivityLocked，通過(guò)App的binder客戶端的代理ApplicationThread調(diào)用回到bindApplication，走入Activity的啟動(dòng)流程；如果進(jìn)程不存在則通過(guò)socket鏈接Zygote，請(qǐng)求fork新的進(jìn)程；
3.App進(jìn)程創(chuàng)建完成后，進(jìn)程啟動(dòng)會(huì)調(diào)用ActivityThread.main方法，初始化主線程Handler,接著走入attach方法，然后通過(guò)AMS的代理調(diào)用AMS的attachApplication方法，并將App進(jìn)程的通信代理ApplicationThread傳入AMS；
4.AMS獲取到ATMS調(diào)用ApplicationThread的bindApplication回到App進(jìn)程的ActivityThread.ApplicationThread.bindApplication方法中，然后使用Handler切換到主線程執(zhí)行handleBindApplication，這里初始化了App的進(jìn)程名字、時(shí)間，用戶的硬件配置，包括App的文件系統(tǒng)，創(chuàng)建了App的Context實(shí)例，Instrumentation實(shí)例，調(diào)用App的onCreate回調(diào)方法，同時(shí)告訴AMS APP初始化工作完畢；
5.AMS接著會(huì)調(diào)用ATMS的attachApplication，最后調(diào)用ClientLifecycleManager的scheduleTransaction方法，通過(guò)App的Binder代理ApplicationThread回到ActivityThread；
6.進(jìn)入ActivityThread.ApplicationThread.scheduleTransaction方法之后就進(jìn)入了Activity的onStart、onResume回調(diào)
創(chuàng)建進(jìn)程之前的過(guò)程主要是AMS的內(nèi)部信息收集的判斷的過(guò)程，下面主要看一下App進(jìn)程啟動(dòng)的源碼流程
從應(yīng)用進(jìn)程被創(chuàng)建開始，ActivityThread.main被執(zhí)行
調(diào)用ActivityThread的attach方法，然后將activity和AMS通信的Binder代理IApplicationThread實(shí)例傳入AMS
接著進(jìn)入AMS進(jìn)程，ActivityManagerService.attachApplicationLocked
1.thread.bindApplication ：該方法主要講App進(jìn)程的配置信息通過(guò)IApplicationThread Binder通信回傳到ActivityThread中
2.mAtmInternal.attachApplication ：mAtmInternal實(shí)際就是ActivityTaskManager的實(shí)例，通過(guò)LocalServices加載
那么這里相當(dāng)于走到了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進(jìn)程中對(duì)App的一些硬件資源配置申請(qǐng)的屬性、App的文件夾等完成App基本信息的初始化
接著看第二條：mAtmInternal.attachApplication
mAtmInternal.attachApplication最終會(huì)調(diào)用mRootActivityContainer.attachApplication(wpc)
RootActivityContainer.attachApplication
接著調(diào)用ActivityStackSupervisor.realStartActivityLocked開始創(chuàng)建Activity
ActivityStackSupervisor.realStartActivityLocked
創(chuàng)建ClientLifecycleManager和ClientTransactionHandler來(lái)輔助管理Activity的生命周期
注意
clientTransaction.addCallback是LaunchActivityItem
lifecycleItem是ResumeActivityItem
ClientLifecycleManager.scheduleTransaction最終會(huì)調(diào)用ClientTransaction的schedule方法
那么這個(gè)mClient是IApplicationThread的實(shí)例，那么此時(shí)也就回到了ActivityThread的ApplicationThread中
ActivityThread的ApplicationThread中
因?yàn)锳ctivityThread繼承ClientTransactionHandler，所以到了ClientTransactionHandler中
通過(guò)Handler發(fā)送消息EXECUTE_TRANSACTION到H中
接著TransactionExecutor的execute方法
LaunchActivityItem.execute方法
client其實(shí)是在ActivityThread的實(shí)例，那么就回到了ActivityThread的handleLaunchActivity
接著調(diào)用performLaunchActivity
在performLaunchActivity中，主要是加載App的資源包，然后創(chuàng)建了Activity的context實(shí)例，并創(chuàng)建了Activity的實(shí)例，接著調(diào)用activity.attach方法，attach執(zhí)行完之后調(diào)用了onCreate方法。
activity.attach
activity.attach中主要
1.創(chuàng)建了PhoneWindow實(shí)例
2.設(shè)置了Window接口的監(jiān)聽
3.初始化了成員變量，包括線程和WindowManager
到此Oncreate已經(jīng)完成，那么OnStart和OnResume去哪了？
TransactionExecutor的execute方法
之前們只分析了executeCallbacks，接著executeLifecycleState方法
TransactionExecutor的executeLifecycleState方法
cycleToPath：lifecycleItem即為ResumeActivityItem
第一點(diǎn)：
int finish = lifecycleItem.getTargetState()
lifecycleItem對(duì)應(yīng)ResumeActivityItem，如下：
ResumeActivityItem的getTargetState方法
對(duì)應(yīng)ActivityLifecycleItem中的枚舉類型：
第二點(diǎn)：ActivityClientRecord中的mLifecycleState，由于在前面已經(jīng)執(zhí)行了handleLaunchActivity所以mLifecycleState=1
對(duì)應(yīng)ActivityLifecycleItem中的枚舉類型：
PRE_ON_CREATE = 0
所以final int star = 1
接著看getLifecyclePath，此時(shí)start=1，finish=3
那么返回的IntArray就是2
接著看performLifecycleSequence
最終執(zhí)行的是handleStartActivity所以最終走到了ActivityThread的handleResumeActivity
兩點(diǎn)：
調(diào)用activity.performStart
調(diào)用Instrumetation.callActivityOnPostCreate
performStart方法：
調(diào)用了Instrumentation.callActivityOnStart方法：
最終到了activity的onStart方法
第二點(diǎn)：Instrumentation.callActivityOnPostCreate
上面主要走了cycleToPath，接著ResumeActivityItem.execute
調(diào)用了handleResumeActivity方法
handleResumeActivity最終調(diào)用performResumeActivity
調(diào)用了Instrumentation.callActivityOnResume，
到了activity.onResume()方法
參考文章：
本文主要是基于android10.0.0來(lái)講述下WMS的啟動(dòng)流程
WMS作為系統(tǒng)的一個(gè)關(guān)鍵服務(wù)其是在SystemServer.java::startOtherServices中啟動(dòng)的
WMS主要有下面幾個(gè)作用
1：應(yīng)用程序通過(guò)WMS向SurfaceFinger申請(qǐng)surface,surface代表的是繪圖表面，應(yīng)用程序繪制都必須在繪圖表面上
2：管理窗口的層級(jí)，一個(gè)窗口一般在WMS端都是一個(gè)WindowState，其是有層級(jí)區(qū)分的，其有baseLayer和subLayer兩個(gè)值共同確定
3：窗口動(dòng)畫：WindowAnimator
其中上面有一個(gè)比較重要的對(duì)象PhoneWindowManager,主要是負(fù)責(zé)窗口管理的各種策略
WindowManagerPolicy mPolicy;----------------對(duì)應(yīng)的實(shí)現(xiàn)類PhoneWindowManager,主要是窗口管理的策略和按鍵的處理
final ActivityManagerInternal mAmInternal;------對(duì)應(yīng)的是AMS,持有AMS對(duì)象
final ActivityTaskManagerInternal mAtmInternal;---管理Task的，android10.0新增
final ArraySetSession mSessions = new ArraySet();----會(huì)話，主要是建立和surfaceFinger的連接
final WindowHashMap mWindowMap = new WindowHashMap();----緩存windowstate
AMS,WMS之間數(shù)據(jù)是對(duì)應(yīng)的，通過(guò)token值可以在AMS,WMS,應(yīng)用程序之后來(lái)唯一確定一組Window,token是關(guān)聯(lián)著一組窗口的，可能有多個(gè)WindowState的token值是相同的
整個(gè)啟動(dòng)過(guò)程涉及3個(gè)線程: system_server主線程, “android.display”, “android.ui”, 整個(gè)過(guò)程是采用阻塞方式(利用Handler.runWithScissors)執(zhí)行的. 其中WindowManagerService.mH的Looper運(yùn)行在 “android.display”進(jìn)程，也就意味著WMS.H.handleMessage()在該線程執(zhí)行。
AMS主要功能：
AMS是Android中最核心的服務(wù)，主要負(fù)責(zé)系統(tǒng)中四大組件的啟動(dòng)、切換、調(diào)度及應(yīng)用進(jìn)程的管理和調(diào)度等工作。還負(fù)責(zé)啟動(dòng)或殺死應(yīng)用程序的進(jìn)程。
WMS主要功能：
為所有窗口分配Surface。
管理Surface的顯示順序、尺寸、位置。
管理窗口動(dòng)畫。
輸入系統(tǒng)相關(guān)：WMS是派發(fā)系統(tǒng)按鍵和觸摸消息的最佳人選，當(dāng)接收到一個(gè)觸摸事件，它需要尋找一個(gè)最合適的窗口來(lái)處理消息。
PWS主要功能：
PMS 用來(lái)管理跟蹤所有應(yīng)用APK，包括安裝，卸載，解析，控制權(quán)限等。
SystemServer也是一個(gè)進(jìn)程，包括AMS、PMS、WMS等等。
zygote意為“受精卵“。Android是基于Linux系統(tǒng)的，而在Linux中，所有的進(jìn)程都是由init進(jìn)程直接或者是間接fork出來(lái)的，zygote進(jìn)程也不例外。
App進(jìn)程是用戶點(diǎn)擊桌面icon時(shí)，通過(guò)Launcher進(jìn)程請(qǐng)求SystemServer，再調(diào)用Zygote孵化的。
①點(diǎn)擊啟動(dòng)一個(gè)App，Launcher進(jìn)程采用Binder IPC向ActivityManagerService發(fā)起startActivity請(qǐng)求；
②ActivityManagerService接收到請(qǐng)求后，向zygote進(jìn)程發(fā)送創(chuàng)建進(jìn)程的請(qǐng)求；
③Zygote進(jìn)程fork出新的子進(jìn)程，即App進(jìn)程；
④App進(jìn)程通過(guò)Binder IPC向sytem_server進(jìn)程發(fā)起綁定Application請(qǐng)求；
⑤system_server進(jìn)程在收到請(qǐng)求后，進(jìn)行一系列準(zhǔn)備工作后，再通過(guò)binder IPC向App進(jìn)程發(fā)送scheduleLaunchActivity請(qǐng)求；
⑥App進(jìn)程的binder線程（ApplicationThread）在收到請(qǐng)求后，通過(guò)handler向主線程發(fā)送LAUNCH_ACTIVITY消息；
⑦主線程在收到Message后，通過(guò)發(fā)射機(jī)制創(chuàng)建目標(biāo)Activity，并回調(diào)Activity.onCreate()等方法。
⑧到此，App便正式啟動(dòng)，開始進(jìn)入Activity生命周期，執(zhí)行完onCreate/onStart/onResume方法，UI渲染結(jié)束后便可以看到App的主界面。
備注：
Launcher，PMS，Zygote，App進(jìn)程是三個(gè)獨(dú)立的進(jìn)程，相互通信就需要使用進(jìn)程間通信機(jī)制。與Zygote通信是使用的socket通信，Launcher，PMS，App進(jìn)程間使用的是Binder機(jī)制。
Android App的安裝可以分為有界面的安裝和無(wú)界面的安裝。
有界面的安裝其實(shí)就是調(diào)用系統(tǒng)App（PackageInstaller）去安裝apk，打開安裝apk應(yīng)用之后，點(diǎn)擊安裝按鈕執(zhí)行startInstall方法，然后就進(jìn)入安裝中界面開始安裝，安裝成功或者失敗都會(huì)有對(duì)應(yīng)的回調(diào)。內(nèi)部其實(shí)也是使用PackageManager的installExistingPackage方法，通過(guò)binder機(jī)制，調(diào)用到PackageManagerService的installExistingPackage方法，最終調(diào)用到installExistingPackageAsUser方法安裝，而 安裝的核心原理其實(shí)就是將apk文件拷貝到系統(tǒng)可識(shí)別的重要的文件目錄 ：
無(wú)界面安裝是調(diào)用adb命令，執(zhí)行到一個(gè)c寫的commandline腳本，調(diào)用 install_app 方法，然后再調(diào)用 pm_command ，然后執(zhí)行到pm腳本，執(zhí)行 run 方法，調(diào)用 runinstall ，然后調(diào)用 installPackageAsUser 通過(guò)AMS執(zhí)行安裝。
說(shuō)到App的啟動(dòng)，就需要從開機(jī)開始說(shuō)起，Android開機(jī)會(huì)先把所有應(yīng)用安裝一遍就是把a(bǔ)pk拷貝到對(duì)應(yīng)的目錄（這也是Android開機(jī)慢的原因）。
整個(gè)流程如下：
其實(shí)App的啟動(dòng)，除了剛開機(jī)是不一樣之外，正常時(shí)候基本與Activity的啟動(dòng)非常接近。
重慶分公司
重慶分公司
