Jank & Rendering Interview Questions
PERFORMANCE › Runtime
Walk me through how you'd diagnose jank in a RecyclerView list that only shows up on mid-tier devices, not on your flagship test device.
What a strong answer covers: A strong answer profiles on an actual mid-tier unit with Perfetto/systrace rather than trusting flagship numbers, since lower core count, slower storage, and less cache expose main-thread work, like item binding, image decode, or complex layouts, that a flagship's headroom hides. Should mention concrete fixes: flattening the item view hierarchy, offloading bitmap decode off the main thread, and using DiffUtil with stable IDs to cut unnecessary rebinds, then validating with FrameTimingMetric on a representative low-end device going forward.
When does overdraw actually matter for jank versus just being visual noise in the debug overlay? What's the real-world scenario where fixing it moves the needle?
What a strong answer covers: Overdraw matters when the GPU becomes the bottleneck, typically on large fill areas like stacked backgrounds or translucent overlays on lower-end GPUs or high pixel-density screens with limited fill-rate; on a flagship with headroom, moderate overdraw is often invisible in frame times. A strong answer gives a concrete diagnostic: check whether RenderThread/GPU time is the long pole in a systrace before chasing the overlay's red zones, since fixing overdraw when the main thread is the actual bottleneck wastes effort.
You've optimized a Compose screen's recomposition count to near zero but users still report jank while scrolling. What else could be the bottleneck, and how would you isolate it?
What a strong answer covers: Should point beyond composition to layout and draw, and to work happening outside Compose entirely: expensive measure/layout passes from nested weights or intrinsic measurements, large image decode or bitmap allocation on the main thread, RenderThread/GPU-bound overdraw, or synchronous I/O or GC pauses unrelated to recomposition count. A strong answer stresses recomposition count is only one input to frame time, and the next step is a Perfetto trace to see which pipeline phase, measure, layout, draw, or RenderThread, is actually consuming the frame budget.