4. 显示延迟的定义与测量

在实时交互系统中，用户感知的“卡顿”或“不跟手”往往并非单纯由帧率（FPS）决定，而是由显示延迟（Display Latency）主导。本章将系统定义显示延迟的三大阶段，并给出在RK3399平台上的工程化测量方法。

4.1 显示延迟的三阶段模型

从用户输入到屏幕像素更新，完整的显示延迟可分解为三个串行阶段：输入延迟、渲染延迟和显示传输延迟。下图展示了在RK3399双屏异构显示架构下的延迟流水线。

4.1.1 输入延迟（Input Latency）

从物理触摸/按键事件发生，到应用程序通过 read() 或 epoll_wait() 获取到输入事件的时间差。在RK3399上，主要受以下因素影响：

• 硬件扫描周期：触摸屏IC的扫描频率（通常100~250Hz）。
• 中断响应：GPIO中断触发到Input核心处理。
• 调度延迟：应用进程被唤醒的时间。

4.1.2 渲染延迟（Rendering Latency）

从应用开始绘制帧，到该帧通过 DRM atomic commit 提交到显示引擎的时间。包含：

• CPU绘制：Skia/OpenGL ES 命令生成。
• GPU渲染：Mali-T860 执行着色器、光栅化。
• 合成与排队：HWC（硬件合成器）或 SurfaceFlinger 合成，Buffer 入队等待。

4.1.3 显示传输延迟（Display Transmission Latency）

从显示控制器开始扫描一行，到像素在物理面板上稳定显示的时间。RK3399的VOP（Video Output Processor）通过DSI或HDMI接口输出，延迟包括：

• VOP扫描：帧起始到帧结束的扫描时间（约16.7ms @60Hz）。
• MIPI DSI传输：数据包串行化与传输（约1~3ms）。
• Panel响应：液晶分子翻转时间（通常5~15ms）。

4.2 延迟测量方法

针对不同阶段，需要采用不同的测量工具和手段。下表总结了RK3399平台上的推荐测量方案：

4.3 渲染延迟的软件测量：ftrace + DRM事件

在RK3399 Linux内核中，DRM驱动提供了精确的帧生命周期追踪点。以下步骤演示如何测量渲染延迟：

1. 启用DRM追踪点：

# 挂载debugfs并启用drm事件
mount -t debugfs none /sys/kernel/debug
echo 1 > /sys/kernel/debug/tracing/events/drm/drm_vblank_event/enable
echo 1 > /sys/kernel/debug/tracing/events/drm/drm_atomic_commit/enable

2. 捕获渲染流水线时间戳：

# 使用trace-cmd记录
trace-cmd record -e drm:drm_atomic_commit -e drm:drm_vblank_event \
  -e sched:sched_wakeup -e sched:sched_switch \
  -T -o trace.dat sleep 5

3. 解析关键时间点：

# 使用kernelshark或脚本解析
trace-cmd report trace.dat | grep "drm_atomic_commit"
# 输出示例：
#   chromium-1234 [000] ...1 12.345678: drm_atomic_commit: commit_id=42
#   chromium-1234 [000] ...1 12.361234: drm_vblank_event: crtc=0 seq=1234
# 渲染延迟 = 12.361234 - 12.345678 = 15.556ms

4.4 端到端延迟测量：高速相机法

对于用户可感知的总延迟，最直观的方法是使用高速相机拍摄屏幕与输入设备。下图展示了测量装置与流程：

测量步骤：

1. 在输入设备（如触摸屏）上粘贴一个LED，当触摸发生时LED立即点亮。
2. 使用高速相机（至少240fps，推荐480fps）同时拍摄LED和屏幕。
3. 逐帧分析视频：记录LED亮起的帧号 F_led，记录屏幕像素变化的帧号 F_screen。
4. 计算总延迟：Total Latency = (F_screen - F_led) × (1000 / fps) ms。

4.5 延迟测量对比总结

下表对比了不同测量方法的适用场景与优缺点，帮助你在RK3399调试中选择最合适的手段：