Android Perfetto Series 1: Introduction to Perfetto

Word count: 3.1kReading time: 19 min

 2024/05/21

This is the first article in the Perfetto series. It mainly provides a brief introduction to the Perfetto tool, including its history, development, and what Perfetto can do.

Android documentation labels Systrace a legacy tool and recommends Perfetto on Android 10+. By the time I wrote this article, Perfetto had largely replaced Systrace in my daily work, and the OPPO and vivo teams I encountered were also migrating. Newcomers facing its complex interface asked me to revisit the Systrace articles using Perfetto.

Technical review: 2026-10-14. The original article and screenshots date from 2024. The updates below distinguish Android 10/11/12 data-source requirements and Perfetto v48.0/v49.0 UI changes from that earlier experience. Available data still depends on the device, recording configuration, and tool version.

Perfetto Series Catalog
Main Content
Why Performance Analysis Needs a God’s View
Introduction to Perfetto
Where it’s not as good as Systrace
Reference Documents
About Me && Blog

Paul Graham said: “Either give a lot of people something they kind of want, or give a small number of people something they really want.“ Perfetto is actually something that a small number of people really want, so let’s start writing. Please join the discussion. If you spot an error or an unclear explanation, let me know so I can fix it before it misleads someone.

In this series, I want to use Perfetto to look at how apps, the Framework, and Linux work together. If you have read plenty of source code and performance articles but still find the flow hard to follow, try placing that code on a trace timeline.

Perfetto Series Catalog

If you haven’t seen the Systrace series yet, here is the portal:

Systrace Series Catalog: Systematically introduced the use of Systrace, the predecessor of Perfetto, and used Systrace to learn and understand the basic rules of Android performance optimization and Android system operation.
Personal Blog: Personal blog, mainly content related to Android, and also put some content related to life and work.

The About Me page has WeChat group information for discussing Perfetto and Android development.

Main Content

I started the Systrace series in 2019 and gradually wrote more than 20 posts: basic usage, how system modules appear in a trace, and practical cases involving startup speed and smoothness. Together, they covered the basic Systrace workflows for new app and system developers. I also met many people through the blog; by the time I wrote this, we had six discussion groups. Thank you for all that support.

I used to think the Systrace series was enough. Here are the reasons I later shared on Knowledge Planet for writing a Perfetto series:

In the teams I encountered in 2024, many OPPO and vivo colleagues were already using Perfetto to record and analyze traces. New readers often started with Perfetto; if I kept writing only about Systrace, I would miss them.
The source code referenced by the Systrace series is now old. Later articles will discuss newer versions, including Android 17 (API 37), but each article is bounded by its stated source tag, device, and trace. Historical cases are not automatically revalidated on a newer system. Practical capture and analysis start at Android 12; that is not Perfetto’s minimum supported version.
I had only scratched the surface of some advanced Perfetto features. Writing the series would give me a reason to learn them properly.
Perfetto is a very powerful tool. Behind it is the entire Android + Linux system. So when writing this series, the focus should be on the Android + Linux behind it, rather than just being limited to the Perfetto tool. Tools are just our way of observing Android + Linux. Understanding the laws of the entire Android system operation, thinking about its operating principles, discovering problems through tools, and thinking about the essence through problems are meaningful to developers.
Perfetto’s official documentation still does not cover many contents related to Android system operation. I can supplement this part; in addition, the official documentation is in English, and Chinese blogs can supplement this aspect.
If the series turns out well, I can also use it for a Google DevFest talk.

Perfetto

Why Performance Analysis Needs a God’s View

Why do we need tools like Systrace and Perfetto? Android performance depends on the app, system services, Linux, hardware, vendor policies, and the conditions on the device. Load, memory pressure, heat, OS versions, and usage patterns all matter. Looking at one app or module may not explain the problem; we need to see how these parts interact.

Perfetto can place several data sources on a shared timeline, helping us investigate the following stages:

How Input events flow
How every frame of the App you are using goes from generation to screen display
Real-time frequency, load, core placement, wake-up of cpu, etc.
How various Apps in the system are running
….

App and platform developers can add trace points to important code paths. A system-wide view still depends on available data sources, TraceConfig settings, permissions, and data loss. Ordinary scheduling events show when a thread ran on a CPU; they do not necessarily expose the scheduler’s complete reason for choosing that CPU. An absent event does not prove that the activity never happened.

Also, to illustrate the complexity of performance optimization, you can look at the description of performance in the book Systems Performance, specifically the methodology, which fits the theme of this article very well. I also strongly recommend that all students engaged in performance optimization keep this book as a frequent reading methodology book: System performance engineering is a challenging field due to many reasons, including the fact that system performance is subjective, complex, and often multi-problem.

