In depth understanding of Android image caching mechanism

In depth understanding of Android image caching mechanism

Android loading a picture into the user interface is very simple, but when loading multiple pictures at a time, the situation becomes more complicated. In many cases (such as listview, GridView, viewpager and other components), there is basically no limit to the number of pictures that have been displayed on the screen and are about to slide to the current screen.

These components will reduce memory usage by reusing the sub views of the removed screen, and the garbage collector will release the downloaded images that are no longer used in time. These are good methods, but in order to maintain a smooth and fast loading user interface, you should avoid reprocessing the images when you return to a page again. Memory cache and disk cache can help us do this. They allow components to quickly reload processed images.

Use memory cache

Memory caching allows fast access to pictures, but it takes up valuable memory of the app. Lrucache class (also supported by API level 4's support library) is particularly suitable for image caching. It uses a strongly referenced LinkedHashMap to save recently used objects, and will remove the least recently used objects before the number of caches exceeds the preset size.

Note: in the past, the popular memory caching scheme used to use soft references or weak references to cache pictures. However, this is not recommended now, because since Android 2.3 (API level 9), the garbage collector prefers to recycle soft references or weak references first, which makes them inefficient. In addition, before Android 3.0 (API level 11), the pixel data of the picture was stored in the local memory, which was released in an unpredictable way. Therefore, the app may exceed the memory limit or even crash.

In order to set an appropriate size for lrucache, the following factors should be considered:

1. How much memory is available for your activity or app?

2. How many pictures are displayed on the screen at a time? How many pictures need to be prepared in advance so that they can be loaded onto the screen at any time?

3. What is the screen size and density of the equipment? High resolution (xhdpi) devices such as the galaxy nexus require more cache space when caching the same number of pictures than devices with resolution (hdpi) such as the nexus s.

4. What is the size and configuration of the picture? How much memory does each picture occupy?

5. How often are pictures accessed? Are some pictures visited more frequently than others? If so, you may be able to keep some pictures in memory all the time or set different lrucache objects for different picture groups.

6. Can you balance the relationship between picture quality and quantity? Sometimes it is more useful to store more low-quality pictures. When necessary, Download high-quality pictures through background tasks.

There is no specific size and calculation formula applicable to all apps. You need to analyze your usage and get an appropriate scheme. When a cache is too small, it will lead to useless additional overhead, and when the cache is too large, it may also cause java.lang.outofmemory exceptions. In addition, the larger the cache, the smaller the memory left for other parts of the app.

Here is an example of setting lrucache for pictures:

Note: in the above example, we allocated 1 / 8 of the application memory as the cache size, and at least 4MB (32 / 8) on a normal / hdpi device. A GridView filled with pictures on an 800 * 480 resolution screen occupies about 1.5MB (800 * 480 * 4byte) of memory, so the cache can cache at least 2.5 pages of such pictures.

When loading an image into ImageView, first check lrucache. If an image is found, it will be directly used to update ImageView. If it is not found, a background thread will be started to process it:

In the above thread, after decoding the picture, you also need to add it to the memory cache:

Using disk cache

Although the memory cache is very useful for quick access to recently used pictures, you can't guarantee that the pictures you need are in the cache. Components like GridView that display a large amount of data can easily fill the memory cache. Your app may also be interrupted by tasks such as a phone. When the app is switched to the background, it may also be killed, and the memory cache may also be destroyed. Once the user returns to the previous interface, your app still needs to reprocess each picture.

The disk cache can be used to assist in storing processed pictures. When the pictures in the memory cache are not available, you can find them from the disk cache, so as to reduce the loading times. Of course, reading pictures from disk is slower than reading from memory, and the reading time is unpredictable, so you need to use a background thread to read them.

Note: ContentProvider may be a suitable place to store frequently accessed pictures, such as in the image gallery application.

The example code here is disklrucache stripped from Android source code. The following is the updated example code, which adds disk cache on the basis of memory cache:

Note: disk operation is required to initialize the disk cache, so it should not be performed in the main thread. However, this means that access operations may occur before the disk cache is initialized. In order to solve this problem, in the above implementation, a lock object is used to ensure that data can be read from the disk cache only after the disk cache is initialized.

The memory cache can be read directly in the UI thread. However, the disk cache must be checked in the background thread, and the disk operation should not occur in the UI thread. When the picture processing is completed, be sure to add the final picture to the memory cache and disk cache for subsequent use.

The above is a detailed explanation of the Android image caching mechanism. If you have any questions, please leave a message or go to the community of this site for communication and discussion. Thank you for reading. I hope it can help you. Thank you for your support to this site!