国产A片视频,欧美日韩国产在线观看

第一章：Android 系統(tǒng)啟動(dòng)流程

1.1 啟動(dòng)階段概述

Android 系統(tǒng)從按下電源鍵到 Launcher 顯示，共經(jīng)歷六個(gè)階段：

Bootloader
Linux Kernel 初始化
Init 進(jìn)程啟動(dòng)
init.rc 解析與守護(hù)進(jìn)程啟動(dòng)
Zygote 與 SystemServer 啟動(dòng)
Launcher 啟動(dòng)

【補(bǔ)充】此六階段模型是理解 Android 系統(tǒng)架構(gòu)的基礎(chǔ)。

1.2 Bootloader 階段

當(dāng)設(shè)備通電后，CPU 會(huì)從芯片中固化的一個(gè)地址開始執(zhí)行代碼，這個(gè)地址通常指向 Boot ROM。Boot ROM 中的代碼會(huì)加載 Bootloader 到 RAM 中，并跳轉(zhuǎn)執(zhí)行。Bootloader 負(fù)責(zé)初始化硬件（如時(shí)鐘、內(nèi)存控制器等），然后加載 Linux 內(nèi)核鏡像（通常是 boot.img）到內(nèi)存，并跳轉(zhuǎn)到內(nèi)核入口開始執(zhí)行。

1.3 Linux 內(nèi)核初始化階段

Linux 內(nèi)核啟動(dòng)后，首先會(huì)創(chuàng)建兩個(gè)特殊的進(jìn)程：

swapper 進(jìn)程（pid=0）：也稱 idle 進(jìn)程，是內(nèi)核的空閑進(jìn)程；
kthreadd 進(jìn)程（pid=2）：內(nèi)核線程管理器，負(fù)責(zé)創(chuàng)建和管理其他內(nèi)核線程。

內(nèi)核完成中斷、調(diào)度器、內(nèi)存管理等子系統(tǒng)的初始化后，會(huì)加載必要的驅(qū)動(dòng)模塊（如顯示、存儲(chǔ)、輸入設(shè)備驅(qū)動(dòng)），掛載 tmpfs、proc、sysfs 等虛擬文件系統(tǒng)，最后執(zhí)行用戶空間的第一個(gè)程序：/init。

1.4 Init 進(jìn)程啟動(dòng)（PID=1）

init 是用戶空間的第一個(gè)進(jìn)程（PID=1），也是所有用戶進(jìn)程的祖先。它主要完成以下工作：

掛載 /system、/vendor、/data 等系統(tǒng)分區(qū)；
創(chuàng)建 /dev、/mnt、/acct 等關(guān)鍵目錄；
啟用 SELinux 安全策略；
啟動(dòng)屬性服務(wù)（Property Service），該服務(wù)提供全局配置的讀寫接口，例如 ro.build.version 等系統(tǒng)屬性。

【補(bǔ)充】SELinux 在此階段激活，后續(xù)所有進(jìn)程的行為都將受到其安全策略約束。

?? 更多關(guān)于 init 進(jìn)程的深度解析，可參考：init進(jìn)程

1.5 解析 init.rc 并啟動(dòng)系統(tǒng)守護(hù)進(jìn)程

init 進(jìn)程會(huì)讀取 /init.rc 文件以及它所 include 的其他 .rc 文件（例如 zygote.rc），按照其中的聲明順序啟動(dòng)一系列關(guān)鍵的系統(tǒng)服務(wù)，包括：

servicemanager：Binder 驅(qū)動(dòng)的服務(wù)注冊(cè)中心，所有 Binder 服務(wù)都必須向它注冊(cè)；
hwservicemanager：用于 Treble 架構(gòu)，管理 HIDL HAL 服務(wù)的注冊(cè)；
adbd：Android Debug Bridge 守護(hù)進(jìn)程，提供調(diào)試接口；
logd：日志系統(tǒng)后臺(tái)服務(wù)；
zygote：Java 應(yīng)用進(jìn)程的孵化器，這是 Android 系統(tǒng)中最重要的進(jìn)程之一。

【重要說明】這些服務(wù)并非由 init 主動(dòng)創(chuàng)建，而是通過 init.rc 腳本中的 service 塊被動(dòng)觸發(fā)，init 通過 fork + exec 方式啟動(dòng)它們。

