Analyzing Android Bitmap Memory Usage and Optimization Strategies

The author, a member of the vivo Internet client team, describes how OutOfMemory (OOM) issues in the vivo Game Center are often caused not only by memory leaks but also by improper handling of images.

Using a simple demo that displays a 350×350 Iron Man bitmap, the article shows that a 36 KB image file can occupy about 2.4 MB of RAM (≈70× its disk size) when loaded into an ImageView . The memory consumption is revealed through Android Studio's Profiler → Memory → Heap Dump feature.

Two popular image‑loading libraries, Glide and Picasso , are compared. Picasso keeps the original image dimensions, so loading the 350×350 bitmap into a 200×200 view consumes roughly 0.49 MB. Glide, by default, scales the image to the target ImageView size, resulting in only about 0.16 MB for the same view.

The article provides code snippets to achieve equivalent results with Picasso using fit() and with Glide using centerInside() :

Picasso.get().load(IMAGE_URL).fit().into(imageVIEW)

Glide.with(this).load(IMAGE_URL).centerInside().into(imageView)

A formula for estimating bitmap memory is introduced:

Image memory = image quality × width × height

For most Android devices the default bitmap config is ARGB_8888 (32‑bit, 4 bytes per pixel). The author recommends using RGB_565 (16‑bit) in low‑end devices to halve memory usage, except when transparency or high‑quality gradients are required.

The impact of drawable resource qualifiers (mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi) on memory is examined. By placing the same image in drawable‑xhdpi and drawable‑xxxhdpi and displaying them on a xxxhdpi device, the final on‑screen size (≈613 px) and memory consumption (≈1.5 MB) are identical, proving that the displayed pixel dimensions—not the original file resolution—determine RAM usage.

Practical optimization steps are suggested:

Load high‑quality ARGB_8888 images on mid‑to‑high‑end devices and RGB_565 on low‑end devices.

Avoid using RGB_565 for images with transparency.

Match source image dimensions to the target ImageView size.

Prefer xxhdpi/xxxhdpi resources for appropriate screen densities.

An example of a custom Glide module written in Kotlin demonstrates how to switch bitmap formats based on device RAM and OS version:

@GlideModule
class MyGlideModule : AppGlideModule() {
    override fun applyOptions(context: Context, builder: GlideBuilder) {
        builder.setDefaultRequestOptions(RequestOptions().format(getBitmapQuality()))
    }
    private fun getBitmapQuality(): DecodeFormat {
        return if (Build.VERSION.SDK_INT < Build.VERSION_CODES.N || hasLowRam()) {
            // Low‑end devices use RGB_565 to save memory
            DecodeFormat.PREFER_RGB_565
        } else {
            DecodeFormat.PREFER_ARGB_8888
        }
    }
}

Additional tools such as MAT (Memory Analyzer Tool) and GIMP can be used to extract and view bitmap data from heap dumps, and the open‑source DoKit library can help locate large images at runtime.

In summary, careful selection of image quality, proper scaling, and appropriate drawable resources are essential to prevent OOM crashes in Android applications.