📚 课程目录第1章车载多屏互动概述

1. 车载多屏互动概述：项目背景、技术选型与核心交互场景

各位好，我是这次课程的主讲。做了十几年车载系统，从最早的单机导航到现在的多屏联动，我亲眼看着这块屏幕从「能亮就行」变成了「不流畅就挨骂」。今天咱们聊的，就是多屏互动这个项目到底在做什么，以及为什么值得你花时间学它。

一句话说清楚：车载多屏互动，就是让仪表、中控、副驾屏、后排屏这些设备，在同一个座舱里协同工作。数据共享、操作同步、体验一致——说白了，别让用户觉得每块屏都是孤岛。

大概从2018年开始，我注意到一个趋势：新车发布会上的屏幕数量，快赶上发动机缸数了。用户坐进车里，主驾看仪表、副驾追剧、后排打游戏——每块屏各玩各的，但数据却需要互通。

举个例子。导航时，中控设好目的地，仪表要显示路线指引，HUD要投射箭头。如果这三块屏各自为政，用户就得在中控设一次、在仪表再调一次。你想想看，这体验能好吗？

所以，多屏互动的核心驱动力就三点：

我记得2019年做某个量产项目时，客户要求「导航信息从中控投到仪表」。当时我们用了最粗暴的方式——截屏传输。结果延迟高、画质差，还被安全团队怼了一顿。嗯，从那以后我就明白了：多屏互动不是简单的「投屏」，而是一整套架构设计。

这是每次项目启动时必吵的架。我个人的习惯是：不迷信某个系统，只看场景需求。下面这张表是我这些年总结的选型参考：

维度	Android	Linux (Yocto/AGL)	QNX
生态丰富度	极高，应用多、开发快	中等，需自建	低，商业闭源
实时性	一般（有GC抖动）	较好（PREEMPT_RT）	极好（硬实时）
功能安全	不支持（需加Hypervisor）	部分支持（SEooC）	原生支持（ASIL-D）
多屏原生支持	Android 10+ 支持多Display	Wayland/Weston 多输出	Screen Graph 多屏管理
典型场景	中控娱乐、副驾屏	仪表、HUD、T-Box	仪表、ADAS、域控

实际项目中，我见过最多的方案是混合部署：QNX跑仪表（安全第一），Android跑中控（生态丰富），Linux跑网关或服务。你可能会问：那通信怎么办？别急，后面章节会详细讲DDS和Some/IP。

我的建议：如果项目预算充足、安全要求高，QNX+Android是黄金组合。如果成本敏感，全Linux方案也能做，但应用生态需要自己补。

场景决定了架构。我习惯把多屏互动拆成三个典型场景，每个场景对技术的要求都不一样。

这是最基础、也最刚需的场景。用户在中控输入目的地，路线信息要同步到仪表和HUD。这里的关键点有两个：

实现方式上，我推荐用共享内存+信号量的方案。如果是跨芯片通信，那就得上以太网AVB或DDS了。

副驾在追剧，想投到后排屏继续看。或者后排小孩在玩游戏，想切到中控大屏。这个场景的核心是媒体流同步。

嗯，这里有个坑。我记得2021年做某个项目时，副驾屏投到后排屏，视频流延迟差了500ms。用户说「画面和声音对不上」。后来排查发现，是编解码器参数没对齐。所以我的建议是：媒体流转一定要用统一的编解码配置，并且做时间戳同步。

这个场景最敏感。中控的导航信息要投射到仪表，但仪表是安全关键系统。你不能让中控的一个崩溃，把仪表也带挂了。

所以，隔离是第一位。我通常的做法是：

注意：仪表联动场景下，千万不要让中控直接控制仪表的渲染。我曾经见过一个方案，中控通过Socket发指令让仪表画箭头——结果中控死机，仪表画面卡死。这是严重的安全事故。

说了这么多，咱们用一张图把整个知识体系串起来。下面这张SVG图，展示了我认为最合理的多屏互动分层架构：

这张图我建议你多看几遍。后面的课程，基本上就是围绕这四层展开的。应用层讲场景设计，服务层讲业务逻辑，通信层讲数据交互，系统层讲底层适配。

好了，第一章的内容就这些。咱们快速回顾一下重点：