Android 系统源码：一座“超级城市”的总体规划图——整体结构与各部分关系

如果把 Android 系统源码 想象成一座每天容纳亿万人生活的“超级城市”，那你手机里发生的一切——点亮屏幕、打开App、播放音乐、拍照、联网、定位、通知弹窗——都像城市里一条条正在运行的业务：有人在坐地铁、有人在医院挂号、有人在超市结账、有人在指挥交通。

而 Android 源码就是这座城市的“全套设计图 + 管理制度 + 基础设施施工图”。
它不是一栋楼，而是从地基到天空、从电线到法律、从水管到广播的完整体系。

这篇文章用“城市”隐喻把 Android 源码的整体结构讲清楚，重点回答两个问题：

1. Android 源码整体分哪几层？每层有哪些关键模块？
2. 它们之间如何协作？从 App 一次点击到硬件一次动作，中间发生了什么？

为了让关系更直观，文末还会用两个“贯穿全城的流程”做串联：

• 你点击桌面图标打开 App
• 你按下电源键点亮屏幕

一、先把 Android 源码当“城市规划图”看：五大区 + 一条主干道

Android 常被画成分层结构，但如果你真的去看 AOSP（Android Open Source Project）源码，你会发现它更像一个城市：分区明确，但道路交错、立交很多。

一个最实用的“总览分区”是：

1. Linux Kernel（内核区）：城市地基与公路系统
2. HAL（硬件抽象层）：把“不同品牌硬件”翻译成统一接口的翻译局
3. Native 层（C/C++系统库）：供全城共用的自来水厂、电厂、燃气站
4. Android Runtime（ART）：应用运行的“虚拟机与执行工厂”
5. Framework（Java/Kotlin系统服务）：市政府与各大局委（Activity、Window、Package、Power…）
6. System Apps（系统应用）：城市公共服务窗口（Settings、Launcher、SystemUI…）

而贯穿各区、让城市能“说话办事”的主干道，是：

Binder IPC（跨进程通信）：Android 的“市政专线/政务内网”

没有 Binder，这座城市就会变成一个个互不相干的小岛：App 见不到系统服务，系统服务也管不了 App。

二、从源码目录角度看 Android：AOSP 根目录像“城市各部门档案馆”

AOSP 目录非常大，不同版本略有差异，但你可以把核心目录当作城市各大局的文件柜：

• kernel/（很多厂商单独维护）
  • 内核源：调度、内存、驱动框架（实际上 AOSP 主线常不直接放完整 kernel，更多在 device/vendor）
• system/
  • init、系统基础工具、log、debug、core组件
• hardware/
  • 传统 HAL、硬件相关实现（新架构更多走 vendor）
• frameworks/
  • frameworks/base：Android Framework 核心（ActivityManager、WindowManager、View、SystemServer…）
  • frameworks/native：SurfaceFlinger、Binder native、InputFlinger 等
  • frameworks/av：AudioFlinger、Camera、Media 等
• art/
  • ART 运行时、AOT/JIT、GC 等
• bionic/
  • Android 的 libc（C库），类似城市“通用语言字典”
• libcore/
  • Java 核心库（早期结构，后与 OpenJDK 结合）
• packages/
  • 系统应用（Settings、SystemUI 等）
• build/
  • 构建系统（Soong/Make），像城市“施工管理规范”
• device/、vendor/
  • 设备/厂商定制：板级配置、专有HAL、驱动用户态部分等
• external/
  • 第三方开源组件（zlib、openssl 等）

重点：
真正理解 Android 的“整体关系”，不要死背目录，而要抓住“分层职责 + Binder 连接”。

三、第一层：Linux Kernel——地基、公路、交通规则与“最后一公里”

1）内核在 Android 中干什么？

内核是“城市地基”，负责最底层的资源与隔离：

• 进程/线程调度：谁先跑、谁等一等
• 内存管理：给谁分房子（内存），垃圾回收是谁的事但内存归内核管
• 文件系统：存储像仓库与档案馆
• 网络协议栈：城市对外道路与交通法规
• 驱动模型：屏幕、触摸、音频、摄像头等硬件“最后一公里”
• 安全隔离：SELinux、权限、cgroup 等

2）Android 对内核的“特色改造”

Android 不是原封不动用 Linux，它对内核提出了很多“城市管理需求”：

• Binder 驱动：Android 最关键 IPC 的内核支撑
• wakelock/电源管理相关机制：让手机睡得更省电、醒得更及时
• cgroup/调度优化：前台App优先、后台限制
• SELinux 强制访问控制：系统级安全“法律体系”

内核像“道路与交通法”，上层再聪明也得在这套规则里运行。

四、第二层：HAL——“翻译局”：把硬件差异翻译成统一能力

Android 生态的硬件千奇百怪：不同屏幕、不同指纹、不同相机、不同音频芯片。系统如果直接对硬件讲话，会被硬件差异拖死。

