仪表盘与 HUD 开发：仪表盘显示策略、HUD 投影技术、Android 与仪表交互
各位同学，今天我们来聊聊车载系统里最“显眼”的两个模块——仪表盘和 HUD。说实话，这两个东西是驾驶员每天看得最多的界面，也是安全要求最高的部分。我当年第一次接触仪表开发时，以为就是画几个圆盘指针，后来才发现，这里面的门道深着呢。
仪表盘显示策略：不只是“画个表”
仪表盘的核心任务，是把车辆状态信息清晰、实时地呈现给驾驶员。但这里有个矛盾：信息太多会分散注意力，太少又不够用。怎么平衡？
核心原则：仪表盘显示策略遵循“层级优先级”模型。关键安全信息（车速、转速、报警灯）永远在最顶层，次要信息（续航、里程）在第二层，娱乐信息（音乐、导航）在最底层。
我在项目中遇到过一个问题：客户要求仪表盘同时显示导航箭头、来电提醒、还有胎压数据。结果屏幕挤得跟手机通知栏似的。后来我们重新梳理了优先级，把导航箭头做成半透明悬浮，来电提醒只显示3秒自动消失，这才解决了视觉过载。
显示策略的三种模式
- 普通模式：显示车速、转速、油量/电量、里程。这是默认状态。
- 运动模式：转速表放大，增加G值显示，换挡提示。背景色变红。
- 简洁模式：只显示车速和关键报警灯，适合夜间或长途巡航。
你想想看，如果驾驶员在高速上巡航，他需要看转速表吗？其实不需要。所以简洁模式就是为这种场景设计的。我建议在开发时，把模式切换做成硬件按键或者方向盘快捷键，不要藏在触摸屏菜单里——安全第一。
HUD 投影技术：把信息“扔”到挡风玻璃上
HUD（Head-Up Display）说白了就是把仪表信息投影到挡风玻璃上，让驾驶员视线不用离开路面。这个技术最早用在战斗机上，现在下放到汽车里了。
HUD 的核心原理其实不复杂：一个高亮度LED光源，经过一组反射镜和透镜，把图像投射到挡风玻璃上。但难点在于——挡风玻璃是有弧度的，而且不同车型弧度不同。这就导致图像会变形。
避坑指南：我曾经在某个项目里，HUD 投影出来的车速数字是歪的，左边高右边低。查了两天才发现，是挡风玻璃的曲率补偿参数没算对。后来我们用了光学仿真软件，提前模拟不同玻璃曲率下的畸变，才彻底解决。
HUD 的两种主流技术路线
| 技术类型 | 原理 | 优点 | 缺点 |
|---|---|---|---|
| TFT 投影 | 用 TFT 液晶屏作为图像源，通过光学系统放大投影 | 成本低，技术成熟，色彩好 | 亮度受限，阳光下可能看不清 |
| DLP 投影 | 用数字微镜器件（DMD）反射光线 | 亮度高，对比度好，寿命长 | 成本高，体积大 |
我个人习惯在量产项目里优先选 TFT 方案，因为供应链成熟，出了问题好找替代。但如果是高端车型，DLP 的显示效果确实更胜一筹。
Android 与仪表交互：双屏通信的“暗号”
现在很多车都是“一芯多屏”架构——一个 SoC 同时驱动中控屏和仪表屏。但 Android Automotive 本身是为中控设计的，怎么让它和仪表盘通信呢？
嗯，这里要分两种情况：
- 同芯片方案：中控和仪表跑在同一个 SoC 上，通过 SurfaceFlinger 的图层分配来实现。仪表显示一个独立的 Surface，中控显示另一个。
- 异芯片方案：中控用 Android，仪表用 QNX 或 Linux。两者通过以太网或 CAN 总线通信。
我参与的一个项目就是异芯片方案。Android 端把导航信息打包成 protobuf，通过以太网发送给仪表端的 QNX 系统。QNX 解析后渲染到仪表盘上。这里有个坑：网络延迟。如果导航箭头晚了几百毫秒，驾驶员可能已经错过路口了。
注意：Android 与仪表通信的延迟必须控制在 100ms 以内。超过这个阈值，驾驶员会明显感觉到“卡顿”。我建议用 UDP 协议而不是 TCP，因为 TCP 的重传机制在实时性要求高的场景下反而坏事。
通信协议示例
下面是一个简化的 protobuf 定义，用于 Android 向仪表发送导航信息：
syntax = "proto3";
message NavigationInfo {
int32 distance_to_turn = 1; // 距离转弯还有多少米
string turn_instruction = 2; // 转弯指令，如"前方300米右转"
int32 current_speed = 3; // 当前车速，单位 km/h
bool is_highway = 4; // 是否在高速上
}仪表端收到这个消息后，解析出距离和指令，然后渲染到 HUD 或者仪表盘上。注意，车速信息其实仪表自己也能从 CAN 总线拿到，但这里从 Android 发过来是为了保证数据一致性——中控导航计算的车速和仪表显示的车速必须一致，否则驾驶员会困惑。
知识体系总览
我把本章的核心逻辑画了一张图，方便你理解整体架构：
这张图展示了三个模块之间的关系。仪表盘策略决定了“显示什么”，HUD 技术决定了“怎么投影”，Android 交互决定了“数据怎么传”。三者缺一不可。
实际开发中的几个建议
- 先做原型，再优化性能。 仪表盘和 HUD 的渲染性能要求很高（60fps 是底线），但一开始不要纠结优化，先把功能跑通。
- 重视模拟器测试。 我习惯在开发阶段用 Android 模拟器配合虚拟 CAN 总线来调试仪表逻辑，等基本功能稳定了再上真车。
- 留好日志接口。 仪表盘出问题很难复现，因为驾驶员不会告诉你“我在那个路口打了左转向灯然后仪表黑了”。所以日志要详细，最好能记录最近 30 秒的所有事件。
一个小技巧：在开发 HUD 时，可以用手机摄像头对准挡风玻璃录制视频，然后逐帧分析投影的稳定性和延迟。这个方法虽然土，但很有效。我当年就是这么发现投影图像有 2 帧抖动的。
好了，仪表盘和 HUD 的内容就讲到这里。记住，这两个模块是驾驶员和车辆之间的“最后一道防线”，代码质量直接关系到安全。写代码的时候多想想：如果这个信息显示错了，驾驶员会怎么做？