1. 课程导入
各位同学，咱们今天聊点实在的。Android Automotive 和仪表盘融合这件事，说白了就是要把车机里那个大平板和方向盘后面的仪表盘，变成一对配合默契的搭档。我最早接触这个领域是在 2018 年，那时候车厂还在纠结要不要用安卓做车机，更别提跟仪表盘通信了。现在呢？不融合都不好意思说自己是智能座舱。
1.1 Android Automotive 整体架构
先看整体架构。Android Automotive 不是手机安卓改个名那么简单。它的核心变化在底层——增加了汽车专用的硬件抽象层（VHAL），用来跟车辆控制单元打交道。
关键分层（从上到下）：
- 应用层：地图、音乐、电话、车辆设置——这些是用户直接看到的。
- 框架层：CarService、CarPropertyManager、CarSensorManager——负责把车辆数据抽象成 API。
- VHAL（Vehicle Hardware Abstraction Layer）：这是 Android Automotive 的灵魂。它定义了一组标准化的车辆属性（车速、转向角、续航里程等），供上层调用。
- HAL 实现层：各家芯片厂商（高通、瑞萨、NXP）自己实现 VHAL 接口，跟底层硬件通信。
- 硬件层：CAN 总线、以太网、LIN 总线——物理连接。
我习惯把 VHAL 比作一个翻译官。上层应用说我要车速，VHAL 就去 CAN 总线上把车速报文翻译成安卓能理解的属性值。没有这层，应用开发者得自己解析 CAN 报文——那画面太美我不敢看。
1.2 仪表显示系统（Cluster）的独立性与融合趋势
传统仪表盘是什么？一个独立的嵌入式系统。它有自己的 MCU、自己的 RTOS（比如 FreeRTOS、QNX）、自己的图形引擎。跟车机之间，最多通过 CAN 总线交换几个信号——车速、转速、油量。说白了，各玩各的。
但这两年趋势变了。为什么？
- 用户体验割裂：车机导航说前方 200 米右转，仪表盘上啥也没有。用户得扭头看中控屏——这不安全。
- 硬件成本压力：两套独立的 SoC、两套内存、两套显示链路——成本翻倍。
- 功能复杂度上升：AR 导航、ADAS 警告、充电状态——仪表盘需要显示的信息越来越多，传统 MCU 扛不住了。
所以现在的主流方案是什么？融合。但不是完全合并，而是分层次融合。
| 融合层次 | 典型方案 | 我见过的坑 |
|---|---|---|
| 数据融合 | IVI 通过以太网把导航信息推给 Cluster | 延迟抖动导致仪表指针卡顿 |
| 显示融合 | 单 SoC 双显示输出（IVI + Cluster） | 仪表屏刷新率要求高，GPU 调度冲突 |
| 系统融合 | 虚拟化：一个 SoC 跑两个 OS（Android + RTOS） | Hypervisor 的 GPU 虚拟化性能损耗 |
我的建议： 如果项目周期紧、安全要求高，先做数据融合。别一上来就搞虚拟化——那玩意儿调试起来能让你怀疑人生。
1.3 IVI 与 Cluster 的通信方式
通信方式决定了融合的深度和实时性。我按带宽从低到高给你捋一遍。
CAN / LIN 总线
这是老本行。CAN 总线带宽只有 500kbps 到 1Mbps，LIN 更慢，20kbps。传个车速、转向灯信号没问题，但传导航地图？别想了。
我曾经在一个项目里，客户坚持用 CAN 传导航箭头图标。结果呢？一张 32x32 的位图要拆成几十帧报文，传输延迟超过 200ms。用户都开过路口了，仪表盘才显示转弯——这能忍？
Ethernet（车载以太网）
现在的主流选择。100BASE-T1 或 1000BASE-T1，带宽 100Mbps 到 1Gbps。传导航地图、媒体信息、ADAS 警告——绰绰有余。
但以太网有个问题：实时性。标准 TCP/IP 协议栈的延迟不可控。所以车厂引入了 AVB（Audio Video Bridging）和 TSN（Time-Sensitive Networking）——说白了就是给以太网加了个“优先通道”。
注意： 用以太网传仪表数据时，一定要做带宽预算。我见过一个团队，把所有 IVI 数据都往以太网上塞，结果仪表屏的刷新率从 60fps 掉到 30fps——因为网络拥塞了。
虚拟化（Hypervisor）
这是终极方案。一个 SoC 上跑两个 OS：Android（IVI）和 RTOS（Cluster），通过虚拟化层共享硬件资源。通信不走物理总线，走共享内存——延迟可以做到微秒级。
我参与过一个基于 QNX Hypervisor 的项目。Android 跑在虚拟机里，Cluster 跑在原生 QNX 上。两者通过 ivshmem（Inter-VM Shared Memory）通信。效果确实好，但调试难度也大——一个 bug 可能同时涉及 Android 驱动、Hypervisor 配置、RTOS 任务调度，三方扯皮是家常便饭。
1.4 知识结构总览
下面这张图，是我自己画的知识结构。你把它存下来，后面每章都会用到。
1.5 避坑指南
最后，分享几个我踩过的坑，你以后大概率也会遇到。
坑一：VHAL 属性定义不统一
我曾经在一个项目里，IVI 团队和 Cluster 团队各自定义了一套车速属性。IVI 用 VehicleProperty::PERF_VEHICLE_SPEED，Cluster 用 VehicleProperty::VEHICLE_SPEED。结果两个系统显示的车速差了 3km/h——因为一个取的是轮速换算值，一个取的是 GPS 值。后来我们强制统一了属性定义，并在 VHAL 层做了数据源路由。
坑二：以太网 QoS 配置遗漏
用 AVB 传仪表数据时，一定要给仪表流打上最高优先级标签（SR class A）。我见过一个团队忘了配，结果仪表数据跟 OTA 下载抢带宽——仪表屏直接卡成 PPT。
坑三：虚拟化场景下的 GPU 抢占
如果你用虚拟化方案，Cluster 的 GPU 渲染任务必须绑定到专用 GPU 核上。否则 Android 的 UI 动画会抢占 GPU 时间片，导致仪表指针渲染掉帧。嗯，这个坑我调了整整两周才找到根因。