【AOSP 的分层设计理念与命名规范】 - 指南

AOSP 的分层设计理念与命名规范

Android Open Source Project（AOSP）是一个庞大的操作系统工程，为了保证可维护性、可扩展性和跨设备适配性，它采用了严格的分层架构设计。在不同层之间，AOSP 通过统一的命名规范 和 接口设计来维持清晰的边界。

---

一、AOSP 的分层设计理念

AOSP 典型的分层模型可能分为以下几层：

1. 应用层（Application Layer）

• 提供给第三方 App 或架构应用使用的公共 API。

• 主要由 Java/Kotlin Manager 类组成，例如：

  • AudioManager

  • CarAudioManager

  • BluetoothManager

这些类运行在应用进程中，本质是Binder Client，调用会被转发到 System Server 层。

---

2. 系统服务层（System Server Layer）

• 在 system_server 进程中运行的核心服务。

• 由 Java Service 类完成，例如：

  • AudioService

  • CarAudioService

  • BluetoothService

这一层负责：

• 通过权限校验（例如控制哪些 App 能够修改系统音量）

• 策略调度（例如不同场景下音频路由规则）

• 对接 JNI，调用 native 层服务

---

3. JNI/中间层（JNI Bridge Layer）

• 通过 JNI（Java Native Interface）将Java Service 层的调用桥接到native 层。

• 典型的命名方式为 XXXSystem，例如：

  • AudioSystem (Java ↔ native 之间的桥梁)

职责：

• 将 Java 方法调用转换为 Binder IPC

• 与 native 层的服务（如 AudioFlinger）交互

---

4. Native Daemon 层（Native Daemon Layer）

• 由独立进程运行的 native 服务，通常进程名以-server 结尾。

• 例如：

  • audioserver

  • cameraserver

  • drmserver

这些进程负责与 HAL 和硬件交互，保证性能与稳定性。

---

5. Native Service 层（C++ Service Layer）

• 运行在 Daemon 进程中的 C++ 类，一般命名为XXXService。

• 例如：

  • AudioFlinger（负责音频混音和播放）

  • AudioPolicyService（负责音频策略和路由）

它们通过 Binder 向上层暴露接口，供 AudioSystem 调用。

---

6. HAL 层（Hardware Abstraction Layer）

• 提供硬件抽象接口，通常遵循HIDL/AIDL 规范。

• 例如：

  • audio HAL → 控制 DSP、Codec 芯片

  • camera HAL → 驱动摄像头传感器

---

7. 内核层（Linux Kernel Layer）

• 提供设备驱动、调度、内存和进程管理等基础作用。

• HAL 通过内核驱动与真实硬件交互。

---

二、AOSP 的命名规范

Android 在不同层之间有明确的命名规则：

层级	命名后缀	示例	特点
应用 API 层	Manager	AudioManager, CarAudioManager	面向 App 的公共接口
System Server 层	Service (Java)	AudioService, CarAudioService	在 system_server 中运行，给出核心逻辑
JNI 桥接层	System	AudioSystem	Java ↔ native 的桥梁
Native Daemon 进程	xxxserver	audioserver, cameraserver	独立进程，运行多个 native Service
Native Service (C++)	Service	AudioFlinger, AudioPolicyService	真正的资源管理与硬件交互
HAL 层接口	HAL / HIDL/AIDL 接口	audio HAL, camera HAL	硬件抽象层
内核驱动	Linux 驱动名	snd_soc_xxx, camera_xxx	最底层，驱动硬件

---

三、以 Audio 为例的完整调用链

App 层
│
▼
AudioManager (App API)
│ Binder 调用
▼
AudioService (System Server)
│ JNI 调用
▼
AudioSystem (JNI 桥接)
│ Binder IPC
▼
audioserver (native daemon)
├── AudioFlinger (音频混音/播放/录音)
└── AudioPolicyService (音频路由/策略)
│
▼
Audio HAL (HIDL/AIDL 接口)
│
▼
Linux Kernel Driver → 硬件 Codec/DSP

四、车载扩展 (Car Audio)

车载系统在标准 Android Audio 体系上扩展了 CarAudio 模块：

• CarAudioManager → 提供给车载应用的 API

• CarAudioService → 在 system_server 中运行，管理多音区、多音源策略

• 底层依然复用标准的 AudioManager / AudioService → audioserver

这样保证了 车载需求（多区域音频、乘员区控制） 与 Android 标准框架 的兼容性。

---

五、总结

• 分层设计理念：AOSP 采用Manager → Service → System → xxxserver → HAL → Kernel的清晰分层，保证模块解耦和跨设备可扩展性。

• 命名规范：

  • Manager → API 层

  • Service (Java) → System Server 层

  • System → JNI 桥接层

  • xxxserver → Native Daemon 进程

  • Service (C++) → Native Service

  • HAL → 硬件抽象层

此种分层和命名方式，使 Android 可以统一对外 API，同时 灵活适配不同硬件平台，尤其在车载系统中，可以扩展 CarAudio 但不破坏整体框架。