2. Android 系统架构

一个生活化比喻

把 Android 想象成一家大饭店：

• 硬件是饭店的厨房设备（灶台、冰箱）。
• Linux 内核是饭店的物业经理，管水电煤气这些基础设施。
• **HAL（硬件抽象层）**是后厨和前台之间的传菜窗口，把复杂的硬件操作翻译成统一接口。
• ART（Android 运行时）和原生库是后厨，负责真正做菜（执行代码、渲染图形、解码视频）。
• 应用框架层是前台服务员，提供点菜、结账、叫号这些服务（Activity Manager、Window Manager 等）。
• 应用层是顾客点的菜本身（你写的 App）。

你写应用时，大多时候是在跟「服务员」打交道，偶尔需要直接去后厨点菜（用 NDK）。下面逐层看。

自下而上的五层架构

Android 官方文档把架构分成这几大块，从底到顶依次是：

1. Linux Kernel（Linux 内核）
2. Hardware Abstraction Layer（HAL，硬件抽象层）
3. Android Runtime + Native C/C++ Libraries（运行时与原生库）
4. Java API Framework（应用框架层，Java/Kotlin 写的系统服务）
5. System Apps / Applications（应用层）

1. Linux 内核

Android 的底层是 Linux 内核（不是完整的 Linux 发行版，只取了内核部分）。它负责：

• 进程管理：每个应用是一个独立进程，由内核调度。
• 内存管理：分配回收内存，OOM（内存不足）时杀进程。
• 驱动模型：相机、蓝牙、显示、Wi-Fi 这些硬件驱动都跑在内核里。
• 电源管理：唤醒锁、Doze 模式都依赖内核支持。
• 网络协议栈。

2. 硬件抽象层 HAL

硬件厂商千差万别，相机模块甲家和乙家的接口完全不一样。HAL 的作用就是给上层提供一套统一接口，把硬件差异藏在底下。

比如你调用相机 API 拍照，框架层不关心是索尼还是三星的传感器，它只管调 HAL 提供的 camera_device 接口，HAL 再去跟具体硬件沟通。

HAL 涵盖：相机、音频、蓝牙、显示、传感器、定位、网络等等。

3. Android Runtime 与原生库

这一层分两块：

Android Runtime（ART）

从 Android 5.0 开始，原来的 Dalvik 虚拟机被 ART（Android Runtime）取代。ART 的关键特性：

• AOT（Ahead-Of-Time）编译：应用安装时就把字节码编译成机器码，运行更快。
• JIT（Just-In-Time）编译：Android 7 起加入，结合 AOT 用，安装快、运行也快。
• GC（垃圾回收）：自动管理内存，你不用手动 free。

你的 Kotlin/Java 代码编译成字节码（dex），最终在 ART 上跑。

原生 C/C++ 库

一些性能敏感的功能用 C/C++ 写，通过 JNI 暴露给上层：

• Media Framework：音视频编解码。
• OpenGL ES / Vulkan：2D/3D 图形渲染。
• SQLite：本地数据库。
• FreeType：字体渲染。
• WebKit / Chromium：WebView 用的内核。

如果你写游戏或图像处理，可能直接用 NDK 调这些库。

4. 应用框架层（Java API Framework）

这是你日常打交道最多的一层，全是 Java/Kotlin 写的系统服务。核心管理者包括：

• Activity Manager：管理 Activity 生命周期、任务栈。
• Window Manager：管窗口的层级、大小、焦点。
• Package Manager：管应用安装包信息、权限。
• Notification Manager：发通知。
• Content Providers：跨应用数据共享。
• View System：传统 View 体系的底层（Compose 另有实现）。
• Location Manager：定位。
• Telephony Manager：电话、短信、网络状态。

你调用的 Context.startActivity()、NotificationManagerCompat.notify() 这些 API，最终都落到这一层的服务上。

5. 应用层

最顶层就是你写的应用，以及系统预装的应用（电话、短信、设置、启动器）。应用之间是平等的，没有谁能直接访问别人的内存，全靠 Intent、ContentProvider、广播这些机制通信。

各层之间的关系

调用方向是自上而下：你的应用调框架层 API -> 框架层调 HAL 或原生库 -> HAL 调内核驱动 -> 内核操作硬件。

数据返回是自下而上：硬件产生数据 -> 内核驱动 -> HAL -> 原生库或框架层 -> 你的应用。

应用层（你的 App）
   ↓ 调用 API
应用框架层（ActivityManager / WindowManager...）
   ↓
Android Runtime + 原生库（ART / SQLite / OpenGL）
   ↓
HAL（硬件抽象层）
   ↓
Linux 内核（驱动 / 进程 / 内存）
   ↓
硬件（相机 / 屏幕 / 传感器）

为什么要分层

分层不是为了装复杂，而是为了解耦：

• 换个厂商的相机，应用代码不用改，因为 HAL 接口统一。
• 升级 Linux 内核版本，上层框架不用大改。
• 你写应用不用懂驱动，只要会用 API。

这也是为什么 Android 能跑在成千上万种不同硬件上—分层把差异吸收了。

开发者最该关注哪层

日常开发 90% 时间在应用层 + 框架层打转。你写 Activity、调 NotificationManager、用 Room 存数据，都在这两层。

但遇到下面这些情况，你得往下看一眼：

• 性能瓶颈，想用 NDK 写 C++ 代码 -> 涉及原生库和 JNI。
• 调试图形渲染问题 -> 看 SurfaceFlinger、OpenGL。
• 设备适配诡异问题（比如某厂商相机行为不同）-> 可能是 HAL 差异。
• 内存泄漏排查 -> 理解 ART 的 GC 和进程优先级有帮助。

小结

Android 架构自下而上五层：Linux 内核管硬件和进程、HAL 统一硬件接口、ART 跑你的代码、框架层提供系统服务、应用层是你写的 App。调用方向自上而下，分层是为了解耦。下一节看 Android 版本是怎么演进的，以及 API Level 这套编号怎么回事。