于是有了 HAL（Hardware Abstraction Layer）：

对上提供统一接口，对下对接具体硬件实现。

1）HAL 的位置像什么？

像“翻译局 + 标准化窗口”。市政府（Framework）不会直接对工厂（硬件）喊话，而是通过翻译局按标准下指令。

2）HAL 如何被组织？

Android 发展中 HAL 形态变化很大：

• 早期：传统 HAL（C 接口、dlopen 动态加载）
• 后来：HIDL（HAL Interface Definition Language） + hwservicemanager（Treble 时代）
• 现在：AIDL HAL 越来越主流

共同点：
HAL 往往跑在 vendor 分区，系统框架在 system 分区，两者通过稳定接口连接，减少系统升级被厂商拖住——这就是 Project Treble 的核心价值：把城市“市政厅”和“工厂区”隔离，避免一改法规全城停摆。

五、第三层：Native 系统库——自来水厂、电厂、广播站（C/C++世界）

这层是“全城公共设施”，很多关键服务都在 C/C++ 实现，性能与实时性更好。

典型组件：

1）Binder（native）

Binder 既有内核驱动，也有 native 用户态库支撑，像“市政专线的接入设备”。

2）SurfaceFlinger（图形合成）

SurfaceFlinger 像“城市大屏幕的总导演”：
每个 App 画自己的“图层”，SurfaceFlinger 把它们按 Z 轴顺序合成，输出到屏幕。

它与：

• 硬件合成器 HWC（HAL）
• 显示驱动（Kernel）
  紧密协作。

3）AudioFlinger（音频混音）

像“全城音响调音台”：
把多个 App 的音频流混音，输出到音频 HAL，再到声卡。

4）MediaCodec / Stagefright（多媒体）

像“影视制作车间”：解码、编码、播放管线。

5）InputFlinger（输入分发）

像“城市接警中心”：触摸、按键等事件从驱动上来，经 input 系统分发到对应窗口/App。

6）Bionic libc

Android 的 C 标准库实现，像“城市通用语言规范”，所有 native 程序靠它完成基础工作。

六、第四层：ART——“应用工厂”：让 Java/Kotlin 代码跑得又快又安全

App 主要用 Java/Kotlin 写，最终要在设备上变成可执行机器指令。ART 就是这套“执行体系”。

ART 可以类比为：

• “工厂流水线”：把 dex（字节码）编译成机器码（AOT/JIT）
• “垃圾处理站”：GC 管理对象内存
• “安全检查站”：类型安全、运行时校验
• “性能调度员”：热点代码 JIT、Profile 指导优化

现代 Android 还有：

• AOT（安装/空闲时编译）
• JIT（运行时编译）
• Profile Guided Compilation（按用户真实使用优化）

ART 让上层写起来舒服、跑起来还不算慢。

七、第五层：Framework——“市政府”：系统服务与应用框架的总集合

如果说 Android 让人着迷，Framework 是最核心的一层：它定义了“应用怎么写、系统怎么管应用”。

Framework 主要在 frameworks/base，可以分成两类：

1. Java Framework API：给 App 用的（Activity、Service、View、Notification…）
2. System Services（系统服务）：在 system_server 进程里运行，像各大局委

1）SystemServer：市政府大楼

开机后，zygote 启动 SystemServer，它会启动一堆系统服务，例如：

• ActivityManagerService (AMS)：应用生命周期与进程管理“公安局+户籍系统”
• PackageManagerService (PMS)：安装/卸载/权限/组件解析“工商局”
• WindowManagerService (WMS)：窗口与焦点“城管+舞台管理”
• PowerManagerService：电源与唤醒“电力局”
• DisplayManagerService：显示管理“广电局”
• InputManagerService：输入“接警中心”
• NotificationManagerService：通知“广播台”
• LocationManagerService：定位“导航中心”
• ConnectivityService：网络“交通局”

这些服务绝大多数通过 Binder 对外提供能力：App 不是直接去操作硬件，而是向这些部门“办事”。

2）Framework 与 Native 的关系：市政府与公共设施协作

例如你播放音乐：

• App 调用 Java API
• 进入 AudioManager/MediaPlayer 等框架层
• 通过 Binder 调到 system_server 或 mediaserver
• 走到 native 的 AudioFlinger
• 再到 Audio HAL → Kernel 驱动 → DAC

Framework 像“政策与调度”，native 像“执行与高性能设施”。

八、System Apps：公共服务窗口——你看得见的系统其实大多是 App

很多“系统功能”其实是系统应用完成的，典型如：

• Launcher：桌面
• SystemUI：状态栏、通知栏、最近任务、锁屏界面
• Settings：设置
• Phone：通话
• Package Installer：安装器

它们也是 APK，也跑在应用沙箱里，只是权限更大、与系统服务关系更紧密。

这像城市的“政务大厅窗口”：它自己不是“法律”，但它代表政府帮你办业务。

