22、车载测试与调试：从模拟器到实车的全链路实战
车载系统开发，有一半时间其实都在跟测试打交道。这话一点不夸张。
我刚开始做 IVI 项目时，总觉得写代码才是核心，测试嘛，跑一遍就完事了。结果呢？第一次集成测试，启动时间超了 3 秒，直接被客户打回来。从那以后，我彻底明白了——测试不是收尾工作，而是质量的生命线。
今天咱们就聊聊车载测试与调试。我会把模拟器、实车、性能、自动化这几个维度串起来讲。你想想看，一个车载系统从代码到量产，中间要过多少道关卡？
核心观点：车载测试不是「测一下能不能用」，而是「测一下在各种极端条件下还能不能用」。多屏交互、传感器噪声、启动时间、内存泄漏——每一个都是坑。
一、模拟器测试：多屏与传感器模拟
模拟器测试，说白了就是「在电脑上假装自己是一台车机」。很多人觉得模拟器不准，但我的经验是——模拟器能帮你筛掉 80% 的显性 bug，剩下的 20% 才需要上实车。
1.1 多屏模拟
车载系统跟手机最大的区别是什么？多屏。仪表盘、中控、副驾屏、后排屏……每个屏幕的分辨率、刷新率、交互方式都不一样。
在 Android Studio 里，你可以这样配置多屏模拟器：
// 在 AVD 配置中，使用以下参数启动双屏
-emulator -avd MyCarAVD -screen-multi-display 1280x720/1920x1080
// 或者通过 adb 动态添加虚拟显示器
adb shell wm display create --display-type=virtual --size 1280x720
我的小技巧：我习惯在模拟器里同时开三个屏幕——中控、仪表、副驾。然后用 adb 分别截图对比，看布局有没有错位。有一次发现副驾屏的字体在 720p 下被截断了，幸亏在模拟器里提前发现，不然实车测试时又要被骂。
1.2 传感器模拟
车载系统依赖大量传感器：GPS、陀螺仪、加速度计、光线传感器……模拟器里怎么搞？
Android 模拟器自带传感器面板，但说实话，功能有限。我推荐用 sensorsimulator 工具，或者直接写脚本注入数据：
// 模拟 GPS 位置（北京天安门）
adb emu geo fix 116.397128 39.916527
// 模拟车辆速度（60 km/h）
adb shell dumpsys sensorservice --set-sensor 3 60.0
// 模拟光线变化（进入隧道）
adb shell dumpsys sensorservice --set-sensor 5 10.0
注意：模拟器的传感器数据是「理想值」，没有噪声。我曾经踩过一个坑——模拟器里导航一切正常，上了实车 GPS 信号飘得厉害，结果发现是天线位置不对。所以模拟器只能测逻辑，不能测硬件耦合。
二、实车测试环境搭建
实车测试，才是真正见真章的时候。我见过太多团队，模拟器跑得飞起，一上车就崩。为什么？因为实车环境太复杂了——电源波动、电磁干扰、温度变化……
2.1 硬件准备
- CAN 总线分析仪：用于模拟车辆信号（车速、车门、灯光等）
- 可编程电源：模拟车辆点火、ACC 通断、休眠唤醒
- 以太网交换机：连接车机、诊断仪、上位机
- USB 转串口模块：抓取底层日志
2.2 软件工具链
我个人习惯用这套组合拳：
| 工具 | 用途 | 备注 |
|---|---|---|
| adb + logcat | 抓取 Android 日志 | 配合 grep 过滤关键字 |
| CANoe / PCAN-View | 模拟 CAN 信号 | 商业工具，但值得投资 |
| systrace / perfetto | 性能追踪 | 分析启动时间必备 |
| Wireshark | 抓取以太网包 | 排查 SOME/IP 通信问题 |
避坑指南：我曾经在实车测试时，logcat 疯狂输出但找不到关键信息。后来发现是日志级别设错了。记住：实车测试一定要开 verbose 级别，并且把日志重定向到 U 盘，不然车机重启后日志就丢了。
三、性能测试：启动时间、内存、CPU
性能测试是车载系统的「硬指标」。客户不会关心你用了什么架构，他只关心——点火后几秒能看导航？
3.1 启动时间测试
启动时间分两种：冷启动（完全断电）和热启动（休眠唤醒）。
用 bootchart 可以精确分析每个阶段的耗时：
# 在车机上启用 bootchart
adb shell 'echo 120 > /data/bootchart/start'
# 重启后拉取数据
adb pull /data/bootchart/ bootchart_logs/
# 生成图表
pybootchartgui -f svg bootchart_logs/bootchart.tgz
我一般关注这几个阶段：
- Bootloader 到 Kernel：通常 2-3 秒，跟硬件相关
- Zygote 启动：1-2 秒，优化空间不大
- SystemUI 加载：1-3 秒，这里最容易优化
- Launcher 首帧：0.5-1 秒，用户体验的关键
3.2 内存与 CPU 监控
车载系统最怕什么？内存泄漏。跑着跑着卡死了，这可不是手机能重启就完事的。
# 实时监控内存
adb shell dumpsys meminfo com.android.car
# 抓取 CPU 使用率
adb shell top -n 1 -d 1 | grep "myapp"
# 使用 perfetto 录制 10 秒
adb shell perfetto -o /data/misc/perfetto-traces/trace.perfetto -t 10s sched freq idle
我的经验：内存泄漏往往在「长时间运行」后才暴露。我习惯让车机跑一个 72 小时的稳定性测试，每 30 分钟记录一次内存。如果内存曲线持续上升，那肯定有泄漏。别问我怎么知道的——我查过一个泄漏，原因是某个 Fragment 在销毁时没有释放 Sensor 监听器。
四、自动化测试框架：CarTest、CTS、VTS
手动测试终究不是长久之计。自动化测试框架，才是保证质量的根本。
4.1 CarTest
CarTest 是 Google 为 Android Automotive 提供的专用测试框架。它模拟车载特有的场景，比如：
- 车辆状态变化（停车、行驶、倒车）
- 多屏交互（主驾操作副驾屏）
- 音频焦点管理（导航打断音乐）
// 一个简单的 CarTest 用例
@Test
public void testNavigationDuringDriving() {
// 模拟车辆进入行驶状态
CarTestManager.setVehicleSpeed(60);
// 启动导航
onView(withId(R.id.nav_button)).perform(click());
// 验证导航界面显示
onView(withId(R.id.nav_map)).check(matches(isDisplayed()));
// 模拟车辆停止
CarTestManager.setVehicleSpeed(0);
}
4.2 CTS（Compatibility Test Suite）
CTS 是 Android 兼容性测试套件。你的车机如果想通过 Google 认证，CTS 必须全绿。
跑 CTS 其实很枯燥，但有几个关键点要注意：
- CTS 对硬件有要求：比如屏幕密度、内存大小，不满足直接 fail
- CTS 版本要匹配：Android 12 的 CTS 不能用在 Android 13 上
- 部分测试需要特定硬件：比如相机、蓝牙，模拟器里跑不了
4.3 VTS（Vendor Test Suite）
VTS 是给硬件厂商准备的。它测试的是 HAL 层、内核、驱动等底层组件。
说实话，VTS 的坑比 CTS 多。我遇到过最离谱的一次——VTS 测试因为某个 GPIO 引脚的电平时序不对而失败，查了三天才发现是硬件设计问题。
重要提醒：CTS 和 VTS 不是「跑一次就完事」的。每次系统升级、驱动更新、甚至只是改了某个配置文件，都要重新跑一遍。我建议把 CTS/VTS 集成到 CI/CD 流水线里，每天自动跑一次。
写在最后
车载测试，说到底就是「把问题消灭在量产之前」。模拟器帮你快速迭代，实车帮你验证真实场景，性能测试帮你守住底线，自动化框架帮你守住长期质量。
嗯，这四个维度缺一不可。你想想看，如果只做模拟器测试，上了实车才发现问题，那代价可就大了去了。
一句话总结：测试不是成本，是投资。你在测试上省下的时间，最终都会在客户投诉和召回上加倍还回来。