📚 课程目录第2章 Android系统架构概览

2. Android系统架构概览

Android 并不是一个“从零写起”的操作系统，而是一个在 Linux 内核之上逐层叠加、逐层抽象的系统栈。理解这套分层结构，是学习 System Service 开发的第一块基石：只有先看清每一层“负责什么、暴露什么、依赖什么”，才能判断一个系统服务应该放在哪一层、通过什么接口对外提供能力，以及它最终如何被应用层调用。

一、核心原理：五层结构，自下而上逐级抽象

从下往上，Android 系统栈可以划分为五个关键层次，每一层都向上层提供更“友好”的抽象，同时隐藏下层的复杂性：

Linux 内核层：负责进程调度、内存管理、文件系统、网络协议栈、电源管理，以及 Binder、Ashmem、Logger 等 Android 特有驱动。它是整个系统的“地基”，也是安全隔离与资源管理的基础。
HAL 层（硬件抽象层）：以一组标准接口（如 Camera HAL、Audio HAL、Sensor HAL）屏蔽不同芯片与硬件的差异，让上层不必关心具体硬件实现。Android 8.0 之后普遍采用 HIDL/AIDL 化的 HAL，可运行在独立进程中。
Native 层：由 C/C++ 编写的本地库与原生守护进程组成，例如 libc（Bionic）、libbinder、libutils、SurfaceFlinger、MediaServer、init 等。它直接与内核和 HAL 交互，是性能敏感逻辑的落脚点。
Framework 层（Java API 框架）：以 Java/Kotlin 为主，向应用提供 ActivityManager、WindowManager、PackageManager、LocationManager 等管理类，以及 Binder 代理、消息循环等基础设施。
System Service 层：运行在 system_server 等系统进程中的常驻服务，如 ActivityManagerService、PackageManagerService、WindowManagerService。它们通常由 Framework 层封装成 Manager 供应用调用，是“系统能力的真正实现者”。
应用层：普通 App 与系统 App，通过 Context.getSystemService() 拿到 Manager，再经由 Binder 跨进程调用到 System Service。

  关键理解：Framework 层的 Manager 往往只是“代理/门面”，真正的逻辑在 System Service 中；而 System Service 又常常依赖 Native 层与 HAL 才能完成实际工作。

二、方法流程：一次系统调用的完整旅程

以“应用获取当前电量”为例，可以清晰看到各层的协作顺序：

应用层调用 getSystemService(Context.BATTERY_SERVICE)，拿到 BatteryManager。
Framework 层的 BatteryManager 通过 Binder 代理，向 system_server 中的 BatteryService 发起跨进程请求。
BatteryService 读取来自 Native 层 healthd / HealthService 上报的电量数据。
Native 层通过 HAL 接口（如 health HAL）访问内核的电源管理节点。
Linux 内核驱动返回真实硬件状态，数据沿原路逐层回传，最终以 Java 对象形式返回给应用。

App
 └─ BatteryManager.getIntProperty(BATTERY_PROPERTY_CAPACITY)
     └─ Binder Proxy ──► system_server: BatteryService
         └─ HealthService (Native)
             └─ android.hardware.health HAL
                 └─ /sys/class/power_supply/battery/capacity (Kernel)

三、案例场景：System Service 在架构中的位置

假设我们要新增一个“设备温度监控服务”，它需要读取温度传感器并对外提供查询接口。按照分层原则，合理的落点是：

内核层：温度传感器驱动，暴露 /sys/class/thermal/ 节点。
HAL 层：定义 IThermal HAL 接口，封装节点读取逻辑。
Native 层：实现 HAL 客户端，将原始数据转换为结构化温度值。
System Service 层：新增 ThermalService，注册到 ServiceManager，提供 getTemperature()。
Framework 层：提供 ThermalManager 作为门面，封装 Binder 调用。
应用层：通过 getSystemService() 获取并调用。

判断服务该放哪一层，可以问三个问题：它是否需要直接操作硬件？是否需要跨进程共享？是否要暴露给普通 App？答案会自然指向 HAL、System Service 或 Framework。

四、误区与复盘：常见理解偏差

常见误区	正确理解
Framework 层就是 System Service 层	Framework 是 Java API 门面，System Service 是运行在系统进程中的实现，二者是“接口与实现”的关系。
HAL 只是几个 .so 库	现代 HAL 多为独立进程，通过 HIDL/AIDL 通信，具备版本管理与进程隔离能力。
应用可以直接调用 Native 层	普通应用受权限与 SELinux 限制，通常必须经由 System Service 暴露的接口访问底层能力。
System Service 只能有一个	除 system_server 中的核心服务外，还存在大量独立系统进程中的服务，如 MediaServer、SurfaceFlinger。

复盘要点：分层不是“越往下越底层”这么简单，而是“每一层只解决一类问题”。System Service 开发的核心，就是在正确的层做正确的事，并通过 Binder 把能力安全、稳定地暴露给上层。

掌握这套分层关系后，后续学习 Binder 机制、system_server 启动流程、服务注册与获取时，就能把每个知识点准确“挂”到对应层级上，形成清晰的知识地图。