How do you diagnose a memory leak using the Android Studio Profiler?
This tests your practical skill with the Android Memory Profiler, not just theory. A great answer involves capturing a heap dump, filtering for unreachable objects, and inspecting the reference tree to find the leak's source.
What's really being asked
This question assesses your practical ability to use core Android developer tools, not just theoretical knowledge. It tests whether you can move from a high-level symptom ("high memory usage") to a specific diagnosis ("this Singleton is holding a reference to a destroyed Activity"). The interviewer wants to see a systematic, tool-driven approach to debugging a common and critical performance issue.
The full answer
A strong answer walks through the process in four steps. First, open the Android Studio Memory Profiler and start a session. Second, perform the user action suspected of causing the leak multiple times (e.g., rotating the screen 10 times, or navigating into and out of an Activity). Third, force garbage collection (GC) using the profiler button to see if memory returns to the baseline. If it doesn't, capture a heap dump. Fourth, in the heap dump analysis view, use the "Analyze" task to find leaked activities automatically or manually look for multiple instances of an Activity that should have been destroyed. You then inspect the "Instance View" and its "References" pane to find the path from the GC root that is preventing the object from being collected.
The mistakes people make
A major red flag is only describing the real-time memory chart. A junior developer might say, "I'd watch the memory graph go up and down." This is observation, not diagnosis. A senior engineer must explain how to use the heap dump to find the why. Another weak answer is vaguely mentioning "looking for leaks" without naming specific tools within the profiler like the heap dump analyzer, the leaked activities task, or the references pane. It shows a lack of hands-on experience. Confusing the CPU profiler with the Memory Profiler is an immediate fail.
What usually comes next
Be prepared for "What are the most common causes of memory leaks on Android?" (static references to Context, anonymous inner classes holding references, listeners not being unregistered). Another is "What if the profiler doesn't show a clear leak? What other tools could you use?" (LeakCanary library, Perfetto traces). They might also ask about the difference between shallow heap and retained heap.
A concrete example
"I suspected a leak on screen rotation. I rotated the device 10 times, forced a GC, and saw memory usage was 50MB higher than baseline. I captured a heap dump and the analyzer immediately flagged 9 leaked instances of MyLeakyActivity. I selected one, looked at its references, and saw it was being held by a static companion object variable that was caching a view. The fix was to clear that reference in the Activity's onDestroy() method."
Interview question
After repeatedly performing an action suspected of causing a memory leak, what is the most effective diagnostic step within the Android Memory Profiler?
- a.Force a garbage collection, then capture a heap dump to analyze object references if memory usage remains high.Correct
- b.Switch to the CPU Profiler to check if the suspected code is also causing high CPU usage, which often correlates with leaks.
- c.Immediately capture a heap dump and identify the object class with the highest instance count or largest shallow heap.
- d.Continuously observe the memory allocation graph to confirm that the baseline memory usage is steadily increasing over time.
Why? this is the answer
Forcing a garbage collection is a critical step to ensure you are analyzing objects that are truly leaked, not just transient objects waiting to be collected. Simply observing the graph confirms a problem but doesn't help find the source.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
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