系統(tǒng)架構(gòu)圖

啟動(dòng)流程圖

?? 關(guān)于 init 進(jìn)程如何管理子進(jìn)程生命周期，詳見：init進(jìn)程

1.6 Zygote 與 SystemServer 啟動(dòng)

Zygote 進(jìn)程在啟動(dòng)時(shí)會(huì)預(yù)加載 Android Framework 中常用的 Java 類（如 Activity、View、Intent 等）以及公共資源（如 R 文件）。這樣，當(dāng)需要啟動(dòng)一個(gè)新的應(yīng)用進(jìn)程時(shí)，只需通過 fork() 系統(tǒng)調(diào)用復(fù)制 Zygote 的進(jìn)程鏡像，即可直接復(fù)用這些已加載的類和資源，從而大幅縮短應(yīng)用啟動(dòng)時(shí)間。

SystemServer 進(jìn)程是由 Zygote 通過 fork() 創(chuàng)建的，它會(huì)執(zhí)行 com.android.server.SystemServer 類的 main 方法。SystemServer 負(fù)責(zé)啟動(dòng) Android 系統(tǒng)中超過 90 個(gè)核心服務(wù)，這些服務(wù)被分為三類依次啟動(dòng)：

引導(dǎo)服務(wù)（Bootstrap Services）：包括 ActivityManagerService (AMS)、PackageManagerService (PMS)、WindowManagerService (WMS) 等；
核心服務(wù)（Core Services）：包括 BatteryService、UsageStatsService、WebViewUpdateService 等；
其他服務(wù)（Other Services）：包括 BluetoothService、WifiService、UsbService 等。

【補(bǔ)充】Zygote 與 AMS 之間的通信使用的是 LocalSocket，而不是 Binder。這是因?yàn)?AMS 向 Zygote 發(fā)送的 fork 請(qǐng)求數(shù)據(jù)量非常小（只包含包名、uid、gids 等），使用 Socket 的開銷更低，且無需經(jīng)過 Binder 的權(quán)限校驗(yàn)流程。

?? Zygote 的雙進(jìn)程模型（zygote64 / zygote_secondary）詳解：zygote進(jìn)程

1.7 Launcher 啟動(dòng)

當(dāng) SystemServer 成功啟動(dòng)并完成所有核心服務(wù)的初始化后，ActivityManagerService (AMS) 會(huì)發(fā)送一個(gè) Intent，其 action 為 ACTION_MAIN，category 為 CATEGORY_HOME。這個(gè) Intent 會(huì)被 Launcher 應(yīng)用接收。Zygote 接收到 AMS 的請(qǐng)求后，會(huì) fork 出一個(gè)新的進(jìn)程來運(yùn)行 Launcher。至此，系統(tǒng)完成了從硬件上電到用戶可見界面的全過程。

【補(bǔ)充】此后，所有普通應(yīng)用的進(jìn)程都是通過同樣的方式——由 Zygote fork 生成。

第二章：PackageManagerService (PMS) —— APK 掃描與解析機(jī)制

2.1 PMS 的初始化時(shí)機(jī)與職責(zé)

PackageManagerService（簡(jiǎn)稱 PMS）是在 SystemServer 啟動(dòng)過程中，作為引導(dǎo)服務(wù)（Bootstrap Services） 之一被創(chuàng)建的。它的核心職責(zé)是：

掃描設(shè)備上所有預(yù)置和用戶安裝的 APK 文件；
解析每個(gè) APK 的 AndroidManifest.xml；
提取并注冊(cè)四大組件（Activity、Service、BroadcastReceiver、ContentProvider）信息；
為系統(tǒng)其他模塊（如 AMS）提供組件查詢與權(quán)限校驗(yàn)?zāi)芰Α?/li>

2.2 APK 掃描路徑與優(yōu)先級(jí)

PMS 會(huì)按以下順序和優(yōu)先級(jí)掃描多個(gè)目錄中的 APK：

/system/framework
存放系統(tǒng)核心庫（如 android.jar、framework-res.apk），具有最高優(yōu)先級(jí)。
/system/app
系統(tǒng)內(nèi)置應(yīng)用（如 Settings、SystemUI），優(yōu)先級(jí)次之。
/vendor/app
廠商定制應(yīng)用。
/data/app
用戶通過應(yīng)用商店或 adb 安裝的應(yīng)用，優(yōu)先級(jí)最低。

