Android memory optimization LRUCache and Disklrucache

In the daily adroid development we often encounter the need to deal with a large number of images, but the memory of the Android phone is limited how to avoid the phone memory overflow caused by the application program Oom,google provides two ways to solve

LruCache

LruCache (This class is available in the ANDROID-SUPPORT-V4 package). This class is ideal for caching images, and its main algorithm is to store recently used objects in linkedhashmap with strong references, and to remove the least recently used objects from memory before the cached value reaches a predetermined value.

In the past, we often used an implementation of a very popular memory caching technique, either soft or weak (SoftReference or weakreference). However, this is no longer recommended because, starting with Android 2.3 (API Level 9), the garbage collector is more inclined to reclaim objects holding soft or weak references, which makes soft and weak references less reliable. In addition, in Android 3.0 (API level 11), image data is stored in local memory, so it cannot be released in a predictable way, which poses a potential risk of memory overflow and crash of the application.

To be able to choose a suitable cache size for LRUCache, there are several factors that should be taken into account, such as:

• How much memory can your device allocate for each application?
• How many pictures can be displayed on the device screen at a time? How many images need to be preloaded, as it is possible to be displayed on the screen soon?
• What is the screen size and resolution of your device? An ultra-high-resolution device, such as a Galaxy nexus, requires more cache space than a lower-resolution device, such as a Nexus S, when holding the same number of images.
• The size and size of the picture, and how much memory space each image occupies.
• How often are the images accessed? Will there be some images that are more frequently accessed than other images? If so, you might want to have some images reside in memory, or use multiple LRUCache objects to distinguish different groups of pictures.
• Can you maintain a good balance between quantity and quality? In some cases, it is more effective to store multiple low-pixel images, while loads in the background to load high-resolution images.

And not a specified cache size can satisfy all applications, which is up to you. You should analyze the usage of the program's memory and then work out a suitable solution. A cache space that is too small can cause images to be released and reloaded frequently, which does not benefit. A cache space that is too large can still cause java.lang.OutOfMemory exceptions.

Here is an example of using LruCache to cache a picture:

Private lrucache<string, bitmap> Mmemorycache;

@Override
protected void onCreate (Bundle savedinstancestate) {
//Gets the maximum amount of available memory, Using memory beyond this value can cause outofmemory exceptions. The
//LRUCache passes through the constructor function to the cache value, in kilobytes.
int maxmemory = (int) (Runtime.getruntime (). MaxMemory ()/1024);
//Use 1/8 of the maximum available memory value as the size of the cache.
int cacheSize = MAXMEMORY/8;
Mmemorycache = new lrucache<string, bitmap> (cacheSize) {
@Override
protected int sizeOf (String key, B Itmap bitmap) {
//override this method to measure the size of each picture, returning the number of pictures by default.
return Bitmap.getbytecount ()/1024;
}
};
}

public void Addbitmaptomemorycache (String key, Bitmap Bitmap) {
if (getbitmapfrommemcache (key) = = NULL {
Mmemorycache.put (key, bitmap);
}
}

Public Bitmap getbitmapfrommemcache (String key) {
return mmemorycache.get (key);
}

In this example, one-eighth of the memory allocated by the system to the application is used as the cache size. This will probably have 4 megabytes (32/8) of cache space in the high-profile handsets. A full-screen GridView is populated with 4 800x480 resolution images, which will probably take up 1.5 megabytes of space (800*480*4). Therefore, this cache size can store 2.5 pages of pictures.
When a picture is loaded into the ImageView, it is first checked in the LruCache cache. If the corresponding key value is found, the ImageView is updated immediately, otherwise a background thread is opened to load the image.

public void LoadBitmap (int resId, ImageView ImageView) {
Final String ImageKey = string.valueof (resId);
Final Bitmap Bitmap = Getbitmapfrommemcache (ImageKey);
if (bitmap! = null) {
Imageview.setimagebitmap (bitmap);
} else {
Imageview.setimageresource (R.drawable.image_placeholder);
Bitmapworkertask task = new Bitmapworkertask (ImageView);
Task.execute (RESID);
}
}

Bitmapworkertask also puts the key-value pairs of the newly loaded pictures into the cache.

Class Bitmapworkertask extends Asynctask<integer, Void, bitmap> {
Load the picture in the background.
@Override
Protected Bitmap doinbackground (Integer ... params) {
Final Bitmap Bitmap = Decodesampledbitmapfromresource (
Getresources (), params[0], 100, 100);
Addbitmaptomemorycache (String.valueof (Params[0]), bitmap);
return bitmap;
}
}

1, LruCache is a caching mechanism based on LRU algorithm;

2, the LRU algorithm principle is to remove the least recently used data, of course, the premise is that the current amount of data is greater than the maximum value set.

3, LruCache does not really release memory, just remove the data from the map, really free memory or to manually release the user

Disklrucache

The above introduction can be known that LRUCache can effectively avoid the program memory overflow, but LRUCache only manage the memory of the image storage and release, if the picture is removed from memory, then need to reload the image from the network, which is obviously very time-consuming. In this, Google also provides a set of hard disk cache solutions: Disklrucache (not officially written by Google, but obtained official certification)

Refer to this article for an introduction to it http://www.tuicool.com/articles/JB7RNj

For more information please follow my personal public number

Android memory optimization LRUCache and Disklrucache