项目实战：从零搭建车载信息娱乐系统
说实话，讲到这里，终于到了我最想聊的部分。前面29章，我们一直在拆解Android Automotive的各个模块，从HAL到CarService，从多屏显示到音频策略。但很多朋友学完后会问：这些东西怎么串起来？
嗯，今天我们就来干这件事——从零开始，搭建一个完整的车载信息娱乐系统。我会带着你走一遍完整的流程：需求分析、架构设计、开发集成、测试交付。这可不是纸上谈兵，是我在几个量产项目中踩过坑后总结出来的实战路径。
核心观点：车载系统开发不是写代码，而是做决策。每一个架构选择，都直接影响后续的集成难度和交付质量。
1. 需求分析：别急着写代码
我见过太多团队，拿到项目就开干。结果做到一半发现，客户要的是A，我们做的是B。为什么会这样？因为需求没理清楚。
车载信息娱乐系统的需求，我习惯分成三层：
- 功能需求：用户能做什么？比如导航、音乐、电话、车辆设置。
- 性能需求：响应时间、启动速度、内存占用。举个例子，倒车影像必须在挂R挡后500ms内显示，这是硬指标。
- 非功能需求：稳定性、安全性、可维护性。车载系统不能死机，这是底线。
我在一个项目中遇到过，客户说“我们要一个音乐播放器”。结果深入聊才发现，他们要支持USB、蓝牙、在线流媒体、本地存储，还要支持无损格式。如果一开始没问清楚，后面改架构就痛苦了。
我的建议：需求阶段，一定要和产品、客户一起画用例图。把每个功能的触发条件、前置条件、后置条件写清楚。别怕麻烦，这一步省下来的时间，后面会加倍还给你。
2. 架构设计：分层是王道
车载系统架构，说白了就是分层。我常用的分层方式是这样的：
你看，这个分层结构其实不复杂。但关键点在于：每一层只做自己的事。应用层不直接访问硬件，HAL层不关心UI逻辑。这样做的好处是，换硬件时只需要改底层，换UI时只需要改上层。
3. 核心模块设计
接下来，我们挑几个核心模块聊聊设计思路。
3.1 多屏交互设计
现在的车，至少两块屏：仪表盘和中控。高端点的还有副驾屏、后排屏。多屏设计，我踩过最大的坑是焦点管理。
举个例子：用户在中控屏上操作导航，同时副驾在看视频。这时候语音助手说“导航到机场”，焦点应该给谁？
我的做法是：设计一个DisplayFocusManager，统一管理各屏的焦点状态。核心逻辑如下：
public class DisplayFocusManager {
private Map<Integer, Boolean> focusMap = new HashMap<>();
public boolean requestFocus(int displayId, String packageName) {
// 检查当前焦点是否被抢占
if (isFocusLocked(displayId)) {
return false;
}
focusMap.put(displayId, true);
return true;
}
public void releaseFocus(int displayId) {
focusMap.put(displayId, false);
}
private boolean isFocusLocked(int displayId) {
// 某些场景下，比如倒车影像，焦点必须锁定
return false; // 简化处理
}
}注意：多屏场景下，千万别让每个应用自己管理焦点。我曾经见过一个项目，每个应用都自己监听按键，结果按一下音量键，三块屏同时响应。用户体验极差。
3.2 音频策略设计
车载音频，比手机复杂得多。手机只有一种输出：扬声器或耳机。但车上有导航音、音乐、电话、提示音，它们可能同时播放。
Android Automotive提供了AudioPolicy机制。我一般这样配置：
<!-- audio_policy_configuration.xml -->
<audioPolicyConfiguration version="1.0">
<globalConfiguration speaker_drc_enabled="false"/>
<modules>
<module name="primary" halVersion="3.0">
<attachedDevices>
<item>Speaker</item>
<item>Headphones</item>
</attachedDevices>
<mixPorts>
<mixPort name="media" role="source">
<profile name="" format="AUDIO_FORMAT_PCM_16_BIT"
samplingRates="48000" channelMasks="AUDIO_CHANNEL_OUT_STEREO"/>
</mixPort>
<mixPort name="navigation" role="source">
<profile name="" format="AUDIO_FORMAT_PCM_16_BIT"
samplingRates="48000" channelMasks="AUDIO_CHANNEL_OUT_MONO"/>
</mixPort>
</mixPorts>
<routes>
<route type="mix" sink="Speaker" sources="media,navigation"/>
</routes>
</module>
</modules>
</audioPolicyConfiguration>这里的关键是：导航音和媒体音走不同的mixPort，但最终混音输出到同一个扬声器。这样导航播报时，音乐会自动降低音量，而不是被完全打断。
4. 开发与集成：从单模块到全系统
开发阶段，我习惯按模块并行推进。但集成阶段，一定要有清晰的节奏。
我常用的集成策略是：
- 第一阶段：各模块独立验证。比如Launcher能启动，Media能播放，Settings能调亮度。
- 第二阶段：模块间联调。比如Launcher点击音乐图标，能跳转到Media应用。
- 第三阶段：全系统集成。所有模块一起跑，模拟用户真实使用场景。
记得有一次，我们在第二阶段发现，导航应用启动时，音乐播放会卡顿一下。查了半天，原来是两个应用同时申请了音频焦点，但没有处理好优先级。这种问题，单模块测试是发现不了的。
5. 测试与交付：别让Bug上路
车载系统的测试，和手机完全不同。手机死机了重启就行，车机死机了，可能影响驾驶安全。
我一般把测试分成这几类：
| 测试类型 | 测试内容 | 工具/方法 |
|---|---|---|
| 功能测试 | 每个功能是否按需求实现 | 手动测试 + UI Automator |
| 压力测试 | 长时间运行、高负载场景 | Monkey + 自定义脚本 |
| 兼容性测试 | 不同硬件版本、不同分辨率 | CTS + VTS |
| 安全测试 | 权限、数据隔离、CAN总线安全 | 渗透测试 + 代码审计 |
一个小技巧：压力测试时，我习惯让系统连续运行72小时，同时记录CPU、内存、温度曲线。如果温度超过85度，基本可以判定散热设计有问题。这个经验来自一个项目，当时车机在夏天暴晒后直接黑屏，后来发现是散热没做好。
6. 交付：不是终点，是起点
交付不是把代码烧进去就完事了。真正的交付，包括：
- 文档交付：架构文档、API文档、测试报告、已知问题列表。
- 工具交付：刷机工具、日志抓取工具、诊断工具。
- 培训交付：给客户的技术团队做培训，告诉他们怎么排查问题。
我个人习惯，在交付前做一次全量回归测试。把之前所有测试用例跑一遍，确保没有引入新的问题。这一步很耗时，但值得。因为车载系统一旦交付，后续的OTA升级成本非常高。
7. 写在最后
从零搭建一个车载信息娱乐系统，听起来很复杂。但拆开来看，无非是需求、架构、开发、测试、交付这几个环节。每个环节都有坑，但只要你把基础打牢，遇到问题就不会慌。
嗯，这一章的内容就到这里。如果你在实际项目中遇到什么问题，欢迎随时交流。毕竟，车载系统开发这条路，一个人走太孤单了。