Android Systrace 基础知识 -- Systrace 简介

字数统计: 4.9k阅读时长: 19 min

 2019/05/28

2026-10-13 技术更新：原文发表于 2019 年，旧 Systrace HTML 和脚本步骤保留作历史参考。现代抓取示例以 Android 11 / API 30+ 为起点；应用 Trace API、权限和数据源的版本边界另行注明。本文同时区分设备端 atrace、主机端 systrace.py 与 perfetto，参数不能混用。

本文是 Systrace 系列文章的第一篇，主要是对 Systrace 进行简单介绍，介绍其简单使用方法；如何去看 Systrace；如何结合其他工具对 Systrace 中的现象进行分析。

本系列的目的是通过 Systrace 这个工具，从另外一个角度来看待 Android 系统整体的运行，同时也从另外一个角度来对 Framework 进行学习。也许你看了很多讲 Framework 的文章，但是总是记不住代码，或者不清楚其运行的流程，也许从 Systrace 这个图形化的角度，你可以理解的更深入一些。

Perfetto 系列文章目录

Systrace 到 Perfetto 的使用方式变化

这篇文章最早写 Systrace 时，主流程是 systrace.py 调 atrace，把 ftrace 和 ATRACE 数据整理成 HTML，再用 Chrome 打开。现在这个流程要拆成两层看：

数据来源有延续：android.os.Trace、Native ATRACE 宏、系统服务里的 ATRACE、Linux ftrace、CPU 调度事件仍然是分析 Android 性能问题的核心数据来源，旧文章的分析方法可以参考，具体 Framework 实现仍要按源码版本核对。
工具流程已经变了：新版本 platform-tools 不再把 systrace.py 当作主入口；Android 10（API 29）及之后，System Tracing 保存的文件是 .perfetto-trace，默认应使用 Perfetto UI 或 trace_processor 分析。
现在抓 Trace 有三条常用路径：通过开发者选项里的 System Tracing 快捷开关抓交互问题；通过 adb shell perfetto ... --out /data/misc/perfetto-traces/xxx.perfetto-trace 抓可复现问题；复杂配置用 Perfetto config 或 record_android_trace 脚本固化。
本文讲的 Systrace 入门概念，对应现在的 Perfetto 1：工具简介、Perfetto 2：Trace 抓取和 Perfetto 3：熟悉 Perfetto View。

Perfetto 将 protobuf Trace、SQL、metrics、命令行处理和大文件分析整合起来，可以支持短场景与长时间记录。旧的 Systrace HTML 更适合快速肉眼扫图；新的 Perfetto 更适合把一次分析继续推进到搜索、过滤、SQL、指标化和自动化。

笔者后续会持续更新 Perfetto 系列，后续所有的图例也都会用 Perfetto 来演示。两套系列可以对照学习；新项目优先用 Perfetto，旧图中的函数、线程与数据范围仍需核对版本。

Systrace 系列文章目录

正文

Systrace 是 Android 4.1 时代引入的系统事件跟踪与分析工具，主要记录已启用的事件和埋点，并非自动采样所有方法的调用栈。它可帮助开发者收集 Android 关键子系统（如 SurfaceFlinger、SystemServer、内核调度、输入、显示和 View 系统）的运行信息，从而帮助开发者更直观地分析系统瓶颈，改进性能。

Systrace 的功能包括跟踪系统的 I/O 操作、内核工作队列、CPU 负载以及 Android 各个子系统的运行状况等。在 Android 平台中，它主要由 3 部分组成：

内核部分：Systrace 利用了 Linux Kernel 中的 ftrace 功能。所以，如果要使用 Systrace 的话，需要内核支持相关 tracing 功能、事件与访问权限，不能简单理解为安装一个额外模块。
数据采集部分：Android 的公开 android.os.Trace 同步区间 API 从 Android 4.3 / API 18 起提供，应用可用它记录自定义区间。同时，Android 还有一个 atrace 程序，它可以从 ftrace 中读取统计信息然后交给数据分析工具来处理。
数据分析工具：旧流程里 Android 提供 systrace.py（Python 脚本文件，曾位于 Android SDK 目录的 platform-tools/systrace 中，其内部调用 atrace 程序）来配置数据采集方式并生成 HTML。新流程里，perfetto 负责抓取并输出 .perfetto-trace，Perfetto UI 和 trace_processor 负责打开、查询和分析。从实现关系看，Systrace 是对 Linux Kernel 中 ftrace 的封装；Perfetto 则是在继续支持 ATRACE/ftrace 的基础上，把更多数据源、文件格式和分析能力整合到了一起。应用进程仍然可以利用 Android 提供的 Trace 类来输出自定义 Trace 点。

