Detailed explanation of Android Bitmap cache pool usage

This article introduces how to use cache to improve the smoothness of UI loading, input and sliding. Using memory cache, disk cache, and processing configuration change events will effectively solve this problem.

Displaying a single image in your UI is very simple, but it becomes a bit more complicated if you need to display many images at once. In many cases (such as using ListView, GridView or ViewPager controls), the number of images displayed on the screen and the number of images that will be displayed on the screen are very large (such as browsing a large number of images in a gallery).

In these controls, when a child control is not displayed, the system will reuse the control to display it in a loop to reduce memory consumption. At the same time, the garbage collection mechanism will release the Bitmap resources that have been loaded into the memory (assuming you do not have strong references to these Bitmaps). Generally speaking, this is good, but when the user slides the screen back and forth, in order to ensure the smoothness of the UI and the efficiency of loading pictures, you need to avoid repeatedly processing the pictures that need to be displayed. Using memory cache and disk cache can solve this problem. Using cache allows the control to quickly load the processed pictures.

This article describes how to use caching to improve the smoothness of UI loading, input, and sliding.

Using Memory Cache

Memory caching increases the speed of image access, but it takes up a lot of memory. The LruCache class (which can be used in the Support Library before API 4) is particularly suitable for caching Bitmaps. It saves the most recently used Bitmap objects with strong references (in LinkedHashMap), and deletes infrequently used objects when the cache size reaches a predetermined value.

Note: In the past, the common practice to implement memory cache was to use SoftReference or WeakReference bitmap cache, but this method is not recommended. Starting from Android 2.3 (API Level 9), garbage collection began to forcibly recycle soft/weak references, resulting in no efficiency improvement for these caches.

In addition, before Android 3.0 (API Level 11), these cached Bitmap data are stored in the underlying memory (native memory), and these objects will not be released after the predetermined conditions are met, which may cause the program to exceed the memory limit and crash.

When using LruCache, you need to consider the following factors to choose an appropriate cache quantity parameter:

• How much memory is available in the program
• How many images should be displayed on the screen at the same time? How many images should be cached first to be displayed on the screen that will be seen soon?
• What is the device's screen size and screen density? Extra high screen density (xhdpi, such as the Galaxy Nexus)
• A device with a higher screen density (hdpi, such as the Nexus S) will require more memory to display the same image than a device with a lower screen density (hdpi, such as the Nexus S).
• The size and format of the image determines how much memory each image takes up.
• How often are your images accessed? Are some images accessed much more often than others? If so, you may want to move these frequently accessed images into memory.
• How do you balance quality and quantity? In some cases it is useful to save a large number of low-quality images, and then use a background thread to join a high-quality version when needed.

There is no 100% recipe that works for all applications. You need to analyze your usage and specify your own cache strategy. Using a cache that is too small will not work as expected, while using a cache that is too large will consume more resources.

memory, which may cause a java.lang.OutOfMemory exception or leave little memory for other functions of your program.

Here is an example using LruCache:

 private LruCache<string, bitmap= "" > mMemoryCache; 
 
 @Override
 protected void onCreate(Bundle savedInstanceState) {
 ...
    // Get memory class of this device, exceeding this amount will throw an
 // OutOfMemory exception.
    final int memClass = ((ActivityManager) context.getSystemService(
            Context.ACTIVITY_SERVICE)).getMemoryClass(); 
 
    // Use 1/8th of the available memory for this memory cache.
    final int cacheSize = 1024 * 1024 * memClass / 8; 
 
    mMemoryCache = new LruCache<string, bitmap= "" >(cacheSize) {
 @Override
        protected int sizeOf(String key , Bitmap bitmap) {
            // The cache size will be measured in bytes rather than number of items.
 return bitmap.getByteCount();
 }
 };
 ...
 }
 public void addBitmapToMemoryCache(String key , Bitmap bitmap) {
    if (getBitmapFromMemCache( key ) == null ) {
        mMemoryCache.put( key , bitmap);
 }
 }
 public Bitmap getBitmapFromMemCache(String key ) {
 return mMemoryCache.get( key );
 }

Note: In this example, 1/8 of the program's memory is used for caching. On a normal/hdpi device, this is at least 4MB (32/8) of memory.

On a device with a resolution of 800×480, filling the full-screen GridView with images will use about 1.5MB (800*480*4 bytes) of memory, so about 2.5 pages of images are cached in memory.

When displaying an image in ImageView, first check if it exists in LruCache. If it does, use the cached image. If not, start a background thread to load the image and cache it:

 public void loadBitmap( int resId, ImageView imageView) {
    final String imageKey = String.valueOf(resId);
    final Bitmap bitmap = getBitmapFromMemCache(imageKey);
 if (bitmap != null ) {
        mImageView.setImageBitmap(bitmap);
 } else {
        mImageView.setImageResource(R.drawable.image_placeholder);
        BitmapWorkerTask task = new BitmapWorkerTask(mImageView);
        task.execute( resId );
 }
 }

BitmapWorkerTask needs to add the new image to the cache:

 class BitmapWorkerTask extends AsyncTask< integer , void,= "" bitmap= "" > {
 ...
    // Decode image in background.
 @Override
    protected Bitmap doInBackground( Integer ... params) {
        final Bitmap bitmap = decodeSampledBitmapFromResource(
                getResources(), params[0], 100, 100));
        addBitmapToMemoryCache(String.valueOf(params[0]), bitmap);
 return bitmap;
 }
 ...
 }