【補(bǔ)充】掃描順序決定了同名包的覆蓋規(guī)則：高優(yōu)先級(jí)目錄中的 APK 會(huì)覆蓋低優(yōu)先級(jí)目錄中的同名包。

2.3 掃描與解析過程細(xì)節(jié)

PMS 對(duì)每個(gè) APK 執(zhí)行以下操作：

使用 PackageParser 讀取 APK 文件；
解壓并解析 AndroidManifest.xml；
提取 package name、version、permissions、uses-sdk 等元數(shù)據(jù)；
遍歷四大組件聲明，為每個(gè)組件創(chuàng)建對(duì)應(yīng)的對(duì)象（如 ActivityInfo、ServiceInfo）；
將所有信息封裝到一個(gè) PackageParser.Package 對(duì)象中，并存入內(nèi)部集合。

【關(guān)鍵細(xì)節(jié)】每個(gè) APK 對(duì)應(yīng)一個(gè) Package 對(duì)象，其內(nèi)部的組件（如 Activity）以 ArrayList<ActivityInfo> 形式存儲(chǔ)。

2.4 異常處理機(jī)制

PMS 在掃描過程中會(huì)對(duì)不同類型的 APK 采取不同的容錯(cuò)策略：

系統(tǒng) APK（/system/app 等）：即使解析失敗，也不會(huì)刪除文件，但會(huì)記錄嚴(yán)重錯(cuò)誤日志；
非系統(tǒng) APK（/data/app）：若解析失?。ㄈ?Manifest 格式錯(cuò)誤、簽名無效），PMS 會(huì)直接刪除該 APK 文件，防止無效應(yīng)用殘留。

【補(bǔ)充】這一設(shè)計(jì)確保了系統(tǒng)啟動(dòng)后，所有已知組件都是合法且可調(diào)度的。

第三章：WindowManager 體系架構(gòu)與窗口管理機(jī)制

3.1 WindowManager 的三層抽象模型

Android 的窗口管理系統(tǒng)采用清晰的三層架構(gòu)，將應(yīng)用層、客戶端與系統(tǒng)服務(wù)解耦：

Window（應(yīng)用層）
- 是一個(gè)抽象類，代表一個(gè)窗口容器；
- 在 Activity 中的實(shí)際實(shí)現(xiàn)類為 PhoneWindow；
- 負(fù)責(zé)持有 DecorView（根視圖）并管理窗口屬性（如標(biāo)題欄、背景等）。
WindowManager（客戶端接口）
- 是一個(gè)接口，提供給應(yīng)用程序使用的窗口操作 API；
- 實(shí)現(xiàn)類為 WindowManagerImpl；
- 應(yīng)用通過它調(diào)用 addView()、updateViewLayout()、removeView() 等方法。
WindowManagerService（WMS，系統(tǒng)服務(wù)）
- 運(yùn)行在 SystemServer 進(jìn)程中；
- 是窗口管理的真實(shí)執(zhí)行者；
- 負(fù)責(zé)窗口的創(chuàng)建、布局計(jì)算、Z-order 排序、動(dòng)畫驅(qū)動(dòng)、Surface 分配及與 SurfaceFlinger 的交互。

【補(bǔ)充】這種分層設(shè)計(jì)使得應(yīng)用無需關(guān)心底層圖形合成細(xì)節(jié)，同時(shí)保證系統(tǒng)對(duì)窗口的統(tǒng)一管控。

?? 完整窗口機(jī)制解析：Android Window 機(jī)制

3.2 WMS 中的關(guān)鍵對(duì)象

WindowState

每個(gè)窗口在 WMS 內(nèi)部都有一個(gè)對(duì)應(yīng)的 WindowState 對(duì)象；
它記錄了窗口的尺寸、位置、類型（TYPE_APPLICATION / TYPE_STATUS_BAR）、可見性、Token 引用等狀態(tài)信息；
是 WMS 進(jìn)行布局計(jì)算和繪制調(diào)度的基本單位。

WindowToken

