Image Loading (Coil & Glide) Interview Questions
DATA › Networking
Is there ever a good reason to reach for Glide over Coil on a new feature in an otherwise Compose-and-coroutines Android app?
What a strong answer covers: Glide is more mature around things Coil handles less natively out of the box, like animated GIF/WebP playback tuning, thumbnail() request chaining, and integrating with legacy View-based custom targets (e.g. drawing into a notification RemoteViews or a widget), so a codebase with heavy legacy View usage or unusual target types may get less friction from Glide. The weak answer is 'always Coil because it's Compose-first'; the strong answer recognizes library choice should follow what the surrounding code and use case actually need, not just the newer library's marketing.
Your image-heavy feed runs fine on a flagship but goes janky and eventually gets OOM-killed on a low-RAM device. Walk me through how you'd diagnose and fix it.
What a strong answer covers: First check whether requested images are sized to their target views rather than full resolution, since that's the single biggest memory lever; then check whether the memory cache size is appropriate for the device (both Coil and Glide can scale cache size off available memory, and you may need a smaller cap on low-memory devices) and whether the app responds to onTrimMemory/ComponentCallbacks2 by trimming the image cache under memory pressure. A subtler cause worth naming is hardware bitmaps: they're cheap for the Java heap since pixel data lives outside it, but that's not free everywhere, some transformations or software rendering fall back and copy the bitmap into normal memory, spiking usage unexpectedly.
You want the hero image on the next screen to already be loaded by the time the user navigates there, so the transition feels instant. How would you implement that prefetch, and how do you stop it from competing with what's currently on screen?
What a strong answer covers: You'd issue a load through the shared ImageLoader/RequestManager ahead of navigation (Coil's ImageLoader.enqueue with a memory-cache-only or disk-preload request, or Glide's preload()) so the bytes and decoded bitmap are ready by the time the destination screen binds its AsyncImage. The nuance is priority: prefetch requests should run at lower priority than on-screen requests so they don't steal bandwidth or decode threads from what the user is actually looking at right now, and they should be cancellable if the user never navigates there.