Memory Leaks: The Silent App Killer
A memory leak is when your app holds onto objects it no longer needs, preventing memory reclamation. This often happens with static references to UI elements or background tasks. The footgun: your app won't crash immediately, but will slow down and die later.
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.
Interview question
Why does a singleton holding a direct reference to an Activity often result in a memory leak?
- a.The singleton, being a long-lived object, maintains a strong reference to the Activity, making it unreachable for garbage collection.Correct
- b.The singleton's static nature prevents the Garbage Collector from ever scanning the referenced Activity.
- c.The Activity's lifecycle methods are repeatedly triggered as long as the singleton exists, consuming CPU and memory.
- d.The Activity's UI components are automatically re-instantiated by the singleton, leading to memory duplication.
Why? this is the answer
A memory leak occurs when a long-lived object, like a singleton, holds a strong reference to a short-lived object, such as an Activity. The Garbage Collector sees this strong reference and incorrectly assumes the Activity is still needed, preventing its memory from being reclaimed. Option B is incorrect because the GC does scan, but finds the strong reference.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on android — each one lists the topics its interview covers.
See open roles