26、测试与调试：自动化测试框架、模拟器测试、真机测试、性能监控工具
说实话，做车机互联开发，最让人头疼的不是写代码，而是测试。你想想看，手机型号千千万，车机品牌各不同，再加上不同的Android版本、不同的互联协议版本……这排列组合下来，测试工作量简直吓人。
我最早做车机互联那会儿，团队就三个人，测试全靠手点。每次发版前，我们仨轮流拿着手机去车里坐着，连上CarPlay或者Android Auto，一个个功能点过去。夏天车里四十度，冬天冻得手抖。后来我实在受不了了，开始琢磨怎么把测试自动化。今天就把我这些年积累的测试调试经验，一次性倒给你们。
核心观点：车机互联的测试，不能只靠「人肉」。自动化测试框架 + 模拟器 + 真机 + 性能监控，四者缺一不可。
26.1 自动化测试框架选型
自动化测试框架，说白了就是让机器替你跑测试。车机互联场景下，我推荐三个方向：
- UI Automator：Google官方框架，适合做跨应用的车机互联UI测试。比如模拟用户点击「连接手机」按钮，检查弹窗是否正常。
- Espresso：轻量级，适合测试单个App内部的交互逻辑。比如测试手机端发送导航指令后，车机端是否正确解析。
- Appium：跨平台，支持iOS和Android。如果你的产品同时支持CarPlay和Android Auto，Appium可以一套脚本跑两边。
我个人习惯用UI Automator + Espresso的组合。为什么？因为车机互联涉及两个设备（手机和车机），UI Automator可以跨应用操作，而Espresso用来验证车机App内部的细节逻辑，分工明确。
我的经验：千万别想着一个框架搞定所有。我在项目中遇到过，团队非要统一用Appium，结果车机端的原生控件响应速度跟手机端不一样，脚本跑起来各种超时。后来改成UI Automator专门测车机端，Espresso测手机端，问题就解决了。
26.2 模拟器测试：没有车也能测
做车机互联开发，最尴尬的就是「车还没到，代码写完了」。怎么办？用模拟器。
Android Automotive模拟器，从Android Studio里就能直接创建。我建议你至少准备两个模拟器配置：
| 模拟器类型 | 用途 | 配置建议 |
|---|---|---|
| 标准车机模拟器 | 测试基础互联功能 | Android 12+，2GB RAM，1280x720 |
| 低配车机模拟器 | 测试性能瓶颈 | Android 10，1GB RAM，800x480 |
模拟器能测什么？
- 蓝牙配对流程
- WiFi直连握手
- 投屏协议的数据传输
- UI布局在不同分辨率下的表现
但注意，模拟器有局限。我记得有一次，模拟器上蓝牙配对一切正常，结果真机上死活连不上。查了两天才发现，模拟器的蓝牙芯片模拟层跟真机不一样，有些底层回调根本没触发。所以——
警告：模拟器测试通过，不代表真机没问题。模拟器只能覆盖60%的场景，剩下的40%必须上真机。
26.3 真机测试：避不开的硬仗
真机测试，才是车机互联开发的「照妖镜」。我总结了一套真机测试的「三步走」策略：
- 手机端选型：至少覆盖主流品牌（华为、小米、OPPO、vivo、三星），每个品牌选2-3款不同年份的机型。别只测旗舰机，中低端机才是用户主力。
- 车机端选型：如果条件有限，优先测市场占有率最高的3-5款车机。比如大众的MIB系统、比亚迪的DiLink、吉利的GKUI。
- 场景覆盖：不要只测「正常连接」场景。要测「连接中断后重连」、「手机来电时投屏是否卡顿」、「车机息屏再唤醒后连接是否还在」这些边缘场景。
我曾经踩过一个坑：某款手机在连接车机后，只要一打开微信语音，投屏就黑屏。后来发现是音频焦点抢占的问题。这种bug，模拟器根本测不出来，只有真机+真实使用场景才能暴露。
真机测试清单（我每次发版前必跑）：
- 蓝牙首次配对 & 自动重连
- WiFi直连传输延迟（< 100ms为合格）
- 投屏分辨率自适应（720p/1080p切换）
- 电话/微信语音打断后恢复
- 车机息屏30分钟后唤醒，连接状态
26.4 性能监控工具：用数据说话
测试不只是「能不能用」，还要看「好不好用」。性能监控，就是拿数据说话。
我常用的工具链：
- Android Profiler：Android Studio自带，监控CPU、内存、网络、电量。车机互联场景下，重点关注「投屏时的CPU占用率」和「蓝牙传输的内存抖动」。
- Systrace：抓取系统级trace，分析投屏延迟的瓶颈。比如是编码耗时，还是网络传输耗时，一目了然。
- Perfetto：Systrace的升级版，支持更长时间的抓取。我习惯用它来监控「连续投屏1小时」的性能表现。
- 自定义埋点：在代码里埋入关键节点的耗时统计。比如「从点击连接按钮到投屏画面出现，耗时多少毫秒」。这个数据，比任何工具都直观。
举个例子，我曾经用Systrace抓到一个问题：某款车机在投屏时，每5秒出现一次掉帧。查了trace发现，是车机端的GPU驱动在每5秒做一次垃圾回收。后来通过调整纹理缓存策略，把掉帧问题解决了。
小技巧：性能监控不要只看平均值，要看「P99延迟」。平均值好看，但偶尔一次卡顿就够用户骂娘了。P99能帮你抓到那些「虽然少，但很致命」的性能问题。
26.5 知识体系总览
下面这张图，是我对本章知识体系的总结。你可以把它当作测试调试的「作战地图」：
26.6 避坑指南
最后，分享几个我这些年踩过的坑，希望能帮你省点时间：
- 不要迷信自动化：自动化测试能覆盖80%的回归场景，但剩下20%的「诡异bug」，往往需要手动测试才能发现。比如某次车机在特定时间（下午3点）会自动断连，查了半天发现是车机系统的省电策略在作祟。
- 日志要打全：我习惯在关键节点打印「进入/退出」日志，配合时间戳。这样出问题时，看日志就能定位到是哪个环节卡住了。
- 性能基线要建立：每次发版前，跑一遍性能测试，把数据记录下来。如果某次发版后投屏延迟从80ms涨到了120ms，你就能立刻发现，而不是等用户投诉。
- 别忘了「负向测试」：比如手机电量低于20%时连接车机，会不会异常？车机存储空间满了，投屏会不会崩溃？这些场景，用户一定会遇到。
嗯，测试调试这块，说到底就是「多想一步，多测一遍」。你投入的时间，都会在线上稳定运行中得到回报。