座舱多屏联动：延迟、冲突与适配

最近在实验室折腾多屏联动测试，踩了一些坑，记录一下。

现在的座舱动不动就三屏四屏，仪表、中控、副驾、HUD，各管各的显示，但数据又得互通。看起来挺酷，测起来就头疼了。

同步延迟

这是第一个坑。中控切导航路线，仪表上的箭头更新慢了半拍，体感上能察觉到。我们拿高速相机对着两个屏幕录，回来数帧，发现有些场景下延迟能到200毫秒往上。

最严重的是高负载场景。后台跑地图渲染的同时前台做触控操作，系统资源抢不过，UI线程被卡，响应时间直接翻倍。跟开发一块看trace，发现是渲染任务优先级没调好，关键路径上的UI更新被后台任务阻塞了。调整之后稍微好点，但彻底解决目前还没做到。

测试方法上我们用了两种：一种是插帧率统计工具看平均响应时间，另一种是固定场景人工体验做主观评价。客观数据达标的不一定体感就好，两个都得过。

交互冲突

副驾在调空调温度，主驾这边弹了个安全警告，副驾的操作就被打断了。逻辑上说得通，但用户很烦。还有多指操作，两个手指分别在不同屏幕上滑动，事件上报到系统之后顺序乱掉的情况也遇到过几次。

后来跟产品商量定了一套优先级规则：安全类 > 驾驶类 > 舒适类 > 娱乐类。安全警告触发时其他操作让路，这个没什么争议。但舒适和娱乐之间的边界有时候模糊，比如副驾看视频和主驾调座椅，谁优先？最后按屏幕位置走了，驾驶员侧的交互优先级高一些。

测试的时候把场景拆成组合来跑，两两组合、三三组合，看有没有交互被意外打断或丢失。

分辨率适配

屏幕来自不同供应商，同样是1080p的屏，显示效果和触控坐标映射都有差异。有一块屏的分辨率上报有问题，系统以为是1080p实际物理分辨率是别的，UI按1080p渲染出来，显示就偏了。

我们建了一个参数表，每块屏的分辨率、物理尺寸、触控IC型号、坐标映射关系都记下来。换屏之后先跑一遍适配验证，让系统重新识别屏幕参数，再跑基础用例确认没有问题。

硬件差异

不同屏的触控芯片方案不一样，有的敏感有的迟钝。同样的滑动操作，在屏A上流畅在屏B上就卡顿。还有屏幕刷新率不同导致的多屏刷新不同步，能看到明显的画面撕裂感。

这块目前没什么好办法，只能把触控灵敏度、响应曲线这些参数标准化，提前定好上下限，验收的时候逐一测量，超标的要求供应商调整驱动。

一点感想

多屏联动的很多问题其实不在应用层，在底层渲染管道和事件分发机制上。跟开发一起翻内核日志、调调度策略、改渲染优先级，比改测试用例管用得多。后面有新进展再记。