WindowToken 是一組窗口的邏輯容器；
例如，一個(gè) Activity 的所有窗口（Activity Window + Dialogs + PopupWindows）共享同一個(gè) WindowToken；
Token 由 AMS 在啟動(dòng) Activity 時(shí)創(chuàng)建，并傳遞給 WMS；
WMS 通過 Token 確保同一任務(wù)內(nèi)的窗口具有相同的生命周期和層級(jí)歸屬。

Window和WindowState關(guān)系

Window和WindowToken關(guān)系

3.3 添加 View 的完整流程

當(dāng)應(yīng)用調(diào)用 WindowManager.addView(decorView, params) 時(shí)，系統(tǒng)執(zhí)行以下步驟：

創(chuàng)建 ViewRootImpl
- WindowManagerImpl 會(huì)為該 View 創(chuàng)建一個(gè) ViewRootImpl 實(shí)例；
- ViewRootImpl 是 View 樹與 WMS 之間的橋梁。
綁定 DecorView
- 將傳入的 DecorView 與 ViewRootImpl 綁定；
- 設(shè)置 LayoutParams。
觸發(fā)首次繪制流程
- 調(diào)用 requestLayout()，觸發(fā) measure → layout → draw；
- 但此時(shí)尚未真正顯示，因?yàn)槲磁c WMS 建立連接。
通過 Binder 調(diào)用 WMS 的 addWindow()
- ViewRootImpl 通過 Binder IPC 調(diào)用 WMS 的 addWindow() 方法；
- 傳入?yún)?shù)包括：View 的 LayoutParams、InputChannel、Display ID 等。
WMS 分配 Surface 并注冊(cè)到 SurfaceFlinger
- WMS 驗(yàn)證權(quán)限和 Token 合法性；
- 創(chuàng)建 WindowState 和 WindowSurfaceController；
- 向 SurfaceFlinger 申請(qǐng)一個(gè) Surface；
- 將 Surface 的生產(chǎn)端（Producer）通過 Binder 返回給 App 進(jìn)程。
App 端開始繪制
- App 拿到 Surface 后，通過 Canvas 或 OpenGL 向其寫入圖形數(shù)據(jù)；
- SurfaceFlinger 在 VSync 信號(hào)到來時(shí)合成所有 Surface 并輸出到屏幕。

WMS職責(zé)

過程

【補(bǔ)充】整個(gè)過程依賴 Choreographer 監(jiān)聽 VSync 信號(hào)，在 doFrame() 回調(diào)中驅(qū)動(dòng)繪制流水線，確保畫面流暢。

3.4 Surface 的管理機(jī)制

WMS 創(chuàng)建真實(shí) Surface：App 進(jìn)程中的 Surface 對(duì)象只是一個(gè)空殼，真正的圖形緩沖區(qū)由 WMS 通過 SurfaceFlinger 創(chuàng)建；
App 僅持有引用：App 通過 Binder 獲取 Surface 的“生產(chǎn)端”（IGraphicBufferProducer），用于提交幀數(shù)據(jù)；
線程安全：Surface 的寫入操作需在 UI 線程或 GL 線程進(jìn)行，避免并發(fā)沖突。

3.5 輸入事件通道

每個(gè)窗口在添加時(shí)，WMS 會(huì)為其創(chuàng)建一對(duì) InputChannel（基于 Socket FD）；
一端留在 WMS，用于接收 InputDispatcher 的事件；
另一端通過 Binder 傳回 App 進(jìn)程，由 ViewRootImpl 的 InputEventReceiver 監(jiān)聽；
事件在 App 主線程中分發(fā)給對(duì)應(yīng) View。

輸入事件通訊模型

?? 深入 WMS 實(shí)現(xiàn)：無處不在的WMS｜WindowManager體系

第四章：Activity 生命周期

4.1 Activity 啟動(dòng)初始化流程

當(dāng) AMS 決定啟動(dòng)一個(gè) Activity 時(shí)，會(huì)通過 Binder IPC 通知目標(biāo)應(yīng)用進(jìn)程的 ActivityThread。ActivityThread 執(zhí)行以下關(guān)鍵步驟：

? attach()

