📚 课程目录第3章延迟数据采集工具选型

章节3：延迟数据采集工具选型

3.1 现象识别 → 数据采集的衔接

帧回调延迟现象一旦被确认（滑动卡顿、掉帧、ANR），必须选择合适的数据采集工具，以便获取足够精度和上下文的数据。选型的核心决策维度包括：

采集粒度：是否需要系统级时间戳（CPU/GPU/显示流水线）？
可复现性：问题能否稳定触发？
性能开销：采集过程本身是否会影响帧率？
部署条件：是否需要root权限？是否允许注入代码？

3.2 工具全景对比表

工具	采集粒度	系统依赖	开销	适用阶段	输出格式
Systrace	线程/进程级 + Trace.beginSection	需要adb root或userdebug	中等	系统级概览	HTML / JSON
Perfetto	内核 + 用户态Trace	Android 10+ / Linux	低-中	全链路深度分析	Proto / UI
dumpsys gfxinfo	仅统计帧时间直方图	无需root	极低	初步筛选	控制台文本
FrameTiming API	每帧精确阶段时间	Android 7+	低	App内帧级别统计	数组 / Log
自定义Trace	开发者定义	无（需嵌入代码）	可调	业务阶段深度分析	自定义

关键判断：若首帧延迟但无明显CPU负载，优先 dumpsys gfxinfo 和 FrameTiming API；若伴随高频Jank，应直接上 Perfetto 或 Systrace 捕获长Trace。

3.3 工具选型决策流程

下图从“帧回调延迟”现象出发，根据观察到的特征选择对应工具：

3.4 各工具详细说明与使用示例

3.4.1 Systrace

系统级Trace工具，收集CPU调度、Binder、SurfaceFlinger等服务以及App通过Trace.beginSection()标记的节段。适合快速获取全局时间线。

# 采集10秒系统Trace，输出到trace.html
python systrace.py --time=10 -o trace.html -a com.example.app

3.4.2 Perfetto

新一代性能追踪平台，支持更细粒度的ftrace和atrace配置，可远程抓取，适合深度分析。

# 使用perfetto命令行捕获
adb shell perfetto -c /data/local/tmp/config.pbtx -o /data/local/tmp/trace.perfetto-trace
# 配置文件示例 config.pbtx (简化)
buffers: {
    size_kb: 204800
    fill_policy: RING_BUFFER
}
data_sources: {
    config { name: "linux.ftrace" }
}
duration_ms: 10000

3.4.3 dumpsys gfxinfo

直接通过adb命令获取当前应用的帧渲染统计信息，包括最坏/最近/平均帧时间，开销极低。

adb shell dumpsys gfxinfo com.example.app
# 输出片段示例
Cumulative stats:
  Back buffer drawing time (ms): max=26.7, min=3.2, avg=8.1
  Prepared frames: 120 / 120
  Process frames: 120 / 120

3.4.4 FrameTiming API

Android 7+ 提供的 FrameMetrics 或 Window.OnFrameMetricsAvailableListener，可在App内获得每帧各个阶段的耗时。

// 注册帧监听器
window.addOnFrameMetricsAvailableListener(
    new Window.OnFrameMetricsAvailableListener() {
        @Override
        public void onFrameMetricsAvailable(Window window, FrameMetrics frameMetrics, int dropCount) {
            long totalDurationUs = frameMetrics.getMetric(FrameMetrics.TOTAL_DURATION);
            long inputDurationUs = frameMetrics.getMetric(FrameMetrics.INPUT_HANDLING_DURATION);
            long animationDurationUs = frameMetrics.getMetric(FrameMetrics.ANIMATION_DURATION);
            long layoutMeasureDurationUs = frameMetrics.getMetric(FrameMetrics.LAYOUT_MEASURE_DURATION);
            long drawDurationUs = frameMetrics.getMetric(FrameMetrics.DRAW_DURATION);
            // 处理帧数据...
        }
    }, new Handler(Looper.getMainLooper()));

3.4.5 自定义Trace

利用TraceCompat.beginSection()在业务代码关键位置添加标记，配合Perfetto/Systrace查看。适合分析具体业务逻辑耗时。

// 在Choreographer回调中包裹
TraceCompat.beginSection("onChoreographerFrame");
doFrame(frameTimeNanos);
TraceCompat.endSection();

3.5 排查表：根据场景选择工具

场景特征	推荐工具	理由
周期性掉帧，可稳定复现	Perfetto	全量数据，可放大到微秒级
偶然卡顿，复现难	自定义Trace + FrameTiming API	低开销长期采集
需快速评估App帧率	dumpsys gfxinfo	一行命令，无需代码
分析UI执行流程（布局/绘制）	Systrace	系统范围时间轴，一目了然
对比优化前后帧时间	FrameTiming API	精确到每个阶段

3.6 原因定位中的工具配合

选型完成后，若数据显示帧回调延迟根源在 Input、Animation、Layout 或 Draw 阶段，应进一步对应细化：

Input 慢 → 检查Perfetto中InputReader线程；
Animation 慢 → 查看自定义Trace中动画回调；
Layout/Measure 慢 → 追加 TraceCompat.beginSection("onMeasure")。

3.7 复测与预防

修复动作后，使用同一套工具复测，确保帧时间回退到正常范围（<16ms）。建议建立持续集成脚本，每日跑 dumpsys gfxinfo 或集成 FrameMetricsAggregator 自动监控，预防回归。

注意：生产环境不建议长期开启Perfetto或Systrace全量捕捉，会增大应用功耗和内存。推荐使用 FrameMetricsLogger（基于FrameTiming API）以极低开销持续记录，仅在异常时触发dump。

至此，数据采集工具选型已完成。结合选型决策树和排查表，快速定位合适工具，获取高质量数据，为后续原因定位打下基础。