Android Studio Profiler: A Practical Guide

Performance problems hide behind assumptions. "The list is slow because of images" might really be a database query on the main thread. The Profiler replaces guesses with timelines, stacks and allocations. You only need to know which tool answers which question.

Which tool for which question

Profile the right build

Debuggable builds behave differently: extra checks and no R8 optimisation. For realistic CPU and timing data, profile a profileable release-like build. Android Studio lets you choose "Profile with low overhead" (profileable) or "Profile with complete data" (debuggable). Use debuggable only when you need the extra detail, such as some memory features.

<application>
    <!-- Allows profiling tools to attach to a non-debuggable build -->
    <profileable android:shell="true" />
</application>

Reading a system trace

1. Record a system trace while reproducing the problem, keeping the recording short and focused.
2. Find long or red frames in the frame lifecycle and jank tracks.
3. Look at the main thread during that frame: what slice spans it?
4. Zoom in and follow nested slices down to your code.

Add your own trace sections

import androidx.tracing.trace

fun buildFeed(items: List<Post>): List<FeedRow> = trace("FeedMapper.buildFeed") {
    items.map { it.toRow() }        // appears as a named slice in system traces
}

Named sections make traces readable, so you can see your own code, not just framework calls. Compose also emits composition tracing when the runtime tracing dependency is added.

Memory investigations

• Sawtooth pattern (rise then drop at each GC) is normal. A steady climb across repeated actions suggests a leak.
• Heap dump: filter by class (for example your Activity) and inspect instance counts and references. See Memory Leaks.
• Allocation tracking: find code allocating many short-lived objects during scroll or animation (GC churn causes jank).

Network Inspector

App Inspection's Network Inspector shows each request's URL, timing, size, headers and payload for supported networking libraries such as OkHttp. Use it to spot duplicate requests, oversized payloads and slow endpoints.

Example investigations

Tips

• Reproduce on a mid-range physical device whenever possible.
• Keep recordings short: a few seconds around the problem.
• Compare before and after traces when you make a fix.
• Automate checks with Macrobenchmark once you've found the problem.

Frequently asked questions

Conclusion

Match the question to the tool: system traces for slowness and jank, heap dumps and allocations for memory, Network Inspector for requests, and the Power Profiler for battery. Profile profileable builds on real devices, add custom trace sections, and verify every fix.

Next step: handle the failures you find in Debugging Crashes with Logcat.