ART Runtime Interview Questions
ANDROID › System
Explain why a freshly installed app feels slower on its first few launches than after a week of use, tying it to what ART is doing behind the scenes.
What a strong answer covers: Early launches run mostly interpreted or freshly-JITed bytecode because dex2oat hasn't AOT-compiled the app's hot methods yet; ART builds a profile of frequently-executed methods across launches, and background dexopt (using the speed-profile filter) only compiles those hot paths to native code once the device is idle and charging. The trap is assuming JIT catches up quickly on its own; in practice that idle-and-charging window can take days, which is exactly the gap Baseline Profiles are meant to close.
You're deciding whether it's worth the engineering effort to ship a Baseline Profile, given ART already does profile-guided AOT compilation on-device over time. What's the actual argument for doing it anyway?
What a strong answer covers: On-device profiling only kicks in after enough usage plus idle-and-charging windows, so day-one users, people who reinstall or update frequently, or anyone who rarely leaves their phone idle-charging never benefit from it in time. A Baseline Profile ships pre-computed hot-path info at install, so even the very first cold start is fast; the trade-off is that it only helps if it's kept current with the app's actual critical user journeys, and it adds build complexity most teams underinvest in maintaining.
Your app hits OutOfMemoryError under moderate use despite the Java heap looking reasonable in the profiler. How does ART's concurrent GC model inform where you'd look, and what's a common misconception about 'concurrent' GC here?
What a strong answer covers: The misconception is that 'concurrent' means pause-free; ART's concurrent copying collector still needs brief stop-the-world pauses for things like thread suspension during root marking, and object-moving GC has real CPU and memory overhead of its own. A senior engineer should also look past the Java heap entirely, since native and off-heap allocations like bitmaps and direct ByteBuffers, plus per-app heap limits that vary by device and whether largeHeap is set, can drive OOM even when the visible Java heap graph looks fine.