Reference

Bitmap Memory Management

Bitmap memory management is how Android allocates, caches, and frees decoded images in RAM. A decoded bitmap costs width x height x bytes-per-pixel, so apps downsample, reuse buffers, and evict caches under memory pressure to avoid OutOfMemoryError.

Android developmentAndroid

Bitmap Memory Management

Also known as: android bitmap memory, bitmap cache, bitmap recycle, android bitmap memory

Bitmap memory management is how Android allocates, caches, and frees decoded images in RAM. A decoded bitmap costs width x height x bytes-per-pixel, so apps downsample, reuse buffers, and evict caches under memory pressure to avoid OutOfMemoryError.

  • A decoded ARGB_8888 bitmap costs ~4 bytes/pixel, so megapixel photos can use tens of MB of RAM.
  • Since Android 8.0 bitmap pixels live in native memory, but downsampling (inSampleSize) still matters.
  • Apps cache bitmaps in an LruCache and drop them on onTrimMemory() to avoid OutOfMemoryError.

Why bitmaps are expensive in memory

A Bitmap holds decoded, uncompressed pixels in RAM. The cost is roughly width x height x bytes-per-pixel: the default ARGB_8888 config uses 4 bytes per pixel, so a 12-megapixel photo can consume on the order of 48 MB of RAM when fully decoded, regardless of how small the original JPEG was on disk. This is why image-heavy screens are the most common cause of OutOfMemoryError.

Since Android 8.0 (Oreo), bitmap pixel data is allocated in native memory rather than the Java heap, which reduces GC pressure, but the total footprint is still bounded by the device's RAM. Apps reduce cost by decoding at the size they actually display using BitmapFactory.Options.inSampleSize / inBitmap buffer reuse, or by choosing the cheaper RGB_565 config when alpha isn't needed.

Caching and releasing under pressure

To avoid re-decoding the same image, apps keep an in-memory cache of recently used bitmaps, typically an LruCache sized to a fraction of available RAM, backed by an on-disk cache for slower-changing data. Image libraries like Glide and Coil layer this automatically. The in-memory portion is RAM, while the disk portion shows up under the app's storage.

When the system runs low on memory it calls onTrimMemory() (and the older onLowMemory()); a well-behaved app drops its bitmap caches at the appropriate trim levels so the OS can reclaim RAM instead of killing the process. A cleaner like Cleanor frees exactly these image caches when it clears an app's cached data, which is why memory and cached-data figures shift after a cleanup.

Related terms

Keep reading the reference.

Act on it

Guides and tools for this topic.