Walk through your toolbox for profiling a slow Android or iOS app

Profiling starts by correctly naming the symptom, not by opening a tool. "The app is slow" collapses at least four distinct problems that live in different subsystems: dropped frames during scrolling (jank), a screen that visibly takes long to open (startup latency), memory climbing until an OutOfMemoryError (a leak or genuine bloat), or a foreground feature draining battery. Each one has a tool that's actually built to see it, and reaching for the wrong one first is what burns the most time — in an interview and in real debugging alike.

On Android, day-to-day work happens in Android Studio's Profiler window (CPU, Memory, Network, and Energy tabs) attached to a running debuggable — or better, "profileable" — process. The CPU tab offers a sampled recording (low overhead, statistical, good for "where's the hot function") versus an instrumented/tracing recording (every method entry and exit timestamped, exact call counts and precise timing, but with much higher overhead that can itself distort the measurement, especially around allocation-heavy code). The Memory tab tracks live allocations and lets you force a heap dump to diff instance counts across a suspected leak.

Beyond the Profiler window itself, Perfetto (which superseded systrace) gives you a system-wide trace: scheduling on every core, whether your main thread was actually running or merely "runnable" and waiting for a core, Choreographer's per-frame breakdown, and Binder calls into system_server. This is the tool for "why did this one frame take 40ms," because it shows the whole system during that frame, not just your process's own method calls.

For leaks specifically, LeakCanary automates the same idea — heap dump plus retained-path analysis — so leaks surface continuously in a debug build instead of requiring a deliberate profiling session. For startup and jank as a regression-gated metric rather than a one-off investigation, the Macrobenchmark library runs StartupTimingMetric and FrameTimingMetric against a release-like build in CI, and Baseline Profiles are the artifact you generate from those same benchmarks to speed up first-run execution.

On iOS, Instruments is the equivalent umbrella: Time Profiler for sampled CPU call trees (the direct analogue of Android's sampled CPU recording), Allocations for tracking live object counts and generation analysis, the Leaks instrument — or, more usefully in modern Swift, the Xcode Memory Graph Debugger for spotting retain cycles directly, since leaks under ARC are almost always cycles rather than "forgot to free" — Core Animation for FPS and offscreen-rendering/blended-layers (the iOS analogue of jank hunting), the App Launch instrument for cold/warm start breakdowns, and os_signpost for hand-instrumenting your own custom intervals so they show up as named tracks right alongside the system ones.

For production telemetry rather than a session on your own machine, MetricKit is the iOS analogue of Play Console's Android vitals: it aggregates hangs, launch times, memory, and disk usage across real devices in the field and delivers them in daily batches, with nobody attaching a debugger to a user's phone.

The nuance that separates a senior answer from a junior one: profile on a release-like build, not a debug build. A debug APK has JIT-unfriendly bytecode paths, no R8/ProGuard shrinking, and — if debuggable=true — extra instrumentation hooks that all inflate measured time; Android's android:profileable manifest flag exists specifically so you can attach the Profiler to a release-configured build without shipping it publicly. iOS has the same trap: an unoptimized Debug-scheme build in Instruments will show CPU costs that a Release/Optimized build simply doesn't have. Measuring on the wrong build configuration is one of the most common ways to "fix" a bottleneck that was never really there.