第2章车载Linux架构概览

第2章车载Linux架构概览：从应用层到硬件层的完整软件栈、HAL在其中的位置

好，咱们直接切入正题。上一章我聊了聊为什么要做HAL，这一章咱们把视野拉高一点，看看整个车载Linux的软件栈长什么样。说白了，就是搞清楚你的代码到底跑在哪个位置，上下左右都跟谁打交道。

我刚开始做车载项目那会儿，拿到一块开发板，第一反应就是往上怼应用。结果呢？底层驱动一换，应用全崩。后来我才明白——你得先看懂这张“地图”。

2.1 车载Linux的完整软件栈

车载Linux的软件栈，从顶到底，大致可以分成这么几层：

层次	典型组件	说明
应用层	仪表盘、中控、ADAS、语音助手	用户直接看到的界面和功能
应用框架层	Android Automotive、AGL、Qt、Wayland	提供应用运行环境和窗口管理
系统服务层	音频管理、网络管理、传感器服务	封装底层能力，向上提供API
硬件抽象层（HAL）	Camera HAL、Audio HAL、Sensor HAL	屏蔽硬件差异，提供统一接口
内核层	Linux Kernel + 设备驱动	直接操作硬件寄存器
硬件层	SoC、传感器、显示屏、CAN总线	物理设备

你想想看，一个语音指令“打开空调”，从应用层一路往下，经过框架、服务、HAL、内核，最后才到硬件。每一层都有它的职责，也都有它的坑。

核心观点：HAL是软件与硬件之间的“翻译官”。它不负责业务逻辑，只负责把硬件的“方言”翻译成系统能听懂的“普通话”。

2.2 各层职责详解

2.2.1 应用层

这是用户直接接触的部分。仪表盘显示车速、中控屏播放音乐、HUD投射导航信息。应用层只关心“我要做什么”，不关心“底层怎么实现”。

我个人习惯，在应用层尽量不碰硬件相关的代码。一旦碰了，换硬件时你就得改应用，那维护成本就上去了。

2.2.2 应用框架层

这一层提供应用运行的基础设施。比如Android Automotive的CarService，或者AGL的Home Screen。它管理窗口、处理事件、调度应用生命周期。

我记得有一次，客户抱怨中控屏切换应用卡顿。查了半天，发现是Wayland的合成器配置不对，跟HAL没关系。所以啊，框架层的问题往往比HAL更隐蔽。

2.2.3 系统服务层

系统服务层是“承上启下”的关键。比如音频服务，它要管理多个音频流（导航、电话、媒体），决定谁优先。它调用Audio HAL来操作硬件，但自己不直接操作寄存器。

这里有个避坑指南：我曾经见过一个项目，系统服务层直接调用了驱动接口，结果驱动一升级，服务全崩。正确的做法是——服务层只跟HAL打交道。

2.2.4 硬件抽象层（HAL）

嗯，这就是咱们课程的核心了。HAL的作用，说白了就是“标准化”。不管你是用NXP的i.MX8，还是瑞萨的R-Car，HAL提供的接口是一样的。

举个例子，Camera HAL。不管摄像头是OV5640还是IMX219，HAL都提供open()、start()、stop()、close()这几个接口。上层应用不需要知道摄像头型号，只需要调用这些接口就行。

我的经验：设计HAL接口时，尽量参考Android的HAL风格。虽然咱们做的是车载Linux，但Android HAL的接口设计经过了大量验证，值得借鉴。

2.2.5 内核层

内核层包含Linux Kernel和设备驱动。驱动直接操作硬件寄存器，处理中断，管理DMA。这一层是HAL的下层依赖。

HAL通过系统调用（如ioctl、mmap）与内核驱动通信。所以，HAL的设计必须考虑内核驱动的接口风格。

2.2.6 硬件层

物理设备。SoC、传感器、显示屏、CAN控制器。硬件层的差异是HAL存在的根本原因。

2.3 HAL在软件栈中的位置

咱们用一张图来理解HAL的位置：

+------------------+
|    应用层         |
+------------------+
|  应用框架层       |
+------------------+
|  系统服务层       |
+------------------+
|  **HAL层**       |  <-- 你在这里
+------------------+
|  内核层（驱动）   |
+------------------+
|  硬件层           |
+------------------+

HAL夹在系统服务层和内核层之间。它向上提供稳定的API，向下适配不同的硬件驱动。

为什么会这样设计？你想想看，如果系统服务层直接调用驱动接口，那换一个硬件平台，所有服务都得重写。有了HAL，换硬件只需要换HAL的实现，上层代码纹丝不动。

注意：HAL不是万能的。它只能屏蔽硬件差异，不能屏蔽功能差异。比如，一个硬件支持HDR拍照，另一个不支持，HAL接口可以设计成“支持HDR”和“不支持HDR”两种模式，但不能让不支持的硬件强行支持。

2.4 一个实际例子：音频通路

咱们拿音频来举个例子。车载音频的路径很复杂：导航、电话、媒体、语音助手，这些音频流要混音、要切换、要优先。

在系统服务层，音频服务管理这些流。它调用Audio HAL的接口：

// Audio HAL 接口示例
int audio_hal_open(audio_device_t *dev);
int audio_hal_set_volume(audio_device_t *dev, float volume);
int audio_hal_start(audio_device_t *dev);
int audio_hal_stop(audio_device_t *dev);

Audio HAL内部再调用内核的ALSA驱动或ASoC驱动。不同的SoC，ALSA驱动实现不同，但Audio HAL的接口不变。

我在项目中遇到过一个问题：某款SoC的ALSA驱动不支持同时播放两个音频流。上层音频服务不知道这个限制，结果导航和音乐同时播放时，系统崩溃。解决方案就是在Audio HAL里做一层“虚拟混音”，把两个流合并成一个再送给驱动。

你看，这就是HAL的价值——它可以在不修改上层代码的情况下，解决底层硬件的限制。

2.5 小结

这一章咱们把车载Linux的软件栈捋了一遍。从应用层到硬件层，每一层都有自己的职责。HAL在中间，扮演着“翻译官”和“缓冲层”的角色。

记住几个要点：

HAL向上提供稳定API，向下适配硬件驱动
HAL不处理业务逻辑，只处理硬件差异
设计HAL时，要考虑内核驱动的接口风格
HAL可以解决硬件限制，但不能创造硬件不存在的功能

下一章，咱们开始动手设计一个简单的HAL。从需求分析到接口定义，一步步来。

一句话总结：HAL是车载Linux软件栈的“腰”，腰不好，整个系统都站不稳。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录