Systrace 工具分析Input

这篇文章通俗地讲解了 Android 输入系统在 Systrace 中的工作流程和分析方法，核心是带大家看懂触摸事件从屏幕到应用的 “旅程”，以及如何通过系统追踪工具定位输入卡顿问题。以下是核心内容解读：

一、输入事件的 “快递运输系统”

Android 的输入处理就像一个快递配送网络，每个环节都有明确分工：

1. InputReader（快递分拣员） ：

   • 驻守在 SystemServer 进程，负责从触摸屏硬件读取触摸事件（如手指按下、滑动、抬起），就像从快递柜取出包裹。
   • 每 8ms 或 6.25ms（取决于屏幕采样率）扫描一次屏幕，生成 “快递单”（输入事件）。

2. InputDispatcher（快递派送员） ：

   • 从 InputReader 拿到事件后，按地址（应用窗口）打包整理，放入不同的 “快递车”（队列），派发给对应的 App。
   • 就像快递员按地址分类包裹，确保触摸事件准确送到目标应用。

3. 队列（快递堆放区） ：

   • InboundQueue：InputDispatcher 的 “待处理快递堆”，存放刚从 InputReader 拿到的事件。
   • OutboundQueue：每个 App 的 “待签收快递车”，存放即将派发给 App 的事件。
   • WaitQueue：App 的 “已派送未签收快递”，记录已发给 App 但未处理完的事件，若堆积说明 App 处理慢（类似快递堆在门口没人取）。

二、触摸事件的 “旅程” 示例：滑动桌面

1. 用户手指按下屏幕：

   • InputReader 读取到触摸事件，放入 InboundQueue。
   • InputDispatcher 取出事件，放入对应 Launcher 的 OutboundQueue，再转移到 WaitQueue 等待处理。

2. Launcher 处理事件：

   • Launcher 的主线程被唤醒，从 PendingInputEventQueue 取出事件，处理滑动逻辑（如移动图标）。
   • 处理完成后，WaitQueue 中的事件被标记为 “已签收”，数量减少。

3. 若出现卡顿：

   • 若 Launcher 主线程繁忙（如加载图片），WaitQueue 中的事件会堆积（数值变大），导致滑动延迟、画面不跟手。

三、关键指标：如何从 Systrace 看输入性能？

1. 看队列状态：

   • WaitQueue 数值突然升高（如从 0 到 8），说明 App 处理事件慢，可能主线程卡顿。
   • InboundQueue 和 OutboundQueue 的耗时过长，说明 InputDispatcher 或 InputReader 处理有瓶颈。

2. 看事件间隔：

   • 正常情况下，InputReader 每 6.25ms（160Hz 采样率）读取一次事件。若间隔变长，可能硬件或驱动问题。

3. 看 Vsync 同步：

   • 屏幕刷新率 60Hz 时，每 16.6ms 处理一帧。若 Input 事件频繁（如 120Hz 采样），但 Vsync 周期内只能处理 1 次，多余事件会被丢弃，可能导致画面抖动。

四、通俗类比：输入卡顿像 “堵车的快递站”

• 正常情况：快递分拣员（InputReader）按时取件，派送员（InputDispatcher）及时派件，用户（App）及时签收，流程顺畅。
• 卡顿情况：用户（App）忙着处理其他事（如主线程卡顿），快递堆在门口（WaitQueue 堆积），派送员只能等待，导致滑动延迟。

五、开发者如何用 Systrace 优化？

1. 定位瓶颈：

   • 若 WaitQueue 堆积，检查 App 主线程是否有耗时操作（如 IO、复杂布局）。
   • 若 InputDispatcher 耗时久，可能是系统层问题（如多窗口同时接收输入）。

2. 采样率与刷新率匹配：

   • 60Hz 屏幕无需 160Hz 采样率，否则多余事件会被丢弃，徒增功耗。
   • 90Hz 屏幕建议搭配 120Hz 采样率，确保事件不丢失。

总结

Systrace 中的 Input 分析就像 “快递物流追踪系统”，通过观察各队列状态和事件处理耗时，能定位从硬件到应用的整个输入链路问题。理解这套机制后，开发者可针对性优化主线程性能，或与系统层配合提升输入响应速度，让用户操作更跟手。