The Memory Devourer

Loading full-resolution Bitmaps without downsampling to the display size

A 4MP camera photo decoded at full resolution uses ~16MB of heap on a device with a 48MB app heap limit. Using BitmapFactory.Options.inSampleSize to decode at display resolution reduces this to under 1MB — a 16x improvement that fits dozens of images in the same memory.

In-memory Bitmap cache with no eviction policy — growing without bound

Caching Bitmaps without an LRU eviction policy means the cache size grows with every image viewed in a session. After scrolling through 50 posts with multiple images each, the cache could hold hundreds of megabytes — more than the entire device RAM on low-end phones.

Bitmap references held in static fields, preventing garbage collection

Static fields have application-lifetime scope. A Bitmap referenced statically is never eligible for garbage collection regardless of memory pressure. Static image caches were common before WeakReference-based and LRU-based caching became standard practice.

Bitmap decoding performed on the main thread causing ANR dialogs

Main-thread Bitmap decoding causes ANRs and UI freezing — not out-of-memory crashes. The symptom here is OOM from heap exhaustion, not a blocked main thread.

Not using an image loading library like Glide or Picasso

The absence of a library is a consequence of the era, not the cause of OOM. The root failures were specific memory management mistakes — any of which would cause OOM even with a loading library if its configuration was wrong.

RecyclerView not using the ViewHolder pattern — inflating layouts on every bind

Missing ViewHolder causes jank and CPU overhead from layout inflation — not the OOM crashes described here. Heap dumps showing hundreds of Bitmap objects point directly to memory mismanagement.