Performance is Subjective

Software fault investigation often has a relatively clear correctness criterion: does the behavior meet expectations, and can the failure be reproduced? A bug does not always produce an error log, and an error message alone may not explain its cause.
Unlike this, performance is often subjective. When starting to address performance issues, the judgment of whether the problem exists may be vague. The same is true when the problem is fixed. Performance considered “bad” by one user may be considered “good” by another user.

The System is Complex

In addition to subjectivity, performance engineering, as a challenging discipline, is not only because of the complexity of the system, but also because we often lack a clear starting point for analysis regarding performance. Sometimes we just start with guessing, for example, blaming the network, and performance analysis must verify whether this is a correct direction.
Performance problems may arise from complex interconnections between subsystems, even if these subsystems perform well in isolation. It may also be due to cascading failure, which refers to a faulty component causing performance problems in other components. To understand these problems, you must clarify the relationship between components and understand how they cooperate.
Bottlenecks are often complex and interconnected in unexpected ways. Fixing a problem may just push the bottleneck to other places in the system, resulting in the overall performance of the system not improving as expected.
In addition to the complexity of the system, the complex nature of the production environment load may also lead to performance problems. It is difficult to reproduce such situations in a laboratory environment, or they can only be reproduced intermittently.
Solving complex performance problems often requires a holistic approach. The entire system—including its internal and external interactions—may need to be investigated. This work requires a very wide range of skills, which is generally unlikely to be concentrated in one person, which drives performance engineering to become a varied and intellectually challenging job.

Multiple Problems May Coexist

Finding a performance problem point is often not the problem itself. In complex software, there are usually multiple problems.
Another difficulty in performance analysis: the real task is not to find the problem, but to identify the problem or identify which problems are the most important.
To do this, performance analysis must quantify the importance of the problem. Some performance problems may not apply to your workload or only apply to a very small extent. Ideally, you should not only quantify the problem, but also estimate the speed increase brought by each problem fix. This information is especially useful when management reviews the reasons for engineering or operation and maintenance resource overhead.
There is an indicator that is very suitable for quantifying performance, that is, latency.

Introduction to Perfetto

Perfetto is an open-source suite for recording and analyzing performance data, with collection components, Trace Processor, and a web UI. It can correlate enabled system and application events and query them with SQL. Memory analysis includes heapprofd allocation sampling (Android 10+) and ART heap reference graphs (Android 11+). Allocation profiles attribute memory to call stacks; reference graphs describe object retention, without object contents or allocation call stacks. On production user builds, heapprofd requires a debuggable or profileable target app. Ordinary system traces do not automatically contain these data.

Recording, analysis, and visualization can be used separately. Cross-platform support is component-specific: Android/Linux system data sources are not available on every platform. Consult the official repository and releases for development activity. Android recommends Perfetto, but its display and analysis behavior is not identical to every legacy Systrace feature.

Existing Systrace files can be opened in Perfetto UI, which supports importing the ftrace/ATrace data embedded in Systrace HTML. This does not reproduce every legacy viewer feature or analysis result. The Legacy UI link in the old screenshots was part of that interface; do not depend on current versions always providing a one-click fallback.

The figure below is the architecture diagram of Perfetto. It can be seen that Perfetto contains three major blocks:

Record traces: The data capture module. It can be seen that the captured content and sources are very rich, involving Java, Native, and Linux, which is much richer than Systrace.
Analyze traces: Mainly the trace analysis module, including Trace parsing, SQL query, Metrics analysis, etc. This part has a dedicated command line tool provided, which is convenient for everyone to call directly or call in the tool chain.
Visualize Traces: Trace presentation, capture, etc.

These modules will be introduced in detail in subsequent articles in the series.

Perfetto’s Core Advantages and Highlights:

Based on daily use and the documentation, the main capabilities fall into the following groups:

Long-running recording: background services record Protobuf data. Configure buffer sizes, write periods, and file limits for the intended duration. A ring buffer overwrites older events; keeping a session alive does not preserve its entire history. See configuration and data-loss analysis.
Multiple data sources: Linux ftrace is one system-tracing source. ATrace, SDK Track Event, and memory profiling have their own configuration and support requirements; Perfetto as a whole is not limited to ftrace.
Recording and triggers: web, command-line, and Android developer-option workflows can start recording. Triggers control configured sessions; they are not an independent data source.
Analysis and visualization:
- Trace Processor exposes SQL tables and views after parsing a trace. Conversion to a SQLite file is not a prerequisite, and a raw Protobuf trace is not a SQLite database.
- The Python API can turn query results into pandas DataFrames. Their validity still depends on recording completeness and query definitions.
- Browser memory limits can prevent large traces from loading. Use a native local Trace Processor with the web UI when needed; host memory remains a constraint.
- Pinned tracks, Binder flows, scheduler wake-up relationships, and critical-path analysis require the relevant events. A thread’s waker is not the same question as what woke the device from suspend.
- Function call stacks require suitable profiling data and symbols. Nested trace slices are not a complete sampled call stack; allocation stacks and ART object reference graphs are also different views.
Versioned components: the UI, Trace Processor, SDK, and device recording components may have different versions. Record the tool version, system version, and TraceConfig when comparing SQL results or reports.

