1. 课程导入
智能座舱的体验竞争，已经从“屏幕够不够大”转向“画面够不够顺、够不够稳、够不够省”。在一辆典型的中高端智能汽车里，仪表、中控、副驾娱乐、HUD、电子后视镜往往由同一颗座舱SoC驱动，GPU既要绘制3D车模、导航地图与游戏级动效，又要承担多图层合成、视频叠加与多屏输出。当帧率抖动、触控延迟、局部撕裂或功耗超标出现时，问题往往不在某一个API调用，而在“渲染—合成—显示”整条链路的资源竞争与调度策略。本课程正是围绕这条链路，建立一套可测量、可定位、可优化的性能工程方法。
学习目标：从“能画出来”到“可度量地画得稳”
完成本课程后，你应当具备四项可验证的能力：第一，能画出座舱GPU的完整数据通路，说清应用渲染、SurfaceFlinger类合成器、硬件合成器与显示控制器之间的职责边界；第二，能读懂并采集关键指标，包括帧时间、GPU占用率、合成器耗时、掉帧数、显示延迟与带宽占用；第三，能针对典型劣化场景给出分层排查路径，而不是盲目调参；第四，能建立性能预算模型，在分辨率、图层数、刷新率与功耗之间做工程取舍。
核心概念：渲染、合成、显示与同步
车载图形链路可以拆成四个层次。渲染指应用或系统UI通过OpenGL ES、Vulkan等API把图元画进缓冲区；合成指把多个图层按Z序、透明度、裁剪区域合并为最终扫描输出图像；显示指显示控制器按VSYNC节拍读取帧缓冲并驱动屏幕；同步则贯穿始终，决定缓冲区何时可写、何时可读、何时上屏。四者之间通过BufferQueue、Fence与时间戳解耦，任何一环阻塞都会以“掉帧”或“延迟”的形式暴露给用户。
需要特别区分两个易混指标：渲染帧率是GPU完成绘制的速率，显示帧率是屏幕实际刷新的速率。二者不一致时，合成器会重复或丢弃帧，表现为卡顿或抖动。另一个关键概念是合成方式：Client合成由GPU完成，灵活但耗算力；Device合成由专用硬件合成器完成，省电但受图层数量与格式限制。性能工程的核心工作之一，就是让尽可能多的图层走Device合成，同时保证视觉正确。
整体知识框架：三层能力，一条主线
课程内容按“原理—度量—优化”三层展开，但始终围绕一条主线：以帧为单位的端到端时间预算。原理层回答“数据怎么流动、同步怎么发生”；度量层回答“用什么工具、采什么指标、如何判定瓶颈”；优化层回答“在渲染、合成、显示、功耗四个方向分别能做什么”。三者不是并列关系，而是逐层收敛：没有正确的链路认知，指标会读错；没有可信的指标，优化就是碰运气。
| 能力层 | 关键问题 | 典型产出 |
|---|---|---|
| 原理认知 | 帧从应用到屏幕经过哪些阶段？ | 链路图、职责边界、同步模型 |
| 性能度量 | 瓶颈在哪一级？证据是什么？ | 指标基线、Trace分析、瓶颈判定 |
| 优化落地 | 改什么、改多少、代价是什么？ | 优化方案、预算表、回归验证 |
实战路线图：从采集基线到闭环验证
建议按五步推进。第一步，建立基线：在目标车型与固定场景下采集帧时间、GPU占用、合成耗时与掉帧数，形成可对比的初始数据。第二步，定位瓶颈：用系统级Trace把一帧拆成应用绘制、合成、上屏三段，判断是GPU算力、合成器图层数还是显示节拍问题。第三步，设计实验：每次只改一个变量，例如减少一个图层或切换合成方式，观察指标变化。第四步，验证收益：不仅看平均帧率，还要看P95/P99帧时间与抖动。第五步，固化回归：把关键场景与阈值写入自动化测试，防止后续版本劣化。
# 典型采集入口（示意，具体命令随平台而定）
dumpsys SurfaceFlinger --latency <layer> # 查看图层上屏时间戳
dumpsys gfxinfo <package> # 查看应用帧耗时分布
perfetto -c config.pbtx -o trace.perfetto # 抓取系统级Trace
cat /sys/class/drm/card0/.../gpu_busy # 读取GPU占用（路径随平台）典型场景与常见误区
一个高频场景是：中控导航滑动时偶发卡顿，但GPU占用并不高。此时若只盯GPU，很容易误判。真实原因可能是图层数量超过硬件合成器上限，导致部分图层回退到Client合成，合成器耗时突增；也可能是应用提交节奏与VSYNC错位，造成周期性丢帧。正确做法是先看合成方式占比与图层数，再看应用帧时间分布，最后才看GPU内部计数器。