How would you use Perfetto and Trace.beginSection to find a non-obvious bottleneck?
Tests correlation beyond CPU sampling. Covers coarse Trace.beginSection to limit 1-10us overhead, recording app ATrace with CPU/scheduling tracks, and correlating slices against scheduler latency. Red flag: omitting overhead or ignoring Perfetto SQL queries.
What's really being asked
This tests whether you can debug elusive performance issues that hide inside standard sampling profilers by combining custom app instrumentation with system-wide tracing. It checks knowledge of ATrace overhead characteristics, Perfetto configuration, and the ability to correlate app-level slices with kernel and system server behavior.
The full answer
First, strategic instrumentation. You bracket suspect code regions with Trace.beginSection and Trace.endSection, but you keep the granularity intentionally coarse. The canonical overhead is 1-10 microseconds per event due to stringification, a JNI call, and a user-space to kernel-space roundtrip to write into trace_marker. Instrumenting a tight loop would destroy the very signal you are trying to measure. Second, trace recording configuration. You enable app ATrace events for your specific package via Perfetto TraceConfig, targeting ATRACE_TAG_APP, and you simultaneously enable system tracks such as CPU frequency, scheduling, and binder transactions. This gives you a unified timeline that the Android Studio CPU Profiler cannot provide. Third, visual analysis. In the Perfetto UI you look for slices that are unexpectedly long, scheduling gaps where your thread is runnable but not running, or binder IPC blocking the main thread. Fourth, quantitative analysis. You use PerfettoSQL against the slice table to sum durations, group by thread, or compute percentiles across thousands of events, turning a visual hunch into hard numbers.
The mistakes people make
A major red flag is proposing Trace.beginSection inside a tight loop or on every frame without mentioning the 1-10us overhead. Another is treating Perfetto as merely a prettier Systrace and ignoring the SQL layer or system-level tracks like CPU scheduling. Some candidates incorrectly suggest migrating to the new Tracing SDK on Android; the current official advice is to continue using the existing ATrace API. Finally, failing to mention endSection or discussing trace events without explaining how to balance granularity is a signal of shallow production experience.
What usually comes next
How do you avoid observer effect when the trace itself adds latency? When would you use Trace.setCounter versus slices? How would you automate regression detection by querying slice durations across a fleet of traces? What is the difference between Perfetto and the Android Studio CPU Profiler for app instrumentation?
A concrete example
Suppose RecyclerView scrolling stutters but the CPU profiler shows bind() taking only 2ms. You instrument bind(), image decode, and database query phases. After recording a ten-second trace with scheduling and binder tracks enabled, you discover the bind slice is fast, but the main thread sits runnable for 8ms immediately after while waiting on a binder IPC to the media server for image resizing. The fix is to move the resize to a background thread and cache the result, which eliminates the scheduling gap.
Interview question
What is the primary reason to enable CPU scheduling and binder tracks when recording a Perfetto trace with app ATrace events?
- a.To eliminate the need for PerfettoSQL by providing a unified visual timeline
- b.To correlate short app slices against thread scheduling gaps and IPC blockingCorrect
- c.To avoid placing instrumentation inside tight loops that distort measurements
- d.To verify that Trace.beginSection overhead stays within the 1-10 us budget per call
Why? this is the answer
System tracks provide the necessary context to correlate short app slices with scheduling gaps or binder IPC blocking, exposing non-obvious system-level bottlenecks. Option A is tempting because Perfetto does offer a unified timeline, but the card explicitly warns against treating it as merely a prettier Systrace and ignoring the SQL layer.
Just read this? Test yourself on what you have been reading.
Read the original → perfetto.dev
- #android
- #perfetto
- #performance
- #tracing
- #debugging
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on android — each one lists the topics its interview covers.
See open roles