Which Android Studio Profiler tool diagnoses high memory usage and leaks?

WHAT THIS TESTS: This question tests whether you treat memory investigation as a structured debugging workflow rather than guesswork. The interviewer wants to see that you know the specific tool inside Android Studio Profiler designed for heap analysis, and that you understand the difference between high memory usage from legitimate large allocations versus a true leak where objects survive garbage collection due to accidental strong references. Senior engineers are expected to articulate how to isolate the leak, quantify it with retained heap metrics, and trace the exact reference path preventing collection.

A GOOD ANSWER COVERS: First, name the Memory Profiler in Android Studio Profiler, not just the profiler in general. Second, describe capturing a heap dump after reproducing the suspected leak, then filtering the heap for classes that should have been garbage collected such as Activity or Fragment instances. Third, explain looking at retained size and instance count to confirm abnormal accumulation. Fourth, detail tracing the reference chain from the leaked object to the nearest garbage collection root to identify the retaining object, which could be a static field, a lingering listener, or an improperly scoped context reference. Fifth, mention using the Allocation Tracker or Live Allocations to spot memory churn if the issue is excessive temporary allocations rather than a leak.

COMMON WRONG ANSWERS: A major red flag is confusing the Memory Profiler with the CPU Profiler, Network Profiler, or Energy Profiler. Another weak pattern is saying you would look for large bitmaps or big objects without explaining how you determine if those objects are leaked versus legitimately in use. Stopping at "I would check for memory leaks" without naming heap dumps or reference chains is too vague. Suggesting System.gc calls as a fix or relying solely on LeakCanary without being able to explain manual heap dump analysis also signals shallow experience.

LIKELY FOLLOW-UPS: The interviewer may ask how you would distinguish between a memory leak and excessive memory churn. They might ask what specific patterns cause Activity leaks, such as anonymous inner classes holding implicit outer class references, static View or Context references, or unregistered listeners. They could also ask how you would verify a fix, or how you would investigate native memory usage if the Java heap looks normal.

ONE CONCRETE EXAMPLE: Suppose users report that rotating the phone three times causes an OutOfMemoryError. You would open the Memory Profiler, perform three rotations, then capture a heap dump. In the heap dump, you filter for MainActivity and see three instances with a retained size of several megabytes each. You select one instance and inspect its reference chain, discovering that a static HashMap in a singleton cache is holding onto the Activity context as a key. The fix is to switch the cache to hold Application context or use WeakReference.