Core Concepts
Performance and Profiling
Why a performance claim without a measurement is a guess, and the tools an interviewer expects you to reach for when a frame budget or startup target is on the line.
Performance work on Android lives or dies on measurement. A candidate who says "we'd cache that, it'd be faster" without naming a tool to verify the claim has skipped the only part of the answer that distinguishes a senior from a mid-level engineer. This page walks through the six measurement tools that cover the four contexts a real team operates in - local dev investigation, automated CI gates, in-the-wild production telemetry, and ahead-of-time install-time optimization - and ends with a decision table mapping each common performance signal to the right tool. The model that profiling surfaces (frame pipeline, GC pauses, RenderThread, Binder transactions) is the subject of the rendering and memory entries; this page is about the instruments, not the substrate.
Four measurement contexts
Every performance tool serves one or two of these contexts well. Confusing them - using a dev-machine profiler to investigate a production p99, or trying to reproduce a user's jank on a beefy Pixel 8 Pro - is the most common waste of time on a mobile perf team.
| Context | Question it answers | Right tools |
|---|