某头部自主品牌汽车厂商车展发布会交互系统：四套独立应用与展具联动

这是一个车展发布会现场的项目。甲方是一家头部自主品牌汽车厂商，要在展台上放一批可以让观众自己上手查询的交互终端，配合发布会讲解使用。

为什么是四套，而不是一套带四个模块

需求确认阶段有一个决定后面所有工作量的选择：这批内容是做成一套软件里的四个栏目，还是四套彼此独立的安装包。

最后定的是四套独立安装包：第一套是 HEV 展具交互，另外三套分别讲电池、电驱、发动机。

原因很实际。车展这种场合，展具是分散摆放的，每台设备守着自己那块展项，讲解动线也是分开的。做成一套大软件的话，现场每台机器都要装全量内容、再各自配置只显示哪一栏，出问题时排查链路更长；而发布会前的内容改动往往只涉及其中一个主题，独立包可以只重打一个，不影响另外三台。

代价是四套要各自维护一遍通用能力。所以通用部分做成了共享的底座，四套只是不同的业务包（flavor），从同一份工程里出四个产物。

现场参数与平台

• 主分辨率 2880×1920（横屏）——按展台实际配的屏幕定的，界面所有排版基于这个基准做。
• 适配平台：Android、iPad、Windows、HarmonyOS NEXT，以及兼容安卓的鸿蒙设备。

跨这么多平台是因为车展的设备来源不固定：有的展具配的是安卓一体机，有的是平板，主控位又是 Windows 电脑。软件得能跟着设备走，而不是反过来要求甲方统一采购。

四套通用的那些「展会必需品」

这些功能单看都不起眼，但少一个现场就要出洋相：

• 待机页循环播放图文/视频：没人操作时不能是黑屏或者停在某个二级页。
• 无操作超时返回待机：默认 300 秒，可配置。观众看完就走是常态，不会有人帮你退回首页。
• 中英文切换即时生效：车展有外宾。
• 崩溃自动恢复：这条是展会软件的命门。发布会现场没有人有空去重启程序，程序挂了必须自己爬起来。
• 全屏展会模式：不能露出任务栏、不能被误触最小化。
• 离线导入内容包：阶段一只做离线导入。展馆的网络环境不可控，把内容更新做成依赖网络的，等于把风险交给了别人。

第一套的展具联动：软件控软件

第一套 HEV 展具交互是四套里唯一需要跟外部设备打交道的。

它要支持「省 / 劲 / 静 / 模式原理」这几种模式切换。观众在触摸屏上点一个模式，现场要同时发生三件事：

1. 本机播放器切到对应的片子；
2. LED 电脑上的播控软件跟着切；
3. 展具本身的联动动作。

第二条是这个项目里比较关键的一处设计。LED 大屏不是由这台交互终端直接驱动的，它有自己的播放电脑。要让两块屏的画面对上，最直接的思路是把 LED 也接到这台机器上做扩展屏——但展台上两者物理位置隔得远，走线不现实。

所以走的是网络控播：交互终端通过 UDP 向 LED 电脑上的播控软件下发切换指令，UDP 优先、TCP 备选。

用 UDP 优先是因为这是局域网内的短指令，要的是低延迟——观众手指点下去，两块屏几乎同时换画面，中间那点延迟一旦上到几百毫秒，现场就会看出「大屏慢了一拍」。TCP 备选是兜底，遇到丢包敏感的场景可以切过去。

这里用的播控软件就是我们自研的企服君播控 SoftPlayer。它本身开放 UDP 命令通道，所以交互终端不需要知道 LED 那台机器的任何内部实现，发报文就行。

这个项目里值得记下来的经验

一是「四套独立包」的决定要在需求阶段就定死。 它影响的不只是打包方式，还有工程结构、内容组织、现场部署流程。等界面都做完了再改，等于重来。

二是展会软件的可靠性优先级高于功能丰富度。 崩溃自恢复、超时回待机、全屏锁定这三条，比多做两个炫酷动效重要得多。发布会只有那么几个小时，出一次事就是事故。

三是跨屏联动优先考虑网络控播，而不是物理扩展屏。 展台的走线条件通常比想象中差，能用一根网线解决的，别用 HDMI 延长器。而且网络控播天然支持一对多——后面如果再加一块屏，加个 IP 就行。