Memory Leaks: The Silent App Killer

WHY IT EXISTS: Android devices have finite RAM. The operating system must aggressively manage memory, allocating it to foreground apps and reclaiming it from apps that are closed or in the background. Memory leaks subvert this process, causing an app to hold onto memory it no longer needs, which degrades performance for the entire system.

THE MENTAL MODEL: A memory leak is like forgetting to return library books. Each book is an object in memory. As long as you hold it, the library (Android OS) can't lend it to anyone else. If you keep forgetting, you accumulate more books than you can carry, and eventually, the library has no books left for other patrons. Your app becomes slow and eventually crashes because it's holding onto resources it will never use again.

HOW IT WORKS: Android uses a Garbage Collector (GC) that periodically scans for objects that are no longer reachable from a set of 'root' references (like static variables or active threads). If an object can't be reached, the GC frees its memory. A leak happens when an object that should be garbage collected is still referenced by another, longer-lived object. The GC sees this reference and incorrectly assumes the object is still in use, preventing it from being collected.

WHEN TO USE IT: You never want to 'use' a memory leak; you want to prevent them. Be vigilant in these situations: first, when using singletons or other objects that live for the entire application lifecycle; second, when registering listeners or callbacks, like a BroadcastReceiver; and third, when using non-static inner classes inside an Activity or Fragment.

WHEN NOT TO USE IT: To avoid leaks, never pass a short-lived context (like an Activity) to a long-lived object. Instead, use the ApplicationContext, which is tied to the app's lifecycle, not a single screen. Always unregister listeners in the corresponding 'destroy' lifecycle method (e.g., unregister in onDestroy if you registered in onCreate). Finally, prefer static inner classes over non-static ones if they don't need access to the outer class's state, or use a WeakReference.

ONE CANONICAL EXAMPLE: A singleton holding an Activity context is a classic leak. If a singleton object has a property var context: Context and you assign an Activity to it, that Activity can never be garbage collected, even after the user navigates away. The singleton lives forever, so its reference keeps the Activity and all its views alive in memory, wasting megabytes of RAM until the app is killed.