Android Perfetto Series 3: Familiarizing with the Perfetto View

Word count: 2.7kReading time: 16 min

 2024/05/21

The first two articles covered what Perfetto is and how to capture a trace. This third article starts after you open that trace: with so much on the screen, where do you look?

Android documentation labels Systrace a legacy tool and recommends Perfetto on Android 10+. When I wrote this article, Perfetto had largely replaced Systrace in my daily work, and the OPPO and vivo teams I encountered were migrating. This series continues the earlier analysis methods with Perfetto.

Technical review: 2026-10-14. The 2024 interface and case screenshots are retained. Updates to shortcuts and analysis semantics use official documentation and v58.3 source (11fbaed83636). The original case traces are not provided here; their illustrated wake-up chains and measurements are not new-version test results.

Perfetto Series Catalog
Perfetto View Interface
Perfetto Trace Interface
Basic Operations
Perfetto Usage Tips
Summary
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.

Perfetto View Interface

Open a captured trace in Perfetto UI. The official record_android_trace helper normally pulls the file and opens the browser, unless --no-open is used. The screenshot below shows the 2024 home page; entries such as Legacy UI should not be assumed to remain available.

Perfetto View Interface

Use Open trace file or drag the trace into the page. Browser memory can limit large files; a local native Trace Processor can work with the UI.

Perfetto Trace Interface

The interface after opening Perfetto Trace is as follows:

Trace Operation Area

The historical screenshot has four broad areas. Menu names and locations can change between versions:

The leftmost operation area: The most important thing here is the few under the Current Trace column that will be used frequently.
1. Show timeline: Display current Trace, after switching to other interfaces, click this again to return to the Trace View interface
2. Query: Place to write SQL query statements and view execution results
3. Metrics: predefined analysis, requiring the relevant data sources and compatible versions; not every trace produces a complete set of metrics.
4. Info and stats: trace metadata, parsing statistics, and data-loss indicators. Check that the capture covers the problem interval before analyzing it.
Information and operation area at the top: The most important thing is to look at the time.
Trace content area in the middle: scheduling, frequency, thread instrumentation, and other tracks. Input, Binder, memory, and frame information depend on what was recorded. In this article’s older terminology, a Task generally means a thread state or execution interval. A Running interval differs from an instrumentation slice: the latter can include waits and is not necessarily CPU time.
Information area at the bottom: details for the selected event, range statistics, or query results. Android Logs requires recorded log data; an app having printed a message does not mean the trace contains it. Ftrace events likewise depend on the recording configuration.

Perfetto can look cluttered and overwhelming at first. Once you get used to it, though, it is hard to go back.

Basic Operations

In my environment at the time, a roughly 500 MB trace felt smoother in Perfetto than in Systrace. Loading and interaction still depend on event count and types, queries, browser, and host memory. That file size is neither a performance guarantee nor a supported-size ceiling.

W/S zoom, A/D pan, and a click selects an event. Press ? for current hotkeys, or Ctrl+Shift+P (Cmd+Shift+P on macOS) for the command palette. Use timeline shortcuts while the timeline has focus, not while typing SQL. The following help screenshots are historical; check current prompts for query-page actions and key combinations. See the UI guide.

Basic Operations

SQL Related Operations

Other Shortcut Keys

Some frequently used shortcuts are:

f is to zoom in on the selection
M creates a temporary span note from the selection. In v58.3 it reuses one temporary-note ID, replacing that note next time; selecting a single event also creates an area selection. Esc clears the selection, which is not the same as deleting a note. See the Notes implementation.
Shift+M creates a new span note each time instead of replacing the previous temporary note. This is useful for marking several intervals. “Persistent” in this sense does not mean the annotation has been written back into the original trace file.

Select the corresponding range to inspect statistics. The screenshot’s SUM(dur) aggregates slice durations, which can overlap between parents and children. A null thread_dur does not mean zero CPU time.
Delete continuous Mark
1. Click the span note’s edge marker to select the annotation.
2. The older UI shows it in Current Selection.
3. Click Remove. v58.3 also provides Remove selected note (Delete by default) and the Notes & markers management tab.
q: Hide and show the information Tab. Screen space is precious in Perfetto. Open the panel when you need the details, then hide it when you are done.
Flagging: Perfetto can also use the method of inserting flags to make marks on Trace. Perfetto supports you to put the mouse on the top of Trace, and a flag will appear. Click the left button to insert a flag on it, which is convenient for us to mark the occurrence of an event, or a certain time point

Cancel the inserted flag: Same as exiting continuous selection, click the flag, there is a Remove in the lower right corner, click it to remove the flag. I’ll skip another screenshot here.

Perfetto Usage Tips

Check Wakeup Source

Here, a wake-up source is the recorded waker when a thread becomes runnable. It is not the device’s suspend wake-up reason and does not directly identify a lock owner or complete application dependency. Scheduling and wake-up events must be present; missing data, IRQ context, and trace boundaries can leave the chain incomplete.

In the article Android Systrace Response Speed Practice 3: Response Speed Extended Knowledge, I talked about how Systrace checks the wake-up source. In fact, it is still a bit troublesome. Checking the wake-up source in Perfetto is very convenient and the operation is very smooth:

The examples below show both the main thread and RenderThread. Check which thread is actually selected in each screenshot.

Click Runnable Status

Select a Runnable interval on the thread-state track to inspect Related thread states. The first screenshot selects the main thread, scrollingexample, whose waker is SurfaceFlinger’s app thread—not RenderThread. A Runnable interval can also follow preemption, so not every such interval has a new external wake-up.

Waker: the recorded waking thread/state, providing a lead for further investigation.
Previous state: The previous state of this Task
Next state: The next state of this Task

