After we've looked at loading, displaying and manipulating images, we'll move on to optimize the process. One of the fundamental features of successful and efficient image loading is caching. In this post, we'll go through the basics of caching in Glide.
Glide Series Overview
- Upgrade Guide from Glide 3.x (Coming soon)
A well implemented image loading component attempts to minimize the number of network requests the Android app has to make. Glide is no different here. Glide uses memory and disk caching by default to avoid unnecessary network requests. We'll look at the exact implementation details in a later blog post. If you can't wait until then, feel free to browse the official document on the topic.
For now, the important take away is that all image requests get cached in memory and on disk. While the caching is generally something very useful, in some scenarios it might not be the wished behavior. In the next section, we'll look at how to change Glide's caching behavior for a single request.
Using Cache Strategies
If you played around with Glide in the past, you noticed that you don't need to do anything extra to activate caching. It comes right out of the box. However, if you know that an image changes rapidly, you might want to avoid certain caches.
Glide offers methods to adapt the memory and disk cache behavior. Let's look at the memory cache first.
Let's visualize it with a very simple request: loading an image from the Internet to an
Glide .with( context ) .load( eatFoodyImages ) .skipMemoryCache( true ) .into( imageViewInternet );
You already noticed that we called
.skipMemoryCache( true ) to specifically tell Glide to skip the memory cache. This means that Glide will not put the image in the memory cache. It's important to understand, that this only affects the memory cache! Glide will still utilize the disk cache to avoid another network request.
It's also good to know that Glide will put all image resources into the memory cache by default. Thus, a specific call
.skipMemoryCache( false ) is not necessary.
Hint: beware of the fact, that if you make an initial request to the same URL without the
.skipMemoryCache( true ) and then with the method, the resource will get cached in memory. Make sure you're consistent across all calls to the same resource, when you want to adjust the caching behavior!
Skipping Disk Cache
As you've learned in the section above, even if you deactivate memory caching, the request image will still be stored on the device's disk storage. If you've an image, which sits behind the same URL, but is changing rapidly, you might want to deactivate disk caching as well.
You can change Glide's behavior of disk caching with the
.diskCacheStrategy() method. Unlike the
.skipMemoryCache() method, it takes an enum with different values instead of a simple boolean. If you want deactivate the disk cache for a request, use the enum value
DiskCacheStrategy.NONE as the parameter:
Glide .with( context ) .load( eatFoodyImages ) .diskCacheStrategy( DiskCacheStrategy.NONE ) .into( imageViewInternet );
The image in this code snippet will not be saved in the disk cache at all. However, by default it'll still use the memory cache! In order to deactivate both caches, combine the method calls:
Glide .with( context ) .load( eatFoodyImages ) .diskCacheStrategy( DiskCacheStrategy.NONE ) .skipMemoryCache( true ) .into( imageViewInternet );
Customize Disk Cache Behavior
As we've mentioned previously, Glide has more than one option for the disk cache behavior. Before we show you the options, you've to understand that Glide's disk caching is fairly complex. For example, Picasso only caches the full-blown image. Glide, however, caches the original, full-resolution image and additionally smaller versions of that image. For example, if you request an image with 1000x1000 pixels, and your
ImageView is 500x500 pixels, Glide will put both versions of the image in the cache.
Now you'll understand the difference between the enum parameters for the
DiskCacheStrategy.NONEcaches nothing, as discussed
DiskCacheStrategy.SOURCEcaches only the original full-resolution image. In our example above that would be the 1000x1000 pixel one
DiskCacheStrategy.RESULTcaches only the final image, after reducing the resolution (and possibly transformations) (default behavior)
DiskCacheStrategy.ALLcaches all versions of the image
As a last example, if you've an image which you know you'll manipulate often and make a bunch of different versions of it, it makes sense to only cache the original resolution. Thus, we'd use
DiskCacheStrategy.SOURCE to tell Glide to only keep the original:
Glide .with( context ) .load( eatFoodyImages ) .diskCacheStrategy( DiskCacheStrategy.SOURCE ) .into( imageViewFile );
Invalidate Cache for Single Image
Since Glide caches multiple versions of the same image in various resolutions, it's not as easy to just delete a single file from the cache. You need to find all variants of the image to effectively invalidate the cache for an image. This is a rather complicated process, which the official wiki guide on cache invalidation covers quite well.
In this blog post, you've learned how the basics of Glide's image caching work and how you can adjust the behavior to your needs. In later blog posts, we'll circle back to this topic to do more advanced optimizations. Nevertheless, for a start this blog post gave you very effective methods to get the most out of the caching behavior of Glide.
Next week, we'll take a look at another critical piece of a good user experience: prioritizing image requests!