The Profiler

Chapter 4 closed on a clean distinction: Logcat and the debugger answer "what is happening and why," while the Profiler answers "how much resource is this using." This chapter is the Profiler itself — CPU, memory, and network, each measuring a genuinely different resource on a genuinely running app.

What the Profiler Actually Measures

The Profiler observes an app while it's actually running on a device or emulator — a real-time measurement, not an analysis of source code sitting at rest (that's static analysis, covered in Chapter 7's own lint material). Nothing in the Profiler can tell you anything about an app that isn't currently executing; it exists entirely to answer questions about live behavior.

CPU Profiler

Recording a method trace shows exactly which methods are consuming CPU time, how often each one is called, and the call stack leading to them. This is the tool for a "why is this screen janky or slow to respond" question — genuinely heavy computation, not a data-loading delay or a memory issue, is what the CPU Profiler is built to reveal.

Memory Profiler

The Memory Profiler tracks heap allocation over time. A healthy pattern shows memory climbing, then dropping back down after garbage collection runs — a sawtooth shape that returns close to its own baseline each time. A pattern that keeps climbing even after repeated garbage collection, never returning to baseline, is a real warning sign of a memory leak — objects being retained somewhere they shouldn't be. Capturing a heap dump at that point shows exactly what's still allocated and, critically, what's still holding a reference to it.

Network Profiler

The Network Profiler inspects the actual HTTP requests and responses a running app makes — timing, payload size, and headers, observed directly rather than inferred. This is the right tool for a "why is this screen slow to load its data" question specifically, as distinct from a CPU-bound slowness the CPU Profiler would reveal instead.

Hands-On Exercises