Design an Image Loading Library

Tier 1 — Memory Cache: stores decoded Bitmap objects in RAM. Sub-millisecond access. Sized to ~15% of app heap. Evicts via LRU. Tier 2 — Disk Cache: stores compressed image bytes (JPEG/PNG) as files. 5–50ms access. Sized to ~250MB. Evicts via LRU across files. Tier 3 — Network: the origin server. 200ms–3s. Unlimited but costs bandwidth. The library checks each tier in order — memory first, then disk, then network — and writes the result back to cheaper tiers on a miss.

Decoded Bitmaps are large but fast to display — a 1080×1920 ARGB_8888 image is 8MB. Keeping them decoded in memory means zero CPU cost on repeated display. But 8MB per image means the memory cache can only hold ~4 images at this size before OOM. Disk cache stores the original compressed JPEG (~100KB) — 80× smaller — so you can cache hundreds of images without filling the disk. The trade-off: disk hits still pay the decode CPU cost, but save the network round-trip.

LRU (Least Recently Used) evicts the item that was accessed furthest back in time. For image caches, it works because temporal locality holds — if you viewed an image recently, you're likely to view it again soon (e.g. scrolling a list up and down). The alternative, FIFO, would evict images in insertion order regardless of access recency. Android's LruCache uses a LinkedHashMap with accessOrder = true — on every get/put, the accessed entry moves to the tail. Eviction picks the head (least recently used).

A BitmapPool is a collection of recycled Bitmap objects grouped by (width, height, config). When the memory cache evicts a Bitmap, instead of letting it be GC'd, it's placed in the pool. The next decode that needs a Bitmap of the same size borrows from the pool and sets it as BitmapFactory.Options.inBitmap — the decoder writes new pixels directly into the existing allocation. The benefit: zero heap allocation for the decode, eliminating GC pauses. In a RecyclerView scrolling 10 images/second, this prevents the GC from triggering every few frames and causing jank.

inSampleSize is a BitmapFactory.Options field that downsamples an image during decode. A value of 2 halves each dimension (¼ the pixels); 4 gives 1/16 the pixels. Without it, loading a 4K photo (16MB decoded) into a 100×100 thumbnail wastes 640× the memory. The correct flow: (1) Set inJustDecodeBounds = true and decode to get image dimensions without allocating pixels. (2) Calculate the minimum inSampleSize that produces an output ≥ target dimensions. (3) Set inJustDecodeBounds = false and decode at that sample size. Every production library does this.

Maintain a ConcurrentHashMap<CacheKey, Deferred<Bitmap>> of in-flight requests. When a second request arrives for the same URL+dimensions, check the map — if a Deferred already exists, call .await() on it instead of starting a new coroutine. All 50 cells share one network request and one decode. Use getOrPut atomically to avoid races. Clean up the entry in a finally block so the next independent load after completion doesn't incorrectly reuse a finished Deferred.

Store the coroutine Job as a tag on the target view: view.setTag(R.id.image_loader_tag, job). When a new request starts on the same view, retrieve the old tag and call job.cancel() before launching the new one. In a RecyclerView, onBindViewHolder calls load(url) — which always cancels the previous job on that view instance. In Compose, use LaunchedEffect(url) — it automatically cancels and re-launches whenever the URL key changes. No manual cancellation code needed.

The same URL loaded into a 100×100 thumbnail and a 1080×1080 full-screen view produces two different decoded Bitmaps. If you keyed only by URL, the 1080×1080 Bitmap would be returned for the 100×100 slot — wasting 100× the memory. Conversely, the 100×100 Bitmap would look pixelated in the full-screen view. The correct key is CacheKey(url, width, height, config, transformations). This means the same URL can have multiple entries in the memory cache, each optimised for a specific target size.

Android calls onTrimMemory(level) on the Application when the system is under memory pressure. The image loader should register a ComponentCallbacks2 listener and respond proportionally: TRIM_MEMORY_UI_HIDDEN → clear the memory cache (app is backgrounded, no UI needs images). TRIM_MEMORY_RUNNING_CRITICAL → clear memory cache + BitmapPool. TRIM_MEMORY_COMPLETE → clear everything. Not responding to these callbacks is a common source of OOM kills when the app is backgrounded — Android may kill the process if you're holding large Bitmap allocations unnecessarily.

Glide maintains a separate ActiveResources map of WeakReference<Bitmap> for images currently displayed on screen. The problem it solves: if image A is displayed in a large list and the LRU cache fills up with other images, image A could be evicted — but it's still being drawn! When the view releases the Bitmap (scrolled off screen), it moves from Active Resources to the LRU cache. When it's needed again, the LRU cache returns it without any re-decode. This two-layer approach means on-screen images are never evicted, while off-screen images compete fairly for LRU space.

Design every component behind an interface: ImageCache, DiskCache, Fetcher, Decoder, BitmapPool. In tests, inject fake implementations. For the Fetcher, use MockWebServer to serve test images. Test the Engine's deduplication with a slow fake Fetcher that uses a Semaphore — fire 10 concurrent requests and assert only one fetch happens. Test LRU eviction by inserting entries until capacity is exceeded and asserting the oldest entry is gone. Test lifecycle cancellation by calling job.cancel() mid-fetch and asserting no view update occurs.