SQL deserves a closer look. Trace Processor exposes tables and views for repeatable analysis. The historical screenshot below illustrates filtering by duration, process, and scheduling state (image from Kernel Artisan).

SQL Query

Limits of these historical queries: OPF: is a trace-specific name, not a standard system event. The lock query counts name-derived identifiers and temporal nesting; this does not establish the number of threads contending for one object. Check fields against the current schema (for example, slice.id), exclude unfinished slices with negative dur, and check scheduling coverage before reuse. Unknown Running time must not be filled with zero.

The documentation also provides SQL and result examples. The screenshot below shows an earlier FrameTimeline query.

Official Docs SQL

When the boss asks for before-and-after numbers, SQL lets you run the same query on both traces and turn the results into a chart. That makes preparing a report much easier. A report still needs the device, scenario, sample count, time window, and recording completeness; one trace alone does not establish a repeatable improvement percentage.

Where it’s not as good as Systrace

Vsync-App is not so intuitive

In the 2024 screenshots below, Perfetto lacks the Vsync-App guide lines that span the Systrace view. Readers accustomed to that presentation may need time to adjust:

In Perfetto, you can Pin Vsync-App to the top to see Vsync information
Perfetto Vsync

In Systrace, Vsync runs through the entire Trace in the form of a vertical line, which is easy to identify:

Systrace Vsync

Vsync-App is a useful timing reference, but it cannot by itself identify which frame or process caused jank. FrameTimeline provides additional frame-level evidence. On Android 12+, a trace containing FrameTimeline data can show Expected and Actual Timeline tracks. See the official documentation.

Expected Timeline: the slice represents the app’s rendering budget for a frame. It begins when the Choreographer callback was expected to run, not when execution actually began.
Actual Timeline: it starts when Choreographer#doFrame or AChoreographer_vsyncCallback actually runs and ends at the later of GPU completion and posting the frame to SurfaceFlinger. This interval includes waiting and GPU work; it is neither CPU running time nor the complete interval until the app’s frame reaches the display.

Compare these tracks to select frames for investigation, then inspect Jank Type, Present Type, and Prediction Type. Red attributes jank to that process; yellow marks an app frame affected by SurfaceFlinger jank, while light green indicates high latency. Do not count only red frames. Blue indicates a dropped frame: the old legend only describes SurfaceFlinger, while the app case can involve a UI state update not reaching RenderThread in time. Check prediction validity and the relevant surface as well; article 7 develops this further.

Jank Detection

Jank Detection 2

The diagram shows why both GPU completion and posting time affect Actual Timeline. Its duration is not the sum of CPU and GPU execution time.

Calculation Method

SurfaceFlinger has corresponding tracks for composition and presentation. Their durations should not be read as app main-thread time.

Folding function is relatively bad, wasteful of screen

The following preserves my experience with the 2024 UI: pinning several threads on a widescreen monitor left little space below, and tracks with deeply nested slices made it painful. At the time I found folding less convenient than in Systrace. These nested slices are not necessarily sampled function call stacks.

Solution:

Pin fewer key threads (where’s the fun in that?)
Turn the monitor upright (and lose width instead)

We eventually found a setup I loved: LG’s 16:18 DualUp monitor. It felt made for reading Perfetto traces. I had already talked colleagues into getting three for the office.

LG DualUp

If the budget allows: LG 28MQ780 - 3599
A cheaper alternative: Innocn 28C1Q - 2999

Version update: the official CHANGELOG records the workspace API with nested tracks and multiple workspaces in v48.0 (2024-10-11), followed by the workspace switcher and track-moving menu in v49.0 (2025-01-06). Grouping the tracks needed for a task into a workspace can reduce dependence on pinned tracks. The monitor experience and prices above are historical 2024 observations, not current pricing or purchasing advice.

Reference Documents

About Me && Blog

Here is a personal introduction and related links. I hope to communicate more with my peers. When three people walk together, there must be one who can be my teacher!