关于 Systrace 的官方介绍和使用可以看这里：系统跟踪与设备端抓取

Systrace 的设计思路

在系统的一些关键操作（比如 Touch 操作、Power 按钮、滑动操作等）、系统机制（input 分发、View 绘制、进程间通信、进程管理机制等）、软硬件信息（CPU 频率信息、CPU 调度信息、磁盘信息、内存信息等）的关键流程上，插入类似 Log 的信息，这里统称为 TracePoint，其中应用/Framework 的 ATrace 标记与内核原生 ftrace 事件来自不同层次，通过这些 TracePoint 来展示一个核心操作过程的执行时间、某些变量的值等信息。然后 Android 系统把这些散布在各个进程中的 TracePoint 收集起来，写入到一个文件中。导出这个文件后，Systrace 通过解析这些 TracePoint 的信息，得到所选时间段内已启用、获准访问并成功写入的系统事件。未埋点的逻辑、未启用的数据源和丢失的事件不会自动补齐。

历史 ATrace 与内核事件片段

Android 系统中，一些重要的模块都已经默认插入了一些 TracePoint，通过 TraceTag 来分类，其中信息来源如下

Framework Java 层的 TracePoint 通过 android.os.Trace 类完成
Framework Native 层的 TracePoint 通过 ATrace 宏完成
App 开发者可以通过 android.os.Trace 类自定义 Trace

把多个进程和内核事件放到同一时间轴上，可以追踪一次操作经过哪些线程、何时等待和被唤醒。它提供跨层观察能力，但不等于收集了 Android 的全部信息；采集本身也有开销，不宜为了“看全”就启用所有类别或在高频循环里密集埋点。

实践中的应用情况

解析后的 Systrace 由于有大量的系统信息，天然适合分析 Android App 和 Android 系统的性能问题， Android 的 App 开发者、系统开发者、Kernel 开发者都可以使用 Systrace 来分析性能问题。

Systrace 可辅助分析响应速度、卡顿丢帧和 ANR 等问题。对应到用户场景，包括：

应用启动速度问题，包括冷启动、热启动、温启动
界面跳转速度慢、跳转动画卡顿
其他非跳转的点击操作慢（开关、弹窗、长按、选择等）
亮灭屏速度慢、开关机慢、解锁慢、人脸识别慢等
列表滑动卡顿
窗口动画卡顿
界面加载卡顿
整机卡顿
App 点击无响应、卡死；闪退前的时序可辅助观察，但崩溃原因还需日志或 tombstone

ANR 需要结合 ANR 记录、线程栈与系统日志判断；开机问题通常需要专门的 boot trace 配置，普通交互录制不能覆盖尚未启动的抓取服务。

在遇到上述问题后，旧系统可以使用兼容的 Systrace 工具抓取 HTML；现在的 Android 10+ 系统更建议使用 System Tracing 或 perfetto 抓取 .perfetto-trace，然后在 Perfetto UI 里分析。旧文章中的“看线程、看唤醒、看 CPU、看 Binder 等待”的方法仍然成立，只是入口从 Chrome HTML 换成了 Perfetto 的轨道、搜索、选择面板和 SQL。

Systrace 简单使用

使用 Systrace 前，要先了解一下 Systrace 在各个平台上的使用方法。早期文章里会提到 Eclipse、Android Studio Device Monitor、systrace.py 这些入口；当前推荐的流程已经变成 System Tracing 或 Perfetto。两套流程的操作节奏类似，但输出文件和分析工具不同。

旧流程是：

手机准备好你要进行抓取的界面
点击开始抓取，命令行就是执行 systrace.py
手机上开始操作，不要太长时间
设定时间结束后生成 Trace.html，使用支持该文件格式的查看器打开分析；旧 HTML 直接在当前 Chrome 中打开可能有兼容问题

新流程（以下按 Android 11+）是：

在开发者选项里打开 System Tracing，或者用 adb shell perfetto 开始录制
手机上复现卡顿、响应慢、启动慢等问题
录制结束后导出 .perfetto-trace
使用 Perfetto UI 打开，必要时再用 SQL、metrics 或 trace_processor_shell 做二次分析

下面是旧版 Systrace UI 的历史示例：com.android.janktown PID 13409、SurfaceFlinger PID 118，以及 CPU、主线程和 RenderThread 轨道。它不是当前设备的抓取结果，也不是 Perfetto 界面。