Click the Running status above it to view continuous wake-up information:

Select a Running interval on the thread-state track and follow its CPU link to the scheduling slice, then inspect the preceding Runnable interval and wake-up event. Merely adjacent or overlapping activity in another thread does not establish a waker relationship.

Click the Running status above RenderThread to jump to the CPU Info area via the small arrow

This historical screenshot links one RenderThread activation to the main thread. It does not mean that every RenderThread wake-up has that source.

Here, the main thread’s recorded waker is SurfaceFlinger’s app thread. Scheduling latency measures the interval from becoming runnable to obtaining CPU time, not the duration of the operation that issued the wake-up.

Check Critical Path (Task)

This Critical Path is a blocking path reconstructed from thread states and wake-up relationships. It helps investigate activity associated with a thread’s waits. It is not the union of every dependency and does not automatically establish a business-level root cause. Uninstrumented asynchronous relationships, missing data, and IRQ context can affect the interpretation.

In the v58.3 plugin, Critical path lite primarily shows the state path; the full Critical path overlays associated slices. These nested slices are not automatically sampled function call stacks. The wake-up graph implementation also notes that missing IRQ-context information before Android 14 can affect accuracy.

The old UI offers Critical path after selecting a Running state. In v58.3, the selected thread state slice command uses that thread and the whole trace’s time bounds. For a specific window, select an area over a thread-state track and use the over area selection command instead.

Wait for a moment to see the Critical path corresponding to the MainThread we selected:

This historical screenshot associates the end of the main thread’s wait with SurfaceFlinger’s app thread. Its CPU numbers describe this instance, not a fixed scheduling rule.

Continue by checking the app thread’s own waker in the trace. The original text mentions TimerDispatch but does not show that step; it needs the original trace for verification and should not be treated as a fixed chain for every frame.

This view places related states and instrumentation together for further investigation. It does not by itself prove that speeding up any one displayed thread will reduce end-to-end latency.

Pin (Fix to Top)

Use the Pin icon beside a track’s title to keep it at the top. Newer workspaces also help organize tracks without pinning so many that little viewing space remains.

Here I have pinned the tracks from the app through to SurfaceFlinger. Seeing them together makes the frame flow much easier to follow when investigating dropped frames.

CPU Info Area Task Highlight

In the CPU Info area, if you put the mouse on a certain Task, other Tasks of the Thread corresponding to this Task will be highlighted.

We often use this for an initial look at which CPUs ran a thread. Highlighting shows scheduling results; it does not establish why migration occurred, a core’s capacity, or the complete scheduling policy.

Check Buffer Consumption Stats

For layers submitted to SurfaceFlinger for display composition, an App Actual Timeline slice can link to the corresponding display frame. Check the layer name and frame token when a process has several layers. A flow is not a BufferQueue-depth measurement or proof that a buffer was copied. FrameTimeline requires Android 12+ and the corresponding recorded data.

Quickly Check App Execution Timeout

Here, “timeout” means a frame missing its expected budget, not an ANR. Multiple buffers can keep older content on screen but do not rule out delayed updates or jank.

Expected Timeline represents a budget; Actual Timeline covers frame processing, including waiting and GPU work. Check Present Type, On time finish, Prediction Type, and Jank Type together instead of reading every long slice as a CPU overrun.

A red frame is a starting point, not a full explanation. The detail screenshot shows App Deadline Missed, Late Present, and Valid Prediction; investigate the main thread, RenderThread, and relevant GPU data before attributing the cause to a function. See the FrameTimeline documentation.

View Log on Perfetto

When android.log data was recorded, Android Logs can align messages with thread activity. The old screenshot’s hover line is a time reference, not proof that the logged operation caused a nearby stall.

Ftrace events shows retained raw events. Missing entries can mean an event was not enabled, was unsupported, or was lost; absence does not establish that it never happened.

Analyze Running Information of Thread

Drag to select a time window and include the target thread-state track to inspect time in each state. Selecting only an instrumentation track gives slice statistics, not scheduler states. A single thread’s Running share is not whole-device CPU utilization. This is often useful when analyzing app startup.

For precise statistics, clip state intervals to the window and state whether the denominator is the window length or valid covered time. Do not fill unknown coverage with Sleep or zero. In the historical screenshot, total Wall duration is about 865.44 ms while Selected range is 857.5 ms, so those table values should not be treated directly as exact percentages of the selected window.

Moving from UI Analysis to SQL Automation

The UI is useful for understanding a trace. Once the analysis is repeatable, translate it into SQL for comparisons and batch work:

Identify the selected event’s table and SQL ID. slice contains instrumentation intervals; track, thread_track, and process_track describe tracks and ownership. They are not interchangeable slice tables.
Use thread_state for scheduler states and sched / sched_slice for on-CPU intervals. Clip to the same window and distinguish wall time, CPU time, and uncovered intervals.
Prefer FrameTimeline tables or standard-library modules for frame analysis, checking tokens, layers, prediction validity, and dropped frames instead of only counting red slices.
track_id, utid, and upid associate tracks, threads, and processes. They do not prove causality across processes; Binder, buffer, camera, and audio chains also need their own transaction, flow, or frame-token evidence.

Article 11: PerfettoSQL, Trace Processor and Regression Detection develops this workflow further.

Summary

That covers the interface and the operations I use most often. Perfetto keeps changing; when a useful feature turns up, I will add it here.

The basic chapter of Perfetto ends here. The follow-up is to understand the basic process of Android system operation through the tool Perfetto, and use Perfetto and Perfetto SQL to analyze the problems encountered such as performance and power consumption.

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!