Android Perfetto 系列 18：响应速度实战，从输入事件到首帧反馈

按钮按下后，按压态何时出现？滑动列表时，内容何时第一次跟着手指移动？这两个状况都要找到输入事件和对应的第一帧反馈；启动总耗时与后续动画帧率回答的是别的问题。

本文用 Perfetto 把 InputReader 读到事件、InputDispatcher 派发、App 处理、帧提交和 SurfaceFlinger 呈现分开计时。每一步的起止点要能回到 Trace 核对。

从 InputReader 的 read_time 到关联帧 present，可以得到系统内部延迟的候选值 estimated_input_to_present_ms。只有确认目标 layer、业务狀態确实在那一帧发生视觉变化，才把它写成 input_to_present_ms。这段時間不包含触控 IC、驱动上报前延迟、显示扫描和面板响应。

点击和滑动还需要不同的终点定义：按压态、转场首帧和内容第一次位移不能混成一个数。App marker 能說明业务动作，高速相机可补外部可见时点。

Perfetto 系列文章

1. Android Perfetto 系列目录
2. Android Perfetto 系列 1：Perfetto 工具簡介
3. Android Perfetto 系列 2：Perfetto Trace 抓取
4. Android Perfetto 系列 3：熟悉 Perfetto View
5. Android Perfetto 系列 4：使用命令行在本地打开超大 Trace
6. Android Perfetto 系列 5：Android App 基于 Choreographer 的渲染流程
7. Android Perfetto 系列 6：为什么是 120Hz？高刷新率的亮点与挑战
8. Android Perfetto 系列 7：MainThread 和 RenderThread 解读
9. Android Perfetto 系列 8：深入理解 Vsync 机制与实力分析
10. Android Perfetto 系列 9：CPU 信息解读
11. Android Perfetto 系列 10：Binder 调度与锁竞争
12. Android Perfetto 系列 11：PerfettoSQL、Trace Processor 与回归检测
13. Android Perfetto 系列 12：Trace 数据流与丢失排查
14. Android Perfetto 系列 13：Perfetto SDK、Track Event 与 App 现场 Trace
15. Android Perfetto 系列 14：heapprofd 与内存 Profiling
16. Android Perfetto 系列 15：Boot Trace、长时段现场 Trace 与偶发状况抓取
17. Android Perfetto 系列 16：GPU、Power Counters 与硬件瓶颈分析
18. Android Perfetto 系列 17：专项场景自动化、问题清单与平台体系
19. Android Perfetto 系列 18：响应速度实战，从输入事件到首帧反馈
20. 影像(B站) - Android Perfetto 基础和案例分享
21. 影片(B站) - Android Perfetto 分享 - 出图类型分享：AOSP、WebView、Flutter + OEM 系统优化分享

从输入事件到第一帧反馈

旧的 Systrace 响应速度系列已经讲过广义响应慢：启动、页面跳转、亮灭屏、解锁、平台繁忙、Binder 等场景。流畅度系列讲连续帧是否稳定。Perfetto 系列第 07、08 篇又把 MainThread、RenderThread、Vsync、SurfaceFlinger 的帧路径拆过一轮。

一次点击的内部時間线可以按这些节点记录：

1
2
3
4
5
6
7
8

使用者输入
  -> InputReader 读到事件
  -> InputDispatcher 派发给方向窗口
  -> App 主线程收到 input
  -> App 处理 input 并请求下一帧
  -> RenderThread 提交 buffer
  -> SurfaceFlinger 合成并 present
  -> 核对目的视觉狀態后确认第一帧反馈

android_input_events.end_to_end_latency_dur 从 read_time 算到关联帧 present。标准库给出的关联仍是候选：is_speculative_frame=false 只表示输入处理切片与同线程 doFrame 相交，不能证明方向 layer 已发生视觉变化。下文 SQL 统一输出 estimated_input_to_present_ms；核对 frame token、目标 layer、actual present 和业务狀態后，才报告已确认的 input_to_present_ms。

如果用 event_time 或业务 marker 作为起点，报告要另列字段，不能和 input_to_present_ms 混在一起比较。

示意图：ACK 与帧显示是不同阶段；候选 present 还需结合 layer 和业务狀態确认，不能直接当使用者可见首帧。

响应慢要拆成四个指标

响应慢的讨论经常混在一起。开始分析前，先把同一次交互拆成四个指标。

第一次反馈的延迟和整个操作完成時間应分别报告。按压态很早出现、页面資訊稍后到达，与迟迟没有任何可见变化，用户使用感受可能不同；具体影响仍要结合场景和外部测量。

点击和滑动的终点也不一样：

• 点击按钮：终点可以是按压态 present、弹窗第一帧 present、页面转场第一帧 present。
• 点击会话：终点可以是会话页進入动画第一帧 present，也可以是第一條动态資訊绘制完成。
• 手指滑动：终点应该是内容第一次发生可见位移的 present。

Perfetto 能帮你定位操作系统内部時間，但“第一帧是否真的有视觉变化”经常需要 App marker 或外部视觉工具校准。

还要区分三个“输入时段”：

• event_time: 输入事件发生时段，比 read_time 更靠前，但仍不是触控固件、电信号或外部可见起点。
• read_time: InputReader 读到事件的时刻，android_input_events 的 end-to-end 字段从这里算到 present。
• dispatch_ts / receive_ts: InputDispatcher 发出事件、App 接收事件的時間，用来拆操作系统分发和 App 处理。

生成文章海報 / 分享 QR Code