第二章 系统架构总览：整体分层架构图、各层职责说明、核心组件介绍

好，咱们正式开始聊架构。说实话，很多初学者一上来就盯着代码看，结果越看越懵。我个人的习惯是——先看地图，再走路。Android Automotive 这套系统，说白了就是一个巨大的分层蛋糕。你只有知道每一层是干嘛的，出了问题才知道该去翻哪里的代码。

2.1 整体分层架构图

先给你一张我脑子里的图（嗯，你可以在纸上画一下）：

┌─────────────────────────────────────────────┐
│             车载应用层 (Apps)                 │
│   (地图、音乐、电话、设置、车辆控制...)       │
├─────────────────────────────────────────────┤
│           Android Framework                  │
│   (ActivityManager, WindowManager,          │
│    CarService, VehicleHalService...)         │
├─────────────────────────────────────────────┤
│           硬件抽象层 (HAL)                    │
│   (Vehicle HAL, Audio HAL, Camera HAL...)   │
├─────────────────────────────────────────────┤
│              Linux 内核层                    │
│   (驱动、电源管理、安全、网络栈...)           │
├─────────────────────────────────────────────┤
│               硬件层 (Hardware)              │
│   (SoC, 传感器, 显示屏, CAN总线...)          │
└─────────────────────────────────────────────┘

一共五层。从下往上，每一层都依赖下一层提供的服务。你想想看，这跟咱们平时做 App 开发是不是有点像？只不过 Automotive 多了一层专门跟车打交道的接口。

2.2 各层职责说明

2.2.1 硬件层

这层没什么好说的，就是物理设备。SoC、内存、屏幕、GPS、摄像头，还有最重要的——CAN 总线接口。我记得有一次在实车调试时，发现空调控制没反应，查了半天，最后发现是 CAN 总线上的一个电阻焊错了。嗯，硬件问题有时候就是这么坑。

2.2.2 Linux 内核层

内核层负责管理硬件资源。驱动、进程调度、内存管理、网络协议栈，这些都是它的活。在 Automotive 场景下，内核层有几个特别重要的点：

• 电源管理：车机不能像手机一样随便关机。休眠、唤醒、快速启动，这些都需要内核支持。
• 安全隔离：仪表盘和中控屏可能跑在不同的虚拟机里，内核要保证它们互不干扰。
• 实时性：有些车辆控制信号对延迟要求极高，内核需要提供实时调度能力。

2.2.3 硬件抽象层 (HAL)

HAL 层是连接内核和 Framework 的桥梁。它把内核驱动的接口封装成统一的 API，上层应用不需要关心底层用的是哪家的芯片。Android Automotive 定义了一套标准的 Vehicle HAL 接口，所有车厂都必须实现它。

举个例子：

// Vehicle HAL 接口示例
// 获取车速
int32_t getVehicleSpeed(VehiclePropValue_t* outValue);

// 设置空调温度
int32_t setHvacTemperature(int32_t zone, float temperature);

你看，上层调用这些接口时，根本不知道底层是走 CAN 总线还是走 LIN 总线。这就是抽象的好处。

2.2.4 Android Framework 层

这一层是 Android 的核心。它提供了应用运行所需的一切服务：

• ActivityManagerService：管理应用的启动、切换、生命周期。
• WindowManagerService：管理窗口的显示、层级、焦点。
• PackageManagerService：管理应用的安装、卸载、权限。
• CarService：这是 Automotive 特有的服务，负责跟车辆硬件交互，并把数据分发给上层应用。
• VehicleHalService：它是 CarService 和 Vehicle HAL 之间的桥梁。

说白了，Framework 层就是个大管家。应用想做什么事，都得通过它来协调。

2.2.5 车载应用层

最上面就是咱们用户能看到的界面了。地图、音乐、电话、设置、车辆控制……这些应用直接跟用户打交道。它们通过 Framework 提供的 API 来获取车辆数据或控制车辆功能。

举个例子，一个空调控制 App 的调用链路是这样的：

App (点击"温度+") 
  → Framework (CarService.getHvacTemperature()) 
    → VehicleHalService 
      → Vehicle HAL (setHvacTemperature()) 
        → 内核驱动 (CAN 总线发送指令) 
          → 硬件 (空调控制器执行)

你看，一个简单的操作，背后要经过这么多层。每一层都有它的职责，缺一不可。

2.3 核心组件介绍

这里我挑几个最重要的组件，单独拎出来说一下。

组件名称	所属层级	核心职责
CarService	Framework	管理车辆状态、分发车辆事件、提供车辆控制 API
VehicleHalService	Framework	桥接 CarService 和 Vehicle HAL，处理属性订阅/取消
Vehicle HAL	HAL	封装硬件驱动接口，提供标准化的车辆属性读写
CarAppService	Framework	管理车载应用的运行模式（如：驾驶模式、停车模式）
CarUserService	Framework	管理多用户（驾驶员、乘客）的权限和配置

另外，还有一个容易被忽略的组件——CarPropertyManager。它是应用层获取车辆属性的主要入口。比如你想知道当前车速、剩余油量、车门状态，都是通过它来查询的。

// 应用层获取车速示例
CarPropertyManager propertyManager = 
    (CarPropertyManager) car.getCarManager(Car.PROPERTY_SERVICE);

// 订阅车速变化
propertyManager.registerCallback(propertyCallback, 
    VehiclePropertyIds.PERF_VEHICLE_SPEED, 0);

嗯，代码看起来很简单对吧？但实际开发中，你可能会遇到回调不触发、数据延迟、属性值不对等各种问题。这时候就要一层层往下排查了。

2.4 小结

这一章咱们把 Android Automotive 的整体架构捋了一遍。从硬件到应用，一共五层。每一层都有明确的职责，层与层之间通过标准接口通信。我个人觉得，理解这个分层模型，比记住某个 API 怎么用要重要得多。因为架构决定了系统的上限，而代码只是实现细节。

下一章，咱们会深入 CarService 的内部实现，看看它到底是怎么跟车辆硬件打交道的。到时候我会分享一些我在实际项目中踩过的坑，保证让你少走弯路。