創(chuàng)建 PhoneWindow 對(duì)象；
將當(dāng)前 Activity 設(shè)置為 PhoneWindow 的 Callback；
調(diào)用 window.setWindowManager()，將 Activity 與 WindowManager 關(guān)聯(lián)；
此時(shí) Window 已創(chuàng)建，但尚未添加到 WMS，因此沒有有效的 WindowToken。

? setContentView()

調(diào)用 PhoneWindow.setContentView()；
inflate 用戶指定的布局文件；
創(chuàng)建 DecorView（整個(gè) View 樹的根容器）；
將用戶布局添加到 DecorView 的 content 區(qū)域（ID 為 android.R.id.content）；
此時(shí) View 樹已構(gòu)建完成，但仍未調(diào)用 WindowManager.addView()，因此不會(huì)觸發(fā) measure/layout/draw，也不會(huì)顯示在屏幕上。

【關(guān)鍵說明】只有在 Activity 的生命周期推進(jìn)到 onResume() 階段后，AMS 才會(huì)通知 WMS 添加窗口。

4.2 完整生命周期方法詳解

以下為原文中對(duì)每個(gè)生命周期方法的完整描述，未做任何刪減

onCreate(Bundle savedInstanceState)

開發(fā)者在此方法中進(jìn)行初始化操作，如調(diào)用 setContentView()、findViewById、綁定數(shù)據(jù)等；
系統(tǒng)會(huì)傳入 savedInstanceState 參數(shù)，用于恢復(fù)因異常銷毀前的狀態(tài)；
此時(shí) Activity 的 Window 尚未注冊(cè)到 WMS，WindowToken 為 null；
不能在此彈出 Dialog 或 PopupWindow，否則會(huì)拋出 “Unable to add window – token null is not valid” 異常。

onStart()

Activity 對(duì)用戶可見，但尚未獲得焦點(diǎn)；
WMS 已接收到 AMS 的請(qǐng)求，開始為該 Activity 分配 WindowToken；
Surface 尚未創(chuàng)建，View 樹不可交互；
可在此執(zhí)行輕量級(jí)的可見性相關(guān)邏輯（如啟動(dòng)動(dòng)畫預(yù)加載）。

onResume()

Activity 進(jìn)入前臺(tái)，獲得焦點(diǎn)，可與用戶交互；
Input 事件通道已建立，觸摸、按鍵事件可正常分發(fā)；
注意：盡管此時(shí) Activity 已“resume”，但在某些機(jī)型或系統(tǒng)版本上，首次在 onResume() 中立即彈出 PopupWindow 仍可能失敗，原因在于 WMS 的 Token 注冊(cè)與 Surface 分配存在微小延遲；
推薦做法：將彈窗操作延遲到 onWindowFocusChanged(true) 回調(diào)中，或通過 View.post() 發(fā)送到消息隊(duì)列尾部執(zhí)行。

onNewIntent(Intent intent)

觸發(fā)條件：當(dāng) Activity 的啟動(dòng)模式為 singleTop 或 singleTask，且該 Activity 實(shí)例已存在時(shí)，再次啟動(dòng)它不會(huì)創(chuàng)建新實(shí)例，而是復(fù)用現(xiàn)有實(shí)例，并調(diào)用 onNewIntent()；
作用：用于接收新的 Intent 數(shù)據(jù)；
注意事項(xiàng)：
- 在 onNewIntent() 中，應(yīng)調(diào)用 setIntent(intent) 更新當(dāng)前 Activity 的 Intent，否則后續(xù)調(diào)用 getIntent() 仍返回舊的 Intent；
- 此方法可能在任意生命周期狀態(tài)后被調(diào)用（如 Activity 在后臺(tái)時(shí)被啟動(dòng)），因此不應(yīng)假設(shè) UI 已可見或已 resume；
- 常見使用場(chǎng)景：推送通知點(diǎn)擊、Deep Link 跳轉(zhuǎn)、跨應(yīng)用數(shù)據(jù)傳遞。

【示例】

@Override
protected void onNewIntent(Intent intent) {
    super.onNewIntent(intent);
    setIntent(intent); // 必須調(diào)用，否則 getIntent() 返回舊值
    handleNewIntent(intent);
}

onPause()

