Core Concepts
Memory and GC
Why a memory budget is a design constraint, and how GC pauses may cause dropped frames.
Half of all interview-grade mobile design questions hinge on memory. Photo gallery, newsfeed, doc editor all arrive at the same arithmetic: a 12 MP JPEG decoded into the Java heap is 46 MB, the heap caps between 256 MB and 512 MB depending on device, and the user is scrolling. A candidate who can explain where those bytes live, who frees them, and what the OS does when there is no room is ahead of one quoting Bitmap.recycle(). This page covers ART's GC topology, the three heaps that share physical RAM, bitmap accounting across API versions, the two OOM modes, GC pauses inside a 16.6 ms frame budget, and the reference-type vocabulary. The frame pipeline is How Rendering Works; the loader pipeline is Image Loading.
The heap topology
Android replaced Dalvik with ART at API 21 and has incrementally rewritten the collector since. Since Android 8.0 (API 26) the default collector is Concurrent Copying (CC), a region-based copying collector; it became generational in Android 10 (API 29). The current shape is three regions inside the managed Java heap plus two more heaps outside it.