Use an atomic write pattern: write to a temp file (key.tmp), then rename to the final path (key) when complete. File rename is atomic on POSIX systems. This prevents a concurrent reader from seeing a partially written file. DiskLruCache (used by OkHttp and Glide) implements this pattern. Additionally, use a per-key lock (ConcurrentHashMap<String, Mutex>) to prevent two coroutines from fetching and writing the same key simultaneously — only one should win, the other should wait and then get a cache hit.

Define a Fetcher interface with a type parameter: interface Fetcher<T> { suspend fun fetch(data: T): ByteArray }. Register fetchers per source type in a FetcherRegistry: HttpFetcher for URLs, FileFetcher for file paths, ResourceFetcher for R.drawable IDs, ContentUriFetcher for content:// URIs. The Engine inspects the request's data type and delegates to the matching fetcher. This is exactly how Coil's Fetcher SPI works — you can also register custom fetchers for proprietary data sources without modifying the library.

Use a RecyclerView.OnScrollListener to detect scroll direction and calculate which items will enter the viewport. Call imageLoader.preload(url, size) for the next 3–5 items — this runs the full pipeline (fetch → decode → cache) without attaching to any view. Use a lower-priority coroutine dispatcher for preloads so they don't compete with visible-item loads. Cancel preloads when scroll direction reverses. Coil's Preloader and Glide's RecyclerViewPreloader implement this. The result: near-instant image display as items scroll into view, reducing the blank-placeholder window from ~200ms to near zero.

Key differences: (1) Coroutines-first: Coil is built entirely on Kotlin coroutines; Glide uses Java threads + callbacks, making Coil's lifecycle cancellation cleaner. (2) OkHttp integration: Coil uses OkHttp natively and defers to OkHttp's HTTP cache, avoiding a separate disk cache layer. Glide manages its own disk cache. (3) No static singleton by default: Coil encourages injecting a custom ImageLoader instance, making it more testable. (4) Compose-first API: Coil has first-class AsyncImage composable; Glide added Compose support later. (5) Coil is newer and smaller in APK size (~3MB vs Glide's ~5MB).

Transformations must be included in the CacheKey. A circle-cropped version and the original of the same URL are different Bitmaps and must be stored separately. The key typically includes a hash of the transformation class name and parameters. For disk cache, you have a choice: cache the transformed or untransformed bytes. Caching untransformed bytes is more space-efficient (one file serves multiple transformations), but you always pay the transform CPU cost on disk hits. Caching transformed Bitmaps in memory is the right call — memory hits are free, and memory cache entries are per-transformation anyway.

Key patterns: (1) Use AsyncImage with a rememberAsyncImagePainter — Compose's LaunchedEffect handles cancellation automatically when the composable leaves composition. (2) Set explicit contentScale and size modifiers so the library can downscale to exactly the render size. (3) Enable allowHardware = false only if you need to draw on Canvas — hardware Bitmaps are faster for display. (4) Use ImageLoader with a generous memory cache (more items are in the composition tree simultaneously than in a View RecyclerView). (5) Consider Coil.imageLoader as a singleton — creating a new ImageLoader per composable defeats the shared cache.

Two approaches: (1) Size-based eviction: If a single image is larger than the disk cache max size, skip writing it to disk cache entirely — it would evict everything else. Check the content-length header before writing and skip if it exceeds a threshold (e.g. 10MB). (2) Streaming decode: For very large images (panoramas, high-res photos), stream decode them using BitmapRegionDecoder instead of loading the full bytes into memory. Decode only the visible region. This is how photo viewer apps like Google Photos handle extremely large images without OOM.

Three layers: (1) Microbenchmarks — use androidx.benchmark to measure decode(bytes) time, memoryCache.get(key) latency, and LRU eviction throughput in isolation. (2) Macro benchmarks — use MacrobenchmarkRule to measure scroll frame rate (jank %) in a RecyclerView with your library vs Coil vs Glide on real devices. (3) Memory profiling — use Android Profiler to compare heap allocations during a 30-second scroll session. A well-implemented BitmapPool should show near-zero Bitmap allocations after the first pass through the list. Track GC events per second as the primary signal of pool effectiveness.

Strong Staff+ answer: (1) Coroutines-native from day one — Glide's Java callback model makes coroutine integration awkward. Design the Engine as a suspend function chain from the start. (2) Delegate HTTP caching to OkHttp — maintaining a custom disk cache alongside OkHttp's HTTP cache creates complexity and potential inconsistency. Let OkHttp own the byte cache; own only the decoded Bitmap cache. (3) Compose as the primary target — design the Target interface as a composable state holder, not an ImageView wrapper. (4) KMP-ready data layer — the cache key, LRU logic, and decoder interface could be Kotlin Multiplatform, sharing code with an iOS SwiftUI image loader.