Android
Memory Usage
Application Performance
Android Development
Mobile Optimization

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:

bash
adb shell dumpsys meminfo com.example.myapp

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:

kotlin
1import android.app.ActivityManager
2import android.content.Context
3
4fun logMemoryUsage(context: Context) {
5    val activityManager = context.getSystemService(Context.ACTIVITY_SERVICE) as ActivityManager
6    val pid = android.os.Process.myPid()
7    val memoryInfo = activityManager.getProcessMemoryInfo(intArrayOf(pid))[0]
8
9    println("dalvik private dirty: ${memoryInfo.dalvikPrivateDirty} KB")
10    println("native private dirty: ${memoryInfo.nativePrivateDirty} KB")
11    println("total pss: ${memoryInfo.totalPss} KB")
12}

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 meminfo for process-level snapshots.
  • Use ActivityManager.getProcessMemoryInfo when 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.

Course illustration
Course illustration

All Rights Reserved.