1. 课程导入

Camera Display 系统是智能手机、智能座舱、AR/VR 眼镜、安防监控等设备中用户感知最直接的子系统之一。它把传感器采集的光信号，经过 ISP 处理、显示合成、面板驱动，最终变成人眼看到的一帧画面。性能工程关注的不是"能不能显示"，而是"显示得是否及时、稳定、清晰、省电"。本课程围绕这条链路，建立一套可测量、可定位、可优化的性能工程方法。

一、学习目标

完成本课程后，你应当具备以下能力：

• 建立全链路视角：能够画出从 Sensor 曝光到 Panel 发光的完整数据通路，并识别每一级的时延、带宽与功耗贡献。
• 掌握关键指标：理解帧率、端到端时延、抖动、丢帧率、显示延迟、功耗等指标的定义、测量方法与相互关系。
• 具备定位能力：面对"预览卡顿""拍照慢""滑动不跟手""发热降帧"等现象，能用数据把问题收敛到具体模块。
• 形成优化闭环：能够提出假设、设计实验、采集 trace、验证收益，并评估优化对画质与功耗的副作用。

二、核心概念

Camera Display 系统的性能问题，本质上可以归结为三类资源的竞争：时间、带宽和能量。时间决定流畅度，带宽决定分辨率与帧率的可达上限，能量决定设备能持续多久以及是否会因发热而降频。

几个必须建立直觉的概念：

• 端到端时延（E2E Latency）：从光子进入 Sensor 到像素在 Panel 上发光的时间。它由曝光、读出、ISP、合成、传输、扫描等多段组成，是"跟手"体验的决定因素。
• 帧率与帧间隔：帧率是平均值，帧间隔的稳定性才决定主观流畅度。60fps 平均但偶发 33ms 长帧，用户仍会感到卡顿。
• 流水线并行：Camera 与 Display 都是流水线，理想状态下各级同时工作。性能优化的关键是让流水线"填满"，而不是让某一级空转。
• 带宽预算：分辨率 × 帧率 × 位深 × 通道数决定数据量，任何一级带宽不足都会造成丢帧或压缩伪影。
• 功耗墙与热墙：持续高帧率会推高 SoC 与 Panel 温度，触发降频降帧，形成"先快后慢"的体验劣化。

三、整体框架：一条链路、四个层次

本课程把系统拆成"采集—处理—合成—显示"四个层次，并在每一层上同时考察时延、带宽、功耗三条主线。下图给出整体框架与关键观测点，后续章节将逐层展开。

这张框架图有三个使用要点。第一，横向看链路：任何一次卡顿都要先判断发生在哪一层，而不是笼统地说"相机慢"。第二，纵向看主线：同一层可能时延合格但带宽吃紧，也可能带宽充足但功耗超标，三条主线要分别核对。第三，看观测点：每一层都标注了可采集的关键数据，性能分析必须落到这些具体信号上。

四、方法流程：从现象到结论

性能工程有一套相对固定的工作流程，建议在课程学习中反复套用：

1. 定义现象：把用户描述转成可量化指标，例如"滑动不跟手"转为"预览端到端时延 > 120ms"。
2. 建立基线：在稳定条件下采集一组基准数据，作为后续对比参照。
3. 分段测量：沿链路逐级打点，找出耗时或带宽占比最大的环节。
4. 提出假设：针对瓶颈给出可验证的原因，例如"ISP 降噪算法在大分辨率下超时"。
5. 设计实验：只改变一个变量，观察指标变化，排除干扰因素。
6. 评估收益与代价：确认优化是否影响画质、功耗或稳定性。
7. 固化与回归：把有效方案写入配置或代码，并加入回归测试防止反弹。

五、典型场景与常见误区

以一个常见场景为例：某手机在 4K 预览时出现周期性卡顿。按框架排查，采集层读出正常，处理层 ISP 单帧耗时从 12ms 涨到 22ms，合成层因等待而丢帧，显示层刷新率被迫降到 30Hz。结论是 ISP 在大分辨率下降噪算法超时，而非显示或 Sensor 问题。若一开始就盯着 Panel 调刷新率，方向就错了。

初学者常见的误区包括：

• 只看平均值：平均帧率达标但长帧频发，体验依然差，必须看分位数与抖动。
• 只优化单点：把 ISP 提速后，瓶颈转移到合成或传输，整体收益有限，需要全链路视角。
• 忽视功耗与热：短时性能提升可能换来持续降频，长期体验反而更差。
• 缺少对照实验：同时改多个参数，无法判断哪个改动真正起作用。

六、关键指标速查清单

七、一个可复用的采集示例

实际分析中，常用 trace 工具抓取关键阶段耗时。下面是一段示意性的采集命令与输出片段，用于说明"分段测量"的落地方式：

# 抓取相机预览链路的帧级耗时
trace_capture --category camera,display,gfx --duration 10s -o preview_trace

# 输出片段（示意）
frame_id   sensor_read   isp_total   compose   present   e2e
  1024        8.2ms       12.4ms      3.1ms     2.0ms   25.7ms
  1025        8.3ms       21.9ms      3.0ms     2.1ms   35.3ms  <-- 长帧
  1026        8.1ms       12.6ms      3.2ms     2.0ms   25.9ms

从输出可以直观看到，长帧的增量几乎全部来自 isp_total，这就把问题收敛到了处理层。后续章节会详细讲解如何解读这类 trace、如何区分算法耗时与内存等待，以及如何在不牺牲画质的前提下压缩 ISP 处理时间。

本章建立了课程的整体坐标系：一条从采集到显示的链路，四个层次，三条主线，以及一套从现象到结论的工作流程。后续每一章都会在这张框架图上落位，逐步把每个模块的指标、测量方法和优化手段讲透。学习时建议始终带着这张图去理解新内容，明确当前讨论的是哪一层、哪条主线、哪个观测点。