【AOSP 的分层设计理念与命名规范】-EW帮帮网

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 但不破坏整体框架。

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