Appearance
00 总体架构：五层结构与关键进程全景
本页导读：本页是「架构原理篇」的地图。以 Android 16（API 36）为基线，自底向上过一遍 Linux 内核、HAL、原生库、Framework、应用五层，再横向铺开 init、zygote、system_server、surfaceflinger、hwservice 等关键进程的全景表。后续 12 页是对本页每个区块的放大，先建立空间感，再进入细节。
一、五层模型：一座五层小楼
把 Android 想成一座小楼：地基是 Linux 内核，一楼是各硬件厂商装修的 HAL 机房，二楼堆着公共设备库（原生库与 ART 运行时），三楼是 Framework 政务区（system_server 及各系统服务），四楼才是我们日常写的应用住户。楼层之间不能随意穿墙：应用调用的每个「系统能力」，最终都要通过 Binder 或系统调用一层层往下传。
| 层 | 典型代码位置 | 主要语言 | 代表组件 |
|---|---|---|---|
| 应用层 | 各 App（含系统应用） | Kotlin/Java | Launcher、SystemUI、Settings、第三方 App |
| Framework 层 | frameworks/base | Java/Kotlin + JNI | ActivityManagerService、WindowManagerService、framework.jar |
| 原生库与运行时 | frameworks/native、art、bionic | C/C++ | SurfaceFlinger、libbinder、libgui、ART、libc |
| HAL 层 | hardware/interfaces、设备 vendor/ | C++/Rust | AIDL HAL（graphics/composer、power/stats、audio…） |
| Linux 内核层 | kernel/common | C | binder、dmabuf heap、wakelock/autosuspend、ashmem→osmem |
两点提醒：
- SurfaceFlinger、servicemanager、inputflinger 属于原生系统服务（独立进程，位于
frameworks/native与system/*），不在 system_server 的 JVM 里； - HAL 从 Android 8 起强制接口化（Treble），Android 11 起新 HAL 一律用 AIDL，详见第 12 页。
二、Linux 内核层：四件套
Framework 的很多「魔法」其实是内核机制的用户态投影：
- binder 驱动：
/dev/binder（及/dev/hwbinder、/dev/vndbinder、binderfs）。一次拷贝 IPC、句柄翻译、死亡通知、fd 传递都在这层，见第 04 页。 - 内存管理：lmkd 借助内核 PSI（Pressure Stall Information）做低内存查杀；传统 ashmem 在 Android 16 上已被彻底移除，共享内存走 dmabuf heaps / osmem（具体节点以 AOSP 与内核版本为准）。
- 电源管理：wakelock 与 autosuspend 是 Doze 之外的第二道省电闸门，见第 11 页。
- 输入设备：
/dev/input/event*+ inotify/epoll，是第 09 页输入系统的起点。
三、原生库与运行时层
- ART（
art/）：AOT/JIT 混合执行、GC、镜像堆（image）；zygote 预加载的全部类都活在这里，见第 02 页。 - bionic（
bionic/）：libc/libm/libdl，Android 专属的 linker 与 property 客户端也在此。 - libbinder / libbinder_ndk（
frameworks/native/libs/binder/）：Binder 用户态核心，IPCThreadState、ProcessState、Parcel的 C++ 实现。 - libgui（
frameworks/native/libs/gui/）：BufferQueue、SurfaceControl、BLASTBufferQueue，图形数据通路，见第 10 页。 - libandroid_runtime（
frameworks/base/core/jni/）：JNI onLoad 注册表，把上面的 C++ 能力接到 Java Framework，android.os.Binder背后就是它。
四、HAL 层：厂商的接口合同
HAL（Hardware Abstraction Layer）让 framework 不直链厂商 .so，而是跨进程调用稳定的接口：
- 接口定义在
hardware/interfaces（如hardware/interfaces/graphics/composer3/aidl/），厂商在vendor/下实现并注册到 servicemanager； - 系统侧与厂商侧通过 VINTF（
manifest.xml+compatibility_matrix.xml）校验版本兼容； - 传统 HIDL 自 Android 13 起停止新增，Android 16 上主流子系统（composer、audio、health、power/stats 等）已全部 AIDL 化。
五、Framework 层：system_server 的政务区
Framework 编译产物主要落两处：
framework.jar（frameworks/base/core）：SDK 类 +com.android.internal内部类，所有应用进程共享（zygote 预加载）；services.jar/SystemServer.apk（frameworks/base/services）：只被 system_server 加载的系统服务实现。
system_server 内部按包分工非常清晰（AOSP main 分支）：
text
frameworks/base/services/core/java/com/android/server/
├── am/ # ActivityManagerService、ProcessList、BroadcastQueue、OOM _adj
├── wm/ # WindowManagerService、Task、ActivityRecord、ATMS
├── pm/ # PackageManagerService、PermissionManagerService、安装会话
├── power/ # PowerManagerService
├── deviceidle/ # DeviceIdleController（Doze）
├── input/ # InputManagerService
└── ... # alarm、notification、connectivity、telephony 等数十个包注：上面目录中
com/android/server前缀以 AOSP 实际路径services/core/java/com/android/server/为准，此处为便于对照做了简写；各服务启动顺序见第 03 页。
六、应用层：三类住户
- 系统应用（
/system_ext、/product、/system/apex）：Launcher、SystemUI、Settings、电话等，多为 platform 签名或特权权限，运行在system_appSELinux 域； - 普通第三方应用：各自独立进程、独立 uid，经 zygote fork 孵化；
- isolated/isolated 进程：如 WebView 沙箱、媒体处理进程，权限被剥到最低，不能直接访问 Binder 服务。
七、关键进程全景表
| 进程 | 可执行/来源 | 谁启动 | 核心职责 | 快速查看 |
|---|---|---|---|---|
| init | /system/bin/init，读 *.rc | 内核（PID 1） | 挂载分区、解析 rc、拉服务、property 服务 | ps -p 1、getprop |
| ueventd | init 别名 | init | 冷启动设备节点、固件加载 | dmesg |
| servicemanager | frameworks/native/cmds/servicemanager | init | Binder 上下文管理者（handle 0） | service list |
| hwservicemanager | system/hwservicemanager | init | HIDL HAL 注册表（遗产，逐步退役） | lshal |
| apexd | system/apex | init 早期 | 挂载 APEX 模块到 /apex | adb shell dumpsys package、ls /apex |
| zygote64 / zygote | app_process + ZygoteInit | init（zygote.rc） | 预加载 + fork 孵化所有 Java 进程 | ps -A 过滤 zygote |
| system_server | zygote fork，SystemServer | zygote | 全部 Java 系统服务宿主 | dumpsys activity、top |
| surfaceflinger | frameworks/native/services/surfaceflinger | init | 合成、VSYNC、显示 HAL 代理 | dumpsys SurfaceFlinger |
| 各 AIDL HAL | vendor/bin/hw/... | init | 硬件能力提供方（composer、audio、sensors…） | servicemanager -l（AIDL） |
| audioserver | frameworks/av/services | init | 音频策略与混音 | dumpsys media.audio_flinger |
| cameraserver | frameworks/av/services/camera | init | 相机服务框架 | dumpsys media.camera |
| lmkd | system/core 系列，实际在 system/memory 模块 | init | PSI 驱动的 Low Memory Killer | dumpsys lmkd_service |
| tombstoned | frameworks/native/cmds/tombstoned | init | native 崩溃落盘 | /data/tombstones |
| 应用进程 | zygote fork | AMS/ATMS | 每个 App 至少一个进程 | dumpsys activity processes |
读表要点：system_server 只有一个，它挂了整机重启（Watchdog 拉起）；zygote 可以有第二个 32 位实例（zygote_secondary）；HAL 进程数量随设备而异，但都注册在 servicemanager/hwservicemanager 名下可枚举。
八、一次点击的一生：把五层串起来
用户点开 Launcher 图标到应用画面出现，这条链路几乎踩过本册每一页：
- 手指按下，触摸中断进内核，
/dev/input/event*出现原始事件（第 09 页）； - InputReader 把原始事件翻译成
MotionEvent，InputDispatcher 按焦点窗投给 Launcher（第 09 页）； - Launcher 主线程 Looper 取出输入消息，走到
View.performClick()的startActivity()（第 05 页）； startActivity是一个 Binder 事务，跨进 system_server 的 ATMS（第 04、06 页）；- 目标进程不存在时，ATMS 经 ProcessList 向 zygote 发孵化请求，zygote
fork出新进程（第 02 页）； - 新进程里
ActivityThread.main()起主线程 Looper，反向 Binder 调用 AMS 完成 attach（第 02、05 页）； - AMS/ATMS 把
LaunchActivityItem投递回应用进程，完成onCreate（第 06 页）； setContentView后 ViewRootImpl 向 WMSrelayout申请窗口与 Surface（第 07 页）；- 应用 RenderThread 绘制，BLASTBufferQueue 把帧排队给 SurfaceFlinger（第 10 页）；
- WMS 用同步事务确认窗口就绪，提交给 SurfaceFlinger 合成（第 07、10 页）；
- HWC/DPU 扫描输出，VSYNC 信号回传驱动 Choreographer 继续下一帧（第 10 页）；
- 整条链路若任何一环超过 5 秒，ANR 的门票就寄到（第 06、09 页）。
这条链值得在学完后面各页后回头再读一遍——架构不是静态地图，而是这条永不停歇的流水线。
九、线程视角：每个进程都是一个小社会
- system_server：除了 Binder 线程池（上限被设为 32，高于普通进程的 16，见
frameworks/native/libs/binder/ProcessState.cpp的setThreadPoolMaxThreadCount，具体值以 AOSP 为准），还有android.fg、android.ui、android.io、ActivityManager、Watchdog等几十个命名线程，dump 时一眼可辨； - 应用进程：main（Looper/Choreographer）+ Binder 池（默认上限 16）+ RenderThread（HWC 渲染）+ 各库线程。主线程被卡 5 秒以上，输入 ANR 就找上门；
- surfaceflinger：主线程只做合成调度，VSYNC、事务提交各有专职线程，所以它极少成为卡顿元凶。
十、分区视角：代码和库装在哪里
五层模型讲的是职责分层，分区（partition）则是同一件事的物理投影。理解分区，才能理解为什么 OTA 可以只刷 system 而不动 vendor：
| 分区 | 归属 | 装什么 | 谁能写 |
|---|---|---|---|
| system | Google/OEM | framework.jar、services、核心 bin、APEX 镜像 | 平台 OTA |
| system_ext | OEM | 平台级 OEM 定制（不动 system 的前提下） | OEM |
| product | OEM | 预装应用、产品级配置与 RRO overlay | OEM |
| vendor | SoC/ODM 厂商 | HAL 实现、驱动配套 bin、vndbinder 服务 | 厂商固件 |
| odm | ODM | 机型强相关资产 | ODM |
| super | 动态分区容器 | system/vendor/product/odm 等子分区的宿主 | 刷机/OTA |
| /data | 用户 | app 安装、APEX 激活副本、用户数据 | 运行期 |
| /apex | 虚拟挂载 | APEX 激活后的只读内容 | apexd |
要点：
- Treble 边界 = system/vendor 边界：跨这条边界只能走 HAL 接口与 vndbinder/hwbinder，不能直接 dlopen 对方的库（第 12 页）；
- Android 10 起动态分区让上述分区都住在
super容器里，用lpmeta分组分配空间，OTA 可以只更新变动的子分区（第 12 页）； - Mainline APEX 双份存在：出厂版在
system/apex镜像，运行期升级的 APEX 落地在/data/system/apex（AOSP 默认，具体以 AOSP 为准），重启激活后统一挂载到/apex下按名访问。
十一、dumpsys：架构课的随身听诊器
| 想看什么 | 命令 | 对应本册章节 |
|---|---|---|
| 进程与 ANR | dumpsys activity processes / dumpsys activity anrs | 06 |
| 窗口与焦点 | dumpsys window | 07 |
| 包与权限 | dumpsys package <pkg> | 08 |
| 输入焦点窗 | dumpsys input | 09 |
| 图层与合成 | dumpsys SurfaceFlinger | 10 |
| 电源与 wakelock | dumpsys power、dumpsys deviceidle | 11 |
| Binder 内核态 | cat /sys/kernel/debug/binder/transactions（需 root） | 04 |
| APEX 清单 | ls /apex、ls /apex、dumpsys package 过滤 apex | 12 |
十二、版本注记
- API 36（Android 16）：基线。Mainline 模块继续扩容；EnergyStats AIDL 稳定接口开放；边到边显示成默认。
- API 35（Android 15）：16KB 页内核对 native 库提出要求；部分系统 API 继续迁入 APEX。
- API 34（Android 14）：预测式返回手势默认；
SdkExtensions/ExtensionVersion 成为 Mainline 模块能力探测入口。 - API 33（Android 13）：HIDL 冻结，新设备新 HAL 必须 AIDL。
- API 31（Android 12）：BLAST 成为默认渲染提交路径；广播队列重写；unallocated app 进程池（USAP）移除。
- API 29（Android 10）：AMS 拆分出 ATMS；非 SDK 接口灰名单收紧。
十三、本册学习地图
建议顺序：00（本页）→ 01 → 02 → 03 打地基，04/05 双基石必须吃透，再按兴趣选修 06～12：
| 页 | 主题 | 一句话定位 |
|---|---|---|
| 01 | 开机到桌面 | 一切时间线的起点 |
| 02 | init 与 Zygote | 进程从哪里来 |
| 03 | SystemServer | 服务往哪里去 |
| 04 | Binder | 所有跨进程调用的底座 |
| 05 | Handler-Looper | 所有异步调度的底座 |
| 06 | AMS/ATMS | 四大组件的总指挥 |
| 07 | WMS | 窗口与画面入场券 |
| 08 | PMS | 安装、扫描、权限 |
| 09 | 输入系统 | 手指到屏幕的路径 |
| 10 | 图形栈 | 像素到屏幕的路径 |
| 11 | 电源 | 省电与唤醒的博弈 |
| 12 | Treble 与 Mainline | 升级与模块化工程 |
本页小结
本页小结：五层小楼各管一段：内核给机制（binder/内存/电源/输入），原生库与 ART 给性能与工具，HAL 给跨边界合同，Framework 给策略与调度，应用享受一切。记住三件事：① 能力跨层要走 Binder 或系统调用；② system_server 与 surfaceflinger 是两个心脏，一个管逻辑一个管画面；③ dumpsys 是本章每一页的验证入口。
参考
- Android 架构总览：developer.android.com/docs/core/architecture
- AOSP 源码入口（代码搜索）：cs.android.com/android/platform/frameworks/base
- 原生服务源码：cs.android.com/android/platform/frameworks/native
- AOSP 架构文档（Treble/启动/图形）：source.android.com/docs