旧版 Systrace 时间轴界面

使用命令行工具抓取 Systrace / Perfetto

我比较推荐命令行：配置一次，以后抓同类场景就方便了，也容易保留可重复的抓取配置。旧 systrace.py 曾随 SDK 分发，但当前 Platform-Tools 已说明它被替代；不再用“下载 33 之前版本”作为通用安装建议。历史脚本可查 Catapult 源码，并按所选版本配置 Python 和依赖。

下面示例以 Android 11 / API 30+、已授权的 ADB 连接、设备支持相应类别为前提。Perfetto 平台服务从 Android 9 起存在，Android 11 起默认启用；Android 9、10 的额外启用步骤及路径限制见官方 Android 抓取说明。

adb shell perfetto -t 10s -b 64mb \
  sched freq idle am wm gfx view binder_driver \
  --out /data/misc/perfetto-traces/trace_file.perfetto-trace

adb pull /data/misc/perfetto-traces/trace_file.perfetto-trace .

这是 Perfetto 的简单模式，主要配置 ftrace/ATrace；它不会自动启用 FrameTimeline、heapprofd 等全部数据源。-b 64mb 是本次选择的环形缓冲区容量示例，不保证高负载时完整保留 10 秒事件。需要更多数据源或长时间记录时使用完整配置，见 Perfetto CLI。

如果要抓 App 自定义 Trace 点，把 com.example.app 换成实际应用，并确认下面的应用埋点条件：

adb shell perfetto -t 10s -b 64mb -a com.example.app \
  sched freq idle am wm gfx view binder_driver \
  --out /data/misc/perfetto-traces/app_trace.perfetto-trace

adb pull /data/misc/perfetto-traces/app_trace.perfetto-trace .

下面是旧 Systrace 脚本的历史调用形式。路径、Python 解释器及依赖须匹配实际脚本版本；类别用空格分隔，输出名显式指定：

1 2	$ cd android-sdk/platform-tools/systrace $ python systrace.py -t 8 -o historical.html sched gfx view

量产 user 构建也能提供许多系统跟踪信息；能看到什么取决于 Android/OEM 版本、类别、权限和应用配置。userdebug/eng 可能开放更多调试能力，但不保证与量产版本性能相同。定位机制后，性能结论应回到目标量产环境核验。

自定义应用埋点

Trace.beginSection() / endSection() 自 API 18 起可用，必须在同一线程成对、正确嵌套。以下是放在应用同步方法中的片段，bindArticle() 代表要测量的实际代码：

android.os.Trace.beginSection("bindArticle");
try {
    bindArticle();
} finally {
    android.os.Trace.endSection();
}

跨线程或挂起后可能换线程的异步工作，不应直接跨越同步 begin/end；API 29 起的 beginAsyncSection() / endAsyncSection() 使用同名和同一 cookie 配对。见 Trace API。

-a 只是选择应用，不会替你埋点，也不会绕过权限。Android 10、11 的 release 应用可在 <application> 中通过 <profileable android:shell="true" /> 允许 shell profiling，避免仅为测时开启 debuggable。Android 12 的开关已有变化：AOSP android-12.0.0_r1 按 debuggable 或 isProfileable() 允许应用 Trace；<profileable> 的 android:enabled 默认 true，不能把旧的 shell 限制照搬到所有新版系统。其他 profiler 的权限仍应分别检查。profileable 说明

不要混用三套命令参数

下面保留的参数表实际来自设备端 atrace，不是 systrace.py。已对照 AOSP android-12.0.0_r1 atrace；它输出原始跟踪数据，不会因为文件后缀写成 .html 就生成 HTML 报告。实际设备以 adb shell atrace --help 为准。

 -a appname      enable app-level tracing for a comma separated list of cmdlines; * is a wildcard matching any process
 -b N            use a trace buffer size of N KB
 -c              trace into a circular buffer
 -f filename     use the categories written in a file as space-separated
                   values in a line
 -k fname,...    trace the listed kernel functions
 -n              ignore signals
 -s N            sleep for N seconds before tracing [default 0]
 -t N            trace for N seconds [default 5]
 -z              compress the trace dump
 --async_start   start circular trace and return immediately
 --async_dump    dump the current contents of circular trace buffer
 --async_stop    stop tracing and dump the current contents of circular
                   trace buffer
 --stream        stream trace to stdout as it enters the trace buffer
                   Note: this can take significant CPU time, and is best
                   used for measuring things that are not affected by
                   CPU performance, like pagecache usage.
 --list_categories
                 list the available tracing categories
