1. 课程导入
智能座舱正在从“单中控屏+机械仪表”快速演进为“仪表、中控、副驾、HUD、后排娱乐、电子后视镜”等多屏并存的移动计算平台。屏幕数量增加、分辨率提升、刷新率提高、动效复杂度上升，使渲染性能从“体验优化项”变成“系统交付门槛”。本课程围绕多屏渲染性能工程展开，目标不是记住若干零散技巧，而是建立一套可测量、可定位、可优化、可回归的工程方法。
一、核心概念：从“帧率”到“帧预算”
多屏渲染性能的第一性概念是帧预算。若某屏刷新率为 60Hz，则每帧只有 16.67ms；若为 120Hz，则只有 8.33ms。多屏同时渲染时，系统必须在同一时间窗口内完成多个独立显示通路的绘制、合成与提交。任何一路超时，都会表现为卡顿、撕裂、掉帧或触控延迟。
需要区分几个常被混淆的指标：
- FPS：每秒呈现帧数，反映流畅度，但会掩盖单帧尖峰。
- Frame Time：单帧耗时，关注 P95/P99 才能发现卡顿。
- Jank：帧未在预算内完成，导致画面更新延迟。
- Input Latency：从触控/语音事件到画面反馈的端到端延迟。
- GPU/CPU Load：资源占用率，需结合频率、带宽、功耗一起看。
多屏场景下，还要引入显示通路概念：每个屏幕都有独立的 Surface、合成器图层、显示控制器与时钟域。多屏不是“把单屏渲染做多份”，而是多个时序约束并行竞争同一套 GPU、内存带宽与总线资源。
二、方法流程：性能工程闭环
性能工程不是“出问题再救火”，而是一个闭环：定义指标 → 建立基线 → 采集数据 → 定位瓶颈 → 实施优化 → 回归验证。多屏场景下，基线尤其重要，因为不同屏幕组合、不同分辨率、不同动效负载会形成完全不同的资源竞争格局。
- 定义指标：明确每块屏的刷新率、分辨率、色彩格式与可接受延迟。
- 建立基线：在稳定版本、固定温度、固定亮度下采集 5～10 分钟数据。
- 采集数据：同时抓取应用帧、合成帧、显示提交与 GPU 计数器。
- 定位瓶颈：区分 CPU 绑定、GPU 绑定、带宽绑定、合成器绑定与显示绑定。
- 实施优化：降分辨率、降图层、改合成策略、错峰渲染、限制动效。
- 回归验证：用同一脚本、同一场景复测，确认 P95/P99 改善且无副作用。
三、典型场景与案例
假设某座舱同时点亮仪表 1920×720@60Hz、中控 2560×1440@60Hz、副驾 1920×1080@60Hz。用户反馈“打转向灯时中控导航卡一下”。初步采集发现：中控 FPS 从 60 掉到 42，仪表正常，副驾正常。进一步看 Perfetto，发现转向灯 3D 车模在仪表侧触发了一次大纹理上传，占满内存带宽，导致中控合成器等待 GPU 完成。
# 典型采集命令示例
adb shell dumpsys SurfaceFlinger --latency "com.example.navi"
adb shell dumpsys gfxinfo com.example.navi framestats
adb shell perfetto -c /data/misc/perfetto-configs/multiscreen.cfg -o /data/misc/perfetto-traces/trace.pftrace
这个案例说明：多屏性能问题往往不是“本屏应用写得差”，而是跨屏资源竞争。优化方向可能是把车模纹理改为压缩格式、把上传时机错峰到导航空闲帧、或把车模渲染降级为 2D 图层。
四、常见误区与复盘
| 误区 | 问题 | 正确做法 |
|---|---|---|
| 只看平均 FPS | 平均值掩盖 P99 尖峰，用户仍感知卡顿 | 同时看 P95/P99、Jank 次数与帧时间分布 |
| 把多屏当单屏做 | 忽略带宽、合成器与时钟域竞争 | 按显示通路分别建模，再做全局资源预算 |
| 盲目降分辨率 | 可能破坏 UI 清晰度与安全提示可读性 | 优先降图层、降动效、改合成策略，再考虑分辨率 |
| 优化后不复测 | 收益不可信，可能引入新瓶颈 | 固定场景、固定温度、固定脚本回归验证 |
五、学习路径
本课程共 30 章，建议按“基础指标 → 框架原理 → 多屏合成 → 资源竞争 → 工具链 → 优化实战 → 回归与交付”的路径推进。每章都会围绕一个可验证的性能问题展开，最终形成一套可复用的多屏渲染性能工程方法。你不需要一开始就掌握所有工具，但需要始终带着“帧预算”和“显示通路”两个视角去观察系统。
学习过程中，建议准备一台可复现的座舱开发板或模拟环境，固定一套多屏场景，持续采集同一组指标。性能工程的核心不是记住结论，而是建立用数据说话的习惯：先测量，再判断，后优化，最后回归。