← All articles

Android Memory Optimization at Scale

Memory problems rarely show up as crashes in your testing — they show up as slow degradation, background kills, and one-star reviews mentioning "app gets laggy after a while." In high-traffic fintech apps handling real-time data, getting this wrong is expensive. Here's what's actually worked in production.

Start with the right tools, not guesses

Before optimizing anything, profile. Android Studio's Memory Profiler shows live heap allocation, and the Layout Inspector catches view hierarchy bloat. For leak detection specifically, LeakCanary is worth keeping in debug builds permanently — it catches Activity and Fragment leaks automatically and gives you a reference chain, which saves hours of manual heap dump analysis.

debugImplementation("com.squareup.leakcanary:leakcanary-android:2.x")

The usual leak suspects

Most leaks in production Android code trace back to a small set of patterns:

• Static references to Activity or Context — common in singletons or companion objects that outlive the screen.
• Anonymous inner classes (listeners, callbacks) holding an implicit reference to the outer Activity.
• Unregistered listeners and observers — BroadcastReceivers, LiveData observers, or location listeners that never get torn down.
• Coroutines launched on the wrong scope, keeping references alive past the screen's lifecycle.

In Compose specifically, forgetting an onDispose block inside DisposableEffect is the most common way I've seen listeners leak.

Use application context where the lifecycle doesn't matter

If a class needs a Context just to access resources, system services, or shared preferences — not anything UI-related — pass the application context instead of an Activity context. It can't leak an Activity because it isn't tied to one.

class AnalyticsLogger(private val appContext: Context) {
    // appContext = context.applicationContext, not the Activity
}

Bitmap and image handling

Images are usually the single biggest memory consumer in any app with a feed, gallery, or chart-heavy UI. A few rules that consistently help:

• Let an image-loading library (Coil, Glide) manage caching and downsampling — don't decode bitmaps manually unless you have a specific reason to.
• Decode images at the target view size, not full resolution, using inSampleSize if you're handling decoding yourself.
• Recycle large bitmaps explicitly in pre-Android-8 code paths where the garbage collector isn't as aggressive about reclaiming native memory.

Background work and WorkManager

Long-running background work is a common silent leak source — a job holding a reference to a ViewModel or Activity well after the screen is gone. Tie coroutine scopes to viewModelScope or lifecycleScope rather than a custom scope you have to remember to cancel manually, and for true background work (sync, uploads), use WorkManager so the OS manages the lifecycle instead of your app holding a wakelock or thread alive indefinitely.

Watch your data structures, not just your views

In real-time apps — order books, live feeds, chat — unbounded in-memory caches are an easy way to slowly grow your heap over a session. A few practices that helped on a trading app with constant WebSocket updates:

• Cap in-memory lists with a fixed window size instead of appending indefinitely.
• Use LruCache for anything that's a cache by definition rather than a plain HashMap.
• Periodically clear stale entries tied to screens the user has already left.

Test on low-end devices, not just your flagship

A flow that performs fine on a high-RAM device can trigger frequent background process kills on a budget device with 2-3GB RAM. If your user base spans price points, profile on the cheapest device in your target range, not just your dev phone — Android's low-memory killer behaves very differently under real memory pressure than it does in a profiler running on a powerful test device.

Quick checklist

• Run LeakCanary in every debug build, not just when chasing a specific bug.
• Audit static references and anonymous inner classes for implicit Activity references.
• Use application context for anything not UI-bound.
• Let an image library handle bitmap memory — don't hand-roll it.
• Scope coroutines to lifecycle-aware scopes, always.
• Cap unbounded collections that grow with real-time data.
• Profile on low-RAM devices before shipping.

---