3. 性能工程基础

在 Camera Display 系统中，性能问题往往不是“某个函数慢”这么简单，而是从 Sensor 出图、ISP 处理、显示合成到屏幕扫描的整条链路共同作用的结果。性能工程的目标，是把“感觉卡”“偶尔掉帧”“发热降频”这类模糊描述，转化为可量化、可复现、可验证的工程语言。本节围绕三个基础问题展开：用什么指标描述性能、用什么方法度量性能、以及如何把性能工作嵌入完整生命周期。

一、核心原理：性能指标是分层定义的

Camera Display 的性能指标不能只看一个 FPS。它至少分为三层：时延类、吞吐类和资源类。时延类关注“从事件发生到画面可见”的时间，例如快门到预览显示时延、拍照到缩略图出现时延；吞吐类关注单位时间完成的工作量，例如预览帧率、录像编码帧率、显示刷新率；资源类关注代价，例如 CPU/GPU 占用、DDR 带宽、ISP 负载、功耗与温度。

这三层之间存在耦合关系。提高预览帧率可能增加 DDR 带宽，带宽饱和又会导致帧率抖动；降低时延可能要求更激进的调度，进而抬高功耗。因此性能指标必须成组定义，而不是孤立追求某一项极值。工程上常用“目标值 + 约束值”的方式表达：例如预览目标 60fps，同时约束整机功耗不超过 3.5W、DDR 带宽占用不超过 70%。

二、度量方法：从埋点到统计

度量方法决定指标是否可信。Camera Display 常用四类手段：

• 时间戳埋点：在 SOF（Start of Frame）、ISP 输出、SurfaceFlinger 合成、Display VSYNC 等关键节点打时间戳，计算端到端时延。
• 计数器与直方图：统计丢帧数、jank 次数、帧间隔分布，避免只看平均值掩盖长尾。
• 系统级采样：用 perfetto、systrace、top、gpu 频率、DDR 带宽计数器观察资源竞争。
• 场景化压测：固定分辨率、帧率、亮度、温度与后台负载，重复运行取 P50/P95/P99。

下面是一段典型的帧间隔统计日志片段，用于判断是否存在周期性抖动：

frame_interval_ms: P50=16.7  P95=18.9  P99=33.4
jank_count: 12 / 1800 frames
dropped_frames: 7
display_vsync_miss: 5
ddr_bandwidth_peak: 78%

如果只看 P50，会认为 60fps 达标；但 P99 达到 33.4ms，说明存在偶发双帧间隔，用户仍可能感知到卡顿。因此度量必须同时报告中心趋势与长尾分布。

三、性能工程生命周期：把性能左移并闭环

性能工程不是发布前的“优化冲刺”，而是贯穿需求、设计、开发、集成、测试、发布与运维的闭环。其生命周期可概括为六个阶段：

1. 需求与预算：根据产品定位确定时延、帧率、功耗、带宽预算，并拆解到 Sensor、ISP、GPU、Display 各模块。
2. 架构与设计：选择 buffer 数量、合成方式、显示模式，评估是否满足预算，避免后期返工。
3. 开发与自测：在模块内建立埋点与基准用例，提交前跑通性能冒烟。
4. 集成与回归：在真实整机上跑场景化用例，对比基线，识别回归。
5. 发布与灰度：监控线上 jank、掉帧、温度与功耗，设置告警阈值。
6. 复盘与迭代：把问题沉淀为规则、工具与预算更新，进入下一轮。

这个闭环的关键是“基线”。没有基线，就无法判断一次改动是优化还是劣化。基线应包含硬件版本、软件版本、测试场景、环境温度与统计口径。

四、案例与场景：一次预览卡顿的定位

某项目在 4K 预览下出现偶发卡顿。团队先定义指标：预览帧率目标 30fps，P99 帧间隔不超过 40ms，DDR 带宽峰值不超过 75%。度量后发现 P99 达到 52ms，且 jank 集中在打开相机后 3 秒内。进一步用 systrace 观察，发现 ISP 输出与 GPU 合成争抢 DDR 带宽，导致 Display 合成错过 VSYNC。

优化措施包括：调整 buffer 数量减少拷贝、将部分合成任务提前、限制后台进程带宽占用。回归后 P99 降至 36ms，带宽峰值降至 68%。这个案例说明：指标定义 → 度量采集 → 根因定位 → 优化验证 → 回归监控 是性能工程的标准闭环。

五、常见误区与复盘清单

把性能指标、度量方法与生命周期三者结合，才能让 Camera Display 的性能工作从“救火”走向“可预测、可管理、可迭代”。