九、Binder：Android 各部分关系的“纽带”——像政务专线与公章系统

理解 Android 结构，Binder 必须单独拿出来讲。

1）为什么需要 Binder？

因为 Android 把功能拆成很多进程：

• 系统服务集中在 system_server
• 图形在 surfaceflinger
• 媒体在 mediaserver（或其拆分进程）
• App 各自独立进程

进程隔离带来安全与稳定，但也带来沟通问题。Binder 就是为此诞生：
高性能、可携带身份、可做权限校验的 IPC。

2）Binder 像什么？

像“政务内网 + 公章”：

• 你提交申请（transaction）
• 带着你的身份证明（UID/PID）
• 系统服务验你权限（permission/SELinux）
• 受理后回你结果

3）AIDL：政务表格模板

AIDL 就像“标准表格”，定义你能申请什么字段、得到什么回复。系统大量 API 都是 AIDL 生成的 Binder 接口。

十、两条贯穿流程：把“结构关系”变成可视化的因果链

下面用两个常见场景，把各层关系串成一条路，让你真正“看见城市在运转”。

流程 A：你点击桌面图标，App 是怎么启动的？

镜头1：手指触摸屏幕（Kernel → Native）

• 触摸屏驱动把事件上报到内核 input 子系统
• native 层的 InputReader 读取事件
• InputDispatcher 决定把事件派发给哪个窗口

镜头2：事件到达 Launcher（Framework → App）

• Launcher 收到点击事件，决定启动某个 Activity
• Launcher 调用 startActivity()

镜头3：AMS 接管（Framework 的市政府）

• startActivity() 最终通过 Binder 调到 ActivityManagerService
• AMS 检查：目标 Activity 是否存在？权限是否允许？是否要新任务栈？

镜头4：Zygote 孵化进程（ART/Native）
如果目标 App 进程不存在：

• AMS 让 Zygote fork 一个新进程
• 新进程加载应用代码、初始化运行环境（ART）

镜头5：ApplicationThread 回调（Binder）

• system_server 通过 Binder 让 App 进程执行 ActivityThread 调度
• 触发 Application#onCreate、Activity#onCreate/onResume

镜头6：WMS/SurfaceFlinger 负责显示（Framework ↔ Native ↔ HAL ↔ Kernel）

• Activity 创建窗口（Window）
• WMS 管理窗口层级与焦点
• App 绘制生成 Buffer
• SurfaceFlinger 合成图层
• HWC/显示驱动输出到屏幕

你会看到：
一次“点开App”，几乎把 Android 所有核心部门都串了一遍：Input、AMS、Zygote、WMS、SurfaceFlinger、HAL、Kernel。

流程 B：你按电源键点亮屏幕，发生了什么？

镜头1：电源键中断（Kernel）

• 按键驱动产生事件
• 内核识别为 wakeup source（唤醒源）

镜头2：PowerManagerService（Framework）

• 输入事件通过 InputManagerService 传给 PowerManagerService
• PMS 判断当前状态：是否从 doze/suspend 唤醒？亮度策略如何？

镜头3：DisplayManagerService + SurfaceFlinger（Framework + Native）

• 通知显示系统恢复
• SurfaceFlinger 重新开始合成
• HWC 打开显示管线

镜头4：SystemUI 更新界面（System App）

• 锁屏/状态栏等 UI 更新
• 如果有通知、指纹提示等会同步出现

这里你会发现：
硬件动作在内核发生，但“用户看见的结果”在 Framework 与 SystemUI 完成。

十一、再用一张“关系地图”做收束（文字版）

你可以把 Android 的关系想成这样一条链：

• App（Java/Kotlin）
  通过 Framework API 调用
• Framework（system_server 的系统服务）
  通过 Binder 连接到
• Native 守护进程/系统组件（SurfaceFlinger、AudioFlinger…）
  通过 HAL 接口 调用
• 厂商 HAL 实现（vendor）
  调用
• Kernel 驱动
  控制
• 硬件设备

同时另一条“基础支撑链”贯穿全局：

• ART：让 App 能跑、能优化、能管内存
• SELinux/权限：让每一步“能不能做”都有法律依据
• Build 系统 + device/vendor 配置：把城市图纸变成可刷入镜像

结语：理解 Android 源码整体结构的关键，不是记住“有多少层”，而是记住“谁负责什么、靠什么沟通”

Android 之所以复杂，是因为它要在有限资源、强隔离、安全要求、巨大硬件差异下，仍然提供一致的应用体验。它的答案是：

• 用 Linux 内核 管资源与隔离
• 用 HAL 隔离硬件差异
• 用 Native 组件 承担高性能系统能力
• 用 ART 承担应用执行与优化
• 用 Framework 系统服务 做统一管理与对外API
• 用 System Apps 作为用户可见的系统入口
• 用 Binder 把一切串成可治理的“政务网络”