How do you diagnose a memory leak with Android Studio Profiler?
This tests your systematic process for debugging memory issues. A good answer outlines using the Memory Profiler, forcing GC, capturing heap dumps, and analyzing object references. A red flag is just naming the tool without explaining the 'how'.
What's really being asked
This question tests your ability to apply a systematic, data-driven approach to a complex problem. It's not about simply naming the Memory Profiler. Interviewers want to see that you can move from a vague report ('high memory usage') to a specific, root-caused, and verifiable bug. It distinguishes engineers who know tool names from those who can actually solve performance issues.
The full answer
A strong answer outlines a clear, four-step process. First, use the Memory Profiler to observe memory allocation over time while performing actions suspected of causing leaks, like rotating the screen or navigating back and forth. Second, repeatedly force garbage collection (GC) using the profiler button. If memory usage returns to the same baseline after each GC, there's likely no leak. Third, if memory usage creates a new, higher baseline after each cycle and GC, capture a heap dump. Fourth, analyze the heap dump. Filter for objects that should have been destroyed (e.g., a specific Activity class) and inspect the 'depth from GC roots' to find the reference chain holding it in memory.
The mistakes people make
A weak answer is just 'I'd use the Memory Profiler'. This shows a lack of practical experience. Another red flag is confusing the Memory Profiler with the CPU or Network profilers. Relying solely on a library like LeakCanary without understanding the underlying manual process is also a negative signal, as you need to be able to debug issues LeakCanary might not catch. Finally, guessing the cause ('It's probably large bitmaps') without a methodical process is a sign of a junior approach.
What usually comes next
Expect questions like: 'What is the difference between shallow heap and retained heap?', 'How would you write a test to catch this leak in CI/CD?', or 'Tell me about the most difficult memory leak you've ever debugged.'
A concrete example
A classic leak is a background task, like a custom listener or an old AsyncTask, implemented as a non-static inner class of an Activity. When the device is rotated, the original Activity is destroyed. However, if the background task is still running, it holds an implicit reference to the destroyed Activity instance, preventing the garbage collector from reclaiming its potentially large memory footprint (e.g., a 2MB bitmap). The heap dump would show the destroyed Activity instance being held in memory by the running task object.
Interview question
When systematically diagnosing a memory leak using Android Studio's Memory Profiler, which sequence of steps is most effective?
- a.Observe memory during suspect actions, repeatedly force GC to check for baseline shifts, capture a heap dump if a new baseline forms, and analyze the dump for retained objects and their reference chains.Correct
- b.Immediately capture a heap dump upon observing high memory usage, then filter for large objects like bitmaps, and attempt to fix any obvious strong references.
- c.Implement custom logging for object lifecycle events, set breakpoints to inspect object references at critical points, and manually track object counts to identify unreleased instances.
- d.Monitor CPU and network usage for anomalies, then use the Memory Profiler to identify the largest allocated objects, and finally integrate LeakCanary for automated leak detection.
Why? this is the answer
The systematic process involves observing memory, confirming a leak by forcing garbage collection and noting if memory fails to return to a baseline, then capturing a heap dump for detailed analysis of retained objects and their reference paths. Other options either miss critical diagnostic steps or rely on less systematic methods.
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