The next page will introduce you to two other methods of using disk caching and handling configuration change events.

Using disk cache

In accessing recently used images, the memory cache is fast, but you cannot be sure whether the image exists in the cache. Controls such as GridView may have many images to display, and soon the image data fills up the cache capacity.

Your app may also be interrupted by other tasks, such as an incoming phone call - while your app is in the background, the system may clear the image cache. Once the user resumes using your app, you will need to reprocess the images.

In this case, the disk cache can be used to save these processed images. When these images are not available in the memory cache, they can be loaded from the disk cache, thus omitting the image processing process.

Of course, loading images from disk is much slower than reading them from memory, and disk images should be loaded in a non-UI thread.

Note: If cached images are frequently used, consider using a ContentProvider, such as in a gallery application.

There is a simple DiskLruCache implementation in the sample code. However, Android 4.0 includes a more reliable and recommended DiskLruCache (libcore/luni/src/main/java/libcore/io/DiskLruCache.java). You can easily port this implementation to versions prior to 4.0 (check Google to see if others have done this!).

Here is an updated version of DiskLruCache:

 private DiskLruCache mDiskCache;
 private static final int DISK_CACHE_SIZE = 1024 * 1024 * 10; // 10MB
 private static final String DISK_CACHE_SUBDIR = "thumbnails" ; 
 
 @Override
 protected void onCreate(Bundle savedInstanceState) {
 ...
    //Initialize memory cache
 ...
    File cacheDir = getCacheDir(this, DISK_CACHE_SUBDIR);
    mDiskCache = DiskLruCache.openCache(this, cacheDir, DISK_CACHE_SIZE);
 ...
 }
 class BitmapWorkerTask extends AsyncTask< integer , void,= "" bitmap= "" > {
 ...
    // Decode image in background.
 @Override
    protected Bitmap doInBackground( Integer ... params) {
        final String imageKey = String.valueOf(params[0]); 
 
        // Check disk cache in background thread
        Bitmap bitmap = getBitmapFromDiskCache(imageKey); 
 
        if (bitmap == null ) { // Not found in disk cache
            // Process as normal
            final Bitmap bitmap = decodeSampledBitmapFromResource(
                    getResources(), params[0], 100, 100));
 }
        // Add final bitmap to caches
        addBitmapToCache(String.valueOf(imageKey, bitmap); 
 
 return bitmap;
 }
 ...
 }
 public void addBitmapToCache(String key , Bitmap bitmap) {
 // Add   to memory cache as before
    if (getBitmapFromMemCache( key ) == null ) {
        mMemoryCache.put( key , bitmap);
 }
 // Also add   to disk cache
    if (!mDiskCache.containsKey( key )) {
        mDiskCache.put( key , bitmap);
 }
 }
 public Bitmap getBitmapFromDiskCache(String key ) {
 return mDiskCache.get( key );
 }
 // Creates a unique subdirectory of the designated app cache directory. Tries to use external
 // but if not mounted, falls back on internal storage.
 public   static File getCacheDir(Context context, String uniqueName) {
    // Check if media is mounted or storage is built -in , if so, try and use external cache dir
    // otherwise use internal cache dir
    final String cachePath = Environment.getExternalStorageState() == Environment.MEDIA_MOUNTED
            || !Environment.isExternalStorageRemovable() ?
                    context.getExternalCacheDir().getPath() : context.getCacheDir().getPath();
 return new File(cachePath + File.separator + uniqueName);
 }

The memory cache is checked in the UI thread, and the disk cache is checked in the background thread. Disk operations should never be implemented in the UI thread. When the image is processed, the final result is added to both the memory cache and the disk cache for future use.

Handling configuration change events

Configuration changes at runtime — such as a change in screen orientation — cause Android to destroy the running Activity and then restart it using the new configuration (for details, see Handling Runtime Changes).

You need to be careful to avoid reprocessing all images when the configuration changes to improve the user experience.

Fortunately, you already have a good cache of images in the Using Memory Cache section. This cache can be passed to the new Activity via the Fragment (which will be saved via the setRetainInstance(true) method)

When the Activity is restarted, the Fragment is reattached to the Activity, and you can use the Fragment to obtain the cached object.

Here is an example of saving a cache in a Fragment:

 private LruCache<string, bitmap= "" > mMemoryCache;
 @Override
 protected void onCreate(Bundle savedInstanceState) {
 ...
    RetainFragment mRetainFragment = RetainFragment.findOrCreateRetainFragment(getFragmentManager());
    mMemoryCache = RetainFragment.mRetainedCache;
    if (mMemoryCache == null ) {
        mMemoryCache = new LruCache<string, bitmap= "" >(cacheSize) {
            ... // Initialize cache here as usual
 }
        mRetainFragment.mRetainedCache = mMemoryCache;
 }
 ...
 }
 class RetainFragment extends Fragment {
    private static final String TAG = "RetainFragment" ;
 public LruCache<string, bitmap= "" > mRetainedCache; 
 
 public RetainFragment() {}
 public   static RetainFragment findOrCreateRetainFragment(FragmentManager fm) {
        RetainFragment fragment = (RetainFragment) fm.findFragmentByTag(TAG);
        if (fragment == null ) {
            fragment = new RetainFragment();
 }
 return fragment;
 }
 @Override
 public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        <strong>setRetainInstance( true );</strong>
 }
 }

In addition, you can try to rotate the device's screen direction with and without Fragment to view the specific image loading status.