AOSP 本质解析：为什么 Android 是编译期 + 运行时的混合系统（系统篇）

一、从一个现象开始

很多人第一次接触 AOSP，会有一个直观感受：

编译一次 AOSP，要几十分钟甚至几个小时

👉 于是很自然会产生一个疑问：

AOSP 是不是一个“纯编译期系统”？

👉 但当你真正跑起来 Android 系统，又会发现：

• 有 ART 虚拟机
• 有 Binder 跨进程
• 有 system_server
• 有各种动态调度

👉 这又明显是：

一个“运行时系统”

二、核心结论（先给答案）

AOSP 不是纯编译期系统，也不是纯运行时系统 👉 而是一个： 编译期（Build） + 运行时（Runtime） 的混合架构

三、AOSP 的两大体系

1️⃣ 编译期体系（Build System）

👉 你在编译 AOSP 时，本质在做：

把“源码 → 操作系统镜像”

编译流程（简化版）

C/C++ → Clang → .so Java → javac → .class → dex ↓ framework.jar / services.jar ↓ system.img / vendor.img / boot.img

👉这一部分完全属于：

编译期（compile time）

编译期做了什么？

• 代码结构确定
• 函数符号确定
• 类结构生成
• 部分优化（AOT）
• 系统打包

👉 一句话：

把系统“提前构建好”

2️⃣ 运行时体系（Runtime System）

当设备启动之后：

Android 系统才真正开始运行

启动流程（简化版）

init ↓ Zygote ↓ system_server ↓ AMS / PMS / WMS ↓ App 运行

👉 ✔️ 这一部分属于：

运行时（runtime）

运行时在做什么？

• ART 执行 dex
• Binder 跨进程通信
• 系统服务调度
• 资源管理
• 生命周期管理

👉 一句话：

系统在“动态运行”

四、关键：AOSP 为什么要混合？

👉 回到我们第2篇的核心：

编译期 = 性能 运行时 = 灵活

👉 Android 的需求是：

既要性能，又要灵活

如果全部编译期（像 C）

• App 无法动态加载
• 系统不灵活
• 无法支持复杂生态

如果全部运行时（像纯 JVM）

• 性能差
• 启动慢
• 资源消耗大

👉 所以 Android 选择：

👉 两者结合

五、最关键机制：ART（核心）

ART 做了什么？

dex → oat（机器码）

👉 方式：

安装时：AOT（提前编译） 运行时：JIT（动态优化）

👉 ✔️ 本质：

把 JVM 的运行时行为，部分提前到编译期

六、Framework 的本质（系统层理解）

上一篇我们讲过：

Android Framework = API + Binder + 系统服务

👉 在 AOSP 里：

Framework = 运行在 ART 上的“系统级代码”

👉 举个例子：

Activity.startActivity() ↓ Framework API ↓ Binder ↓ system_server（AMS）

👉 ✔️ 这是：

运行时行为（跨进程）

七、AOSP 的终极模型

编译期（Build） ↓ system.img（系统镜像） ↓ ───────────── ↓ 运行时（Runtime） ↓ ART + Binder + Framework ↓ App 执行

八、再回到最初的问题

为什么 AOSP 编译这么慢？

因为它不是在编一个程序 👉 而是在“构建一个操作系统”

👉 包括：

• Native 层（C/C++）
• Java Framework
• 系统服务
• 系统镜像

👉 ✔️ 本质：

把大量运行时工作提前做掉

九、终极总结（建议记住）

AOSP 的本质： 编译期：构建系统 运行时：运行系统 GCC：纯编译期 JVM：偏运行时 Android：两者融合

十、整个系列的核心串起来

第1篇：C++ 为什么改函数名（编译期行为）
第2篇：编译期 vs 运行时（认知模型）
第3篇：AOSP（混合系统）（本篇）

👉 下一篇（总纲）：

编译期 vs 运行时：一切技术设计的底层逻辑（总纲）

总结

很多人学 AOSP，会陷入细节：

• Binder
• HAL
• Framework
• Native

👉 但如果你没有这个认知：

👉 编译期 vs 运行时

👉 就很难真正理解系统的本质。

👉 一旦你理解了：

👉 Android = 编译期 + 运行时的平衡设计

👉 你会发现：

系统，其实并没有那么复杂