How do I discover memory usage of my application in Android?
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
On Android, memory usage is something you measure from several angles, not with one magic number. The most useful tools are Android Studio’s profiler for live analysis, adb shell dumpsys meminfo for process snapshots, and runtime APIs when the app itself needs to inspect memory state.
Use Android Studio Profiler First
For day-to-day debugging, Android Studio’s Memory Profiler is usually the best starting point. It shows live allocations, heap growth, garbage collections, and object retention patterns.
That makes it especially useful when you are trying to answer questions like:
- is the app leaking activities or fragments
- does one screen allocate too much memory
- does memory return after leaving a feature
- is bitmap usage dominating the heap
The profiler is better than guessing because it shows behavior over time instead of one static number.
Get a Snapshot with dumpsys meminfo
If you want a command-line snapshot of the process, use adb:
This reports metrics such as Java heap, native heap, graphics, code, stack, and other categories associated with the app process.
It is a good tool when you need a quick measurement from a device, a CI-style diagnostic, or a reproducible check outside Android Studio.
Read Process Memory from Code
If the app needs to inspect its own memory state, ActivityManager can provide process memory information:
totalPss is often the most useful high-level number because it approximates the process’s proportional memory footprint more realistically than just looking at one heap value.
Know What You Are Measuring
Android memory numbers can be confusing because different metrics mean different things:
- Java heap is managed object memory
- native heap covers native allocations such as some libraries and bitmaps in certain cases
- PSS estimates shared-memory cost proportionally across processes
- RSS is resident memory in RAM
That is why two tools can report different-looking values without either being wrong. The question is which metric matters for the problem you are investigating.
If you are debugging leaks in Kotlin or Java objects, Java heap views matter most. If the app crashes around large images or native code, PSS and native allocations may be more revealing.
Use LeakCanary for Leak Hunting
If the concern is not just “how much memory” but “what is being retained,” LeakCanary is often the fastest way to identify object leaks in development builds.
Profilers tell you that memory is growing. Leak tools help tell you what failed to be released.
That combination is usually more effective than either tool alone.
Common Pitfalls
The biggest mistake is treating one number as the full truth. Android memory has several categories, and each tool emphasizes different aspects of process usage.
Another issue is measuring only in emulators. Real devices, real images, and vendor memory behavior can differ significantly from desktop simulation.
Developers also sometimes profile the app only at launch and miss the real leak, which happens after repeated navigation, configuration changes, or background and foreground cycles.
Finally, do not confuse a temporary spike with a leak. Memory can rise during a feature and later drop after garbage collection. A leak is about retention over time, not just momentary allocation.
Summary
- Use Android Studio Memory Profiler for live inspection and leak investigation.
- Use
adb shell dumpsys meminfofor process-level snapshots. - Use
ActivityManager.getProcessMemoryInfowhen the app needs runtime memory data. - Understand the difference between heap metrics and PSS.
- Measure over time on real devices so you can distinguish spikes from true leaks.

