What is Level 3 Cache?
- Memory cache, priority loading, fastest
- Local cache, sub-priority loading, fast
- Network cache, finally loading, slow speed, waste traffic
Why do I need to perform Level 3 cache
The most practical significance of the third-level caching strategy is to reduce unnecessary traffic consumption and increase loading speed.
Today's APP network interaction seems to be essential, and it is normal to obtain pictures through the Internet. However, every time you start an application, you have to get pictures from the network, or you want to browse some pictures repeatedly, and you need to get them from the network every time you browse, which consumes more traffic. In terms of today's traffic charges, it will definitely easily affect the number of users.
There is also the network loading pictures, which sometimes load very slowly, affecting the user experience.
In addition, from a development perspective, the creation of Bitmap is very time-consuming and memory-consuming, which may lead to frequent GC. Using caching strategies will load Bitmap more efficiently, reducing lag, and thus reducing read time.
The main function of memory cache is to prevent applications from repeatedly reading image data into memory, while hard disk cache is to prevent applications from repeatedly downloading and reading data from the network or other places.
The principle of level 3 cache
- When loading for the first time, it loads over the network, obtains pictures, and saves them to memory and SD cards.
- When running the APP later, priority is given to accessing the image cache in memory.
- If memory does not exist, the picture from the local SD card is loaded.
The specific cache strategy can be as follows: memory is used as the first-level cache, local is used as the second-level cache, and network loads as the last. Among them, the memory uses LruCache, which internally uses LinkedhashMap to hold strong references to external cache objects; for local cache, DiskLruCache is used. When loading the picture, first use the LRU method to search. The specified content cannot be found. Local search is carried out according to the third-level cache method, and the network has not been loaded.
Image cache code implementation
It is not difficult to implement a Level 3 cache tool class by yourself. It can probably be like this:
public class BitmapUtil{
//Singleton Mode //···
public void displayImage(ImageView img, String url){
Bitmap bitmap;
//Memory cache, url is used as a unique identifier bitmap = loadBitmapFromMemoryCache(url);
if(bitmap != null){
(bitmap);
return ;
}
//Local cache bitmap = loadBitmapFromDiskCache(url);
if(bitmap != null){
(bitmap);
//Then save the local cache to the memory cache return ;
}
//Network cache bitmap = loadBitmapFromNet(url);
if(bitmap != null){
(bitmap);
//Same way, save the cache to memory and local return;
}
}
}
I won’t talk about it in detail, there are many similar articles available for reference on the Internet.
The core implementation of memory cache is basically to obtain the maximum memory of the APP, and then use LruCache<url , bitmap> put in when setting. It will control the memory to a certain size according to the algorithm that is least used recently, and automatically recycle it when it exceeds the value.
Another thing to note is that when the url is used as a key, it will be processed using the MD5 algorithm, and finally its MD5 value is used as the key. This may be to avoid the use of some special characters.
About Glide's cache
In fact, now it is rare to encapsulate a level three cache strategy by itself, and add cache strategies to many image frameworks, making it easier to implement. Here we take Glide as an example.
The use of Glide is basically solved in one line of code. Like below
//Load local picturesFile file = new File(getExternalCacheDir() + "/"); (this).load(file).into(imageView); // Load application resourcesint resource = ; (this).load(resource).into(imageView); // Load binary streambyte[] image = getImageBytes(); (this).load(image).into(imageView); // Load the Uri objectUri imageUri = getImageUri(); (this).load(imageUri).into(imageView);
Of course, it is best to package it twice when applied to the project. These are not the subject of this article. Let's go back to the cache.
Glide's memory cache
Glide has enabled memory cache by default. As long as you load a picture through Glide, it will cache it into memory. As long as it has not been cleaned from memory, it will be loaded from the memory cache next time you use Glide. This greatly improves the efficiency of image loading.
Of course, if you have special requirements, you can add a line of code to turn off the memory cache that is enabled by default.
(this) .load(url) .skipMemoryCache(true)//Close memory cache .into(imageView);
Glide's memory cache is actually not much different from what we said above. It also uses the LruCache algorithm, but it also combines a weak reference mechanism to jointly complete the memory cache function.
Glide's hard drive cache
About Glide hard drive cache is also very simple to use.
(this) .load(url) .diskCacheStrategy() .into(imageView);
A diskCacheStrategy( ) method can adjust its hard disk cache strategy. There are four parameters that can be passed in:
- : Indicates that no content is cached.
- : Indicates that only the original image is cached.
- : Indicates that only converted pictures are cached (default option).
- : It means that both the original image is cached and the converted image is cached.
Glide's hard disk cache defaults to compress and convert pictures and then cache them to the hard disk. This way of processing will avoid OOM often.
If you need to change the hard disk cache policy, you only need to change the parameters passed in.
The above is all the content of this article. I hope it will be helpful to everyone's study and I hope everyone will support me more.