Activity 失去焦點(diǎn)（例如：?jiǎn)?dòng)新 Activity、彈出 Dialog、來電界面覆蓋）；
必須快速返回，不能執(zhí)行耗時(shí)操作，否則會(huì)導(dǎo)致 ANR（Application Not Responding）；
系統(tǒng)可能在此之后殺死進(jìn)程，因此不應(yīng)依賴此方法保存持久化數(shù)據(jù)；
通常用于暫停動(dòng)畫、釋放傳感器、注銷廣播接收器等輕量級(jí)清理。

onStop()

Activity 完全不可見（被其他 Activity 完全覆蓋或進(jìn)入后臺(tái)）；
可在此釋放重量級(jí)資源，如停止網(wǎng)絡(luò)請(qǐng)求、關(guān)閉數(shù)據(jù)庫連接、注銷位置監(jiān)聽；
若因配置變更（如屏幕旋轉(zhuǎn)）導(dǎo)致重建，系統(tǒng)會(huì)在 onStop() 之后調(diào)用 onDestroy()。

onDestroy()

Activity 被銷毀；
所有資源應(yīng)在此徹底釋放；
若由 finish() 觸發(fā)，則 isFinishing() 返回 true；
若因系統(tǒng)內(nèi)存不足被回收，則此方法可能不會(huì)被調(diào)用。

4.3 onSaveInstanceState() 的調(diào)用時(shí)機(jī)（版本差異）

原文明確指出以下版本行為差異，完整保留：

在 Android API 級(jí)別 28（Android 9.0）之前：
onSaveInstanceState() 在 onPause() 之后、onStop() 之前調(diào)用。
從 Android API 級(jí)別 28（Android 9.0）開始：
onSaveInstanceState() 被移至 onStop() 之后調(diào)用。

【原因說明】Google 作出此調(diào)整是為了避免開發(fā)者在 onStop() 中釋放的資源（如 Bitmap、數(shù)據(jù)庫連接）被 onSaveInstanceState() 誤用，從而引發(fā)空指針或狀態(tài)不一致問題。

【建議】不要在 onSaveInstanceState() 中訪問可能已在 onStop() 中釋放的對(duì)象。

4.4 AMS 與 Activity 的協(xié)作機(jī)制

AMS 作為系統(tǒng)服務(wù)，維護(hù)所有 Activity 的狀態(tài)機(jī)；
當(dāng)需要切換 Activity 狀態(tài)時(shí)，AMS 通過 Binder 向目標(biāo)進(jìn)程的 ApplicationThread 發(fā)送指令；
ActivityThread 的 H（Handler）接收到消息后，反射調(diào)用對(duì)應(yīng) Activity 的生命周期方法；
Activity 本身不具備主動(dòng)控制權(quán)，其生命周期完全由 AMS 驅(qū)動(dòng)；
因此，Activity 是 AMS 管理的一個(gè)被動(dòng)狀態(tài)機(jī)，應(yīng)用代碼只是狀態(tài)變更的響應(yīng)者。

?? 完整生命周期詳解：Activity生命周期

生命周期

?? 更多 AMS 與 WMS 協(xié)作細(xì)節(jié)：WMS/AMS 窗口層級(jí)結(jié)構(gòu)解析

第五章：其他關(guān)鍵技術(shù)機(jī)制

5.1 Zygote 與 AMS 的通信機(jī)制

AMS 在需要啟動(dòng)新應(yīng)用進(jìn)程時(shí)，不會(huì)直接 fork 進(jìn)程，而是通過 LocalSocket 向 Zygote 發(fā)送請(qǐng)求；
請(qǐng)求內(nèi)容包括：目標(biāo) APK 的包名、用戶 ID（uid）、組 ID（gids）、調(diào)試標(biāo)志等；
Zygote 接收到請(qǐng)求后，執(zhí)行 fork() 創(chuàng)建子進(jìn)程，并在子進(jìn)程中調(diào)用 RuntimeInit.zygoteInit()，最終啟動(dòng)目標(biāo) ActivityThread；
為何使用 Socket 而非 Binder？
- 因?yàn)?fork 請(qǐng)求數(shù)據(jù)量極?。ㄍǔ?< 1KB）；
- Socket 在小數(shù)據(jù)量下延遲更低、開銷更??；
- Binder 需要跨進(jìn)程權(quán)限校驗(yàn)和上下文切換，不適用于高頻、輕量的進(jìn)程孵化場(chǎng)景。