📚 课程目录第4章收集Binder性能数据

4. 收集Binder性能数据：使用binder_stats、dumpsys binder、perfetto trace采集

数据采集是问题排查的基石。针对Binder通信延迟导致的帧率抖动，选择正确的采集工具能快速锁定瓶颈层次。本章聚焦三种核心手段：binder_stats、dumpsys binder、Perfetto trace，并给出每种工具的使用时机与判断规则。

4.1 binder_stats：实时监控Binder线程池状态

binder_stats是Linux内核导出的Binder全局统计接口，位于/proc/binder_stats。它能反映Binder线程池的即时健康度：线程是否存在长时间阻塞、是否有pending work积压。

采集命令：

adb shell cat /proc/binder_stats

输出示例：

Binder stats:
  proc 1234 (surfaceflinger) thread 7: returned 3456 ok, 12 timed out
  proc 5678 (system_server) thread 16: returned 12345 ok, 34 timed out
  ...
  global: threads 45 active 3 pending 5

排查规则：若active线程数接近Binder线程池上限（默认16/进程），且pending持续>0，表明线程池饥饿，是高延时的直接信号。

4.2 dumpsys binder：系统级Binder状态快照

dumpsys binder提供更详细的进程级Binder状态：各进程的binder node、ref、transaction统计，以及活跃transaction的调用栈。

采集命令：

adb shell dumpsys binder --stats   # 通用统计
adb shell dumpsys binder --transactions  # 活跃事务列表

关键输出字段：

proc：进程名及PID
threads：已创建/最大线程数
waitingForWork：正在等待work的线程数
activeTransactions：当前未返回的事务

注意：dumpsys binder会短暂挂起目标进程（通常<10ms），在高帧率场景下可能导致额外丢帧，建议在非关键帧区间或复现期执行。

4.3 Perfetto trace：端到端Binder延时追踪

Perfetto是Android最强大的全系统追踪工具，可精确到微秒级的Binder transaction延时，并关联CPU调度、SurfaceFlinger合成等上下文。

采集命令：

# 启用binder相关数据源
adb shell perfetto -c - <<'EOF'
data_sources {
  config {
    name: "linux.ftrace"
    ftrace_config {
      ftrace_events: "binder/binder_transaction"
      ftrace_events: "binder/binder_transaction_received"
      ftrace_events: "binder/binder_transaction_alloc_buf"
      ftrace_events: "binder/binder_lock"
      ftrace_events: "binder/binder_locked"
    }
  }
}
duration_ms: 5000
EOF

生成trace后，通过ui.perfetto.dev打开，在“Binder”切片组中查看：

Binder transaction：完整调用耗时
Binder reply：服务端处理时长
Binder async：异步调用情况

排查规则：在Perfetto中排序按duration降序，若某binder transaction时长超过16.7ms（60fps帧间隔）且发生在SF或App主线程的vsync间隔内，即可判定为帧率抖动的直接原因。

工具选择决策表

工具	采集方式	数据类型	典型输出	适用场景
binder_stats	即时读取/proc	整数计数器	线程活跃/等待数	快速判断线程池饥饿
dumpsys binder	IPC同步转储	进程级快照	事务活跃列表	定位具体是否被阻塞
Perfetto trace	内核ftrace + 用户追踪	时间序列切片	微秒级事务时长/堆栈	精确定位延时归属函数

数据采集决策流程

下图为Binder性能数据采集的故障树，帮助根据现象快速选择工具：

数据采集最佳实践要点

先低开销后高开销：binder_stats几乎零开销 → dumpsys binder短暂挂起 → Perfetto trace较大但最全面。
连续采集对比：在抖动发生前后各取一次binder_stats，看active/pending变化量。
Perfetto触发模式：使用perfetto --txt-config + 应用自定义触发器（如监听到掉帧时自动转储trace），避免长时间录制。
保留日志上下文：同时抓取logcat -s "BufferQueue" "Choreographer"，关联帧率事件与Binder事务。

常见误区：不要只用Perfetto而不检查线程池状态。很多“Binder慢”实际是线程池满导致排队，而非单次调用耗时长。先binder_stats可避免浪费trace分析时间。