2. 智能座舱基础
智能座舱并不是“把更多屏幕塞进仪表台”，而是以座舱域控制器为核心，把仪表、中控、副驾、HUD、后排娱乐与电子后视镜等显示与交互终端统一编排，形成可感知、可计算、可迭代的移动数字空间。理解它的硬件架构与多屏交互方式，是后续讨论渲染性能工程的前提。
一、智能座舱的定义与能力边界
从工程视角看，智能座舱可定义为：以座舱域控制器（CDC）为计算与通信中枢，融合仪表、信息娱乐、抬头显示、后排娱乐、环视与语音/视觉感知，向驾乘者提供统一交互体验的车载系统集合。它通常具备四项核心能力：
- 多模态交互：触控、语音、手势、物理按键、方向盘控制并存，输入事件需要被统一分发。
- 多屏协同：不同屏幕共享内容、迁移应用、跨屏拖拽，同时保持各自刷新节奏。
- 安全分级：仪表与安全提示属于高优先级，娱乐与第三方应用属于低优先级，二者必须隔离。
- 可迭代：通过 OTA 更新应用与界面，硬件生命周期内持续演进。
需要强调的是，智能座舱与智能驾驶在计算平台上可能共享，但在实时性、功能安全等级与渲染优先级上要求完全不同。把仪表渲染与游戏渲染放在同一调度队列里，是典型的架构误区。
二、发展历程：从机械仪表到域集中
座舱电子大致经历四个阶段。第一阶段是机械与独立电子，仪表为指针式，中控仅收音机；第二阶段是分布式 ECU，仪表、空调、音响各自独立，屏幕小、交互弱；第三阶段是集中式信息娱乐，中控大屏与倒车影像普及，但仪表仍相对独立；第四阶段是座舱域集中，一颗 SoC 驱动多块屏幕，通过 Hypervisor 或容器实现仪表与娱乐的隔离。
这一演进带来的直接变化是：显示通道从“一对一”变为“一对多”，GPU 从“单屏合成”变为“多图层叠加”，性能问题也从“单应用卡顿”升级为“跨屏资源竞争”。
三、典型硬件架构与信号链
典型座舱域控的硬件链路为：SoC（CPU/GPU/DPU/NPU）→ 显示控制器 → 串行器（Serializer）→ 同轴线缆 → 解串器（Deserializer）→ 屏幕。多屏场景下，SoC 内部通过图层合成器把仪表、中控、HUD 等图层合成为不同输出流，再经各自显示通道送出。
图中可见，多屏并非简单复制输出，而是共享 GPU 与显示控制器资源。当副驾播放 4K 视频时，GPU 的合成带宽、显示控制器的通道带宽、内存带宽都会被占用，进而影响仪表帧率。
四、多屏交互场景与性能挑战
常见多屏交互场景包括：导航从中控滑到仪表、副驾视频与中控共享音频、倒车影像在挂挡瞬间覆盖中控、HUD 与仪表同步显示限速与报警。这些场景对性能提出三类挑战：
| 挑战类型 | 典型表现 | 关键资源 | 工程关注点 |
|---|---|---|---|
| 帧率竞争 | 副驾视频播放时仪表掉帧 | GPU、内存带宽 | 优先级调度、图层分离 |
| 延迟累积 | 触控到画面响应超过 100ms | 输入分发、合成链路 | 端到端延迟测量 |
| 带宽瓶颈 | 多屏 4K 输出时画面撕裂 | 显示通道、SerDes | 分辨率与刷新率匹配 |
| 隔离失效 | 娱乐应用崩溃影响仪表 | Hypervisor、容器 | 资源配额与故障域 |
五、一个可复用的分析流程
- 列出屏幕清单：分辨率、刷新率、色彩格式、安全等级。
- 标注数据流：每个屏幕的图层来源、合成位置、传输通道。
- 识别共享资源：GPU、内存带宽、显示控制器通道、SerDes 链路。
- 设定优先级：仪表 > HUD > 中控 > 娱乐。
- 压测验证：在副驾播放 4K、倒车影像触发等场景下采集帧率与延迟。
# 示例：采集多屏帧率与合成耗时（伪代码）
for screen in [cluster, center, passenger, hud]:
fps = read_fps(screen)
compose_ms = read_gpu_compose_time(screen)
if fps < target_fps[screen]:
log_warn(screen, "frame drop", fps, compose_ms)