外观
为什么帧率看起来平稳，操作仍然有延迟？
标准回答
帧率主要描述单位时间展示了多少帧，交互延迟描述一次输入多久后体现在屏幕上。两者可以不同：系统稳定显示每秒 60 帧，但这些帧如果在队列里等了较久，用户仍会觉得操作“跟手慢”。
当生产者持续产帧，而消费者尚未展示之前的内容时，待显示缓冲区可能积压。这会增加排队延迟；资源紧张时，生产者还可能等待可复用缓冲区。Perfetto 的 BufferStuffing 就与这种队列积压状态有关。
增加缓冲区可以在某些情况下改善流水线利用率，但也可能增加延迟，并不能让持续过载的系统无限吞下新帧。是否丢弃过时帧、等待或限制生产节奏，取决于具体队列与渲染策略。
因此排查跟手性时，除了看帧间隔和掉帧，还要把输入、业务状态、目标帧提交与实际展示串起来。主线程、GPU 和显示侧各自不慢，也不意味着它们之间没有排队。
关键机制
- “三缓冲”是常见理解方式，不是所有 Surface 固定三个缓冲区的普遍规则。
- 锁等待、GPU 完成等待与缓冲区归还等待需要区分，不能看到等待就认定 CPU 不够。
- 调优需要同时观察吞吐与延迟，避免只追求漂亮的平均帧率。
通俗例子
遥控滑块每次输入都生成新状态，但屏幕持续显示队列里的旧状态。画面可能很平滑，滑块却总落后手指一段距离。
追问与回答
提高刷新率能直接消除这种延迟吗？
不能保证。更高刷新率缩短了潜在显示间隔，但应用和显示链路必须跟得上，排队和同步等待仍然存在。如果产帧成本超过新的期限，反而可能增加错过时机的次数。应先找到延迟在输入、计算、队列还是展示，再决定如何优化。
易混淆点
积压不必然意味着每个事件都丢失；也不能未经证据就通过扩大队列解决。
参考资料
内容来源
- Android 技术札记 · 原条目
frame-backpressure