-o filename      write the trace to the specified file instead
                   of stdout.

例如，Bash/zsh 中旧脚本的交互式 alias 可以写成下面这样。先把示例路径和 python 换成实际环境；等号两侧不留空格，使用普通引号，类别之间使用空格：

1
2
3

alias st-start='python /path/to/legacy-systrace/systrace.py'
alias st-start-gfx-trace='st-start -t 8 sched gfx view'
st-start-gfx-trace -o historical.html

这些参数不用一次全记住，先会抓一个简单场景，分析过程中会慢慢熟悉。不过，用的是哪一个工具要先分清，常用参数可以这样对照：

参数	设备端 atrace（上述 Android 12 版本）	Perfetto 简单模式
`-o`	设备端原始数据输出文件	设备端 Perfetto Trace 输出文件
`-t`	秒数，帮助默认 5 秒	可显式写 `10s` 等时长
`-b`	KB	上例显式写 `64mb`，不是 KB
`-a`	逗号分隔应用进程命令行名称，可用通配符	选择应用的 ATrace 埋点

旧 systrace.py 以它自身的 --help 为准。不要把 atrace 的 -s（延迟开始）照搬给 Perfetto，后者简单模式的 -s 指最大文件大小。环形缓冲区写满会覆盖较早事件；需要核对丢失情况、缩短窗口或调整完整采集配置，而不是认定默认 buffer 总够用。

查看支持的 TAG

设备当前可用的 atrace 类别，可以通过下面的命令列出，不同厂商的机器可能有不同的配置，在使用的时候可以根据自己的需求来进行选择和配置，TAG 选的少的话，Trace 文件的体积通常会变小，但是抓取的内容也会相应变少。Trace 文件大小会影响其在 Chrome 中打开后的操作性能，所以这个需要自己取舍

下面是我当时手上那台 Android 12 设备的输出。文中没有留下厂商和构建号，不能视为每台 Android 12 或现代设备的标准列表。末尾带 HAL 的类别和重复名称属于这份设备输出；左边是类别名，右边是解释。

$ adb shell atrace --list_categories
         gfx - Graphics
       input - Input
        view - View System
     webview - WebView
          wm - Window Manager
          am - Activity Manager
          sm - Sync Manager
       audio - Audio
       video - Video
      camera - Camera
         hal - Hardware Modules
         res - Resource Loading
      dalvik - Dalvik VM
          rs - RenderScript
      bionic - Bionic C Library
       power - Power Management
          pm - Package Manager
          ss - System Server
    database - Database
     network - Network
         adb - ADB
    vibrator - Vibrator
        aidl - AIDL calls
       nnapi - NNAPI
         rro - Runtime Resource Overlay
         pdx - PDX services
       sched - CPU Scheduling
         irq - IRQ Events
         i2c - I2C Events
        freq - CPU Frequency
        idle - CPU Idle
        disk - Disk I/O
        sync - Synchronization
       workq - Kernel Workqueues
  memreclaim - Kernel Memory Reclaim
  regulators - Voltage and Current Regulators
  binder_driver - Binder Kernel driver
  binder_lock - Binder global lock trace
   pagecache - Page cache
      memory - Memory
     thermal - Thermal event
        freq - CPU Frequency and System Clock (HAL)
         gfx - Graphics (HAL)
         ion - ION Allocation (HAL)
      memory - Memory (HAL)
       sched - CPU Scheduling and Trustzone (HAL)
  thermal_tj - Tj power limits and frequency (HAL)

拿到 Trace 后先看什么

先确认复现时间段、目标进程及 PID、所选数据源和采集丢失情况。文件生成成功只表示有文件，不表示问题窗口已被完整记录。
沿目标操作看主线程、RenderThread、Binder 对端和 CPU 调度。Running 是正在执行；Runnable 是等待 CPU；Sleep/等待的原因要继续找唤醒、锁或 Binder 等证据，不能凭一种颜色定根因。
同步切片的跨度可能包含等待，不等于纯 CPU 时间。关联相关线程与帧后再判断；Android 12 / API 31+ 可另启用 FrameTimeline，前面的简单命令并未采集它。
将现象与 ANR 栈、崩溃日志或专项 profiler 交叉验证；修改后在同设备、同构建与相近负载下重复场景。缺轨道或缺事件保留为未知，不当作零耗时。