- The original link: Google recommended image loading Library Glide introduction
- Author: nuuneoi
- Translator: Jianghejie
- Reviewer: chaossss
Status: Complete
At the Google Developer Forum in Thailand, Google introduced a picture loading library called Glide, the author of Bumptech. The library is widely used in Google's open source projects, including the official app released at the 2014 Google I/O conference.
There is no doubt that this library has aroused my interest. So I spent an evening researching and playing with it, and after analyzing its implementation principles, I decided to write a blog post to share some of my own experience. Before I start, I want to say that glide and Picasso have a 90% similarity, and, to be exact, I think it's like a clone of Picasso.
Anyway, there's a lot of difference between Glide and Picasso in detail, and then I'll let you know the difference.
Import Library
Picasso and Glide are on the jcenter. Adding dependencies in your project is simple: Picasso
{ compile ‘com.squareup.picasso:picasso:2.5.1‘}
Glide
{ compile ‘com.github.bumptech.glide:glide:3.5.2‘ compile ‘com.android.support:support-v4:22.0.0‘}
Anyway, Glide needs the Android support Library V4 package, don't forget to add the Android support Library V4 package as the above code does. But that's not a big problem, because now Android support Library V4 is basically the standard for every new Android project.
Basis
As I said, Glide and Picasso are very similar, glide the way to load pictures is the same as Picasso.
Picasso
Picasso.with(context) .load("http://inthecheesefactory.com/uploads/source/glidepicasso/cover.jpg") .into(ivImg);
Glide
Glide.with(context) .load("http://inthecheesefactory.com/uploads/source/glidepicasso/cover.jpg") .into(ivImg);
Although the two look very similar, Glide's code is undoubtedly better designed, because the Glide with () method not only accepts the Context, but also accepts Activity and Fragment. In addition, the with () method automatically extracts the Context from the various things you put into it for its own use.
The benefit of activity/fragment as a with () parameter is that the picture load will be consistent with the activity/fragment life cycle, such as the paused state is paused and reloaded automatically at resumed time. So I suggest that you pass the activity and fragment to glide instead of the context when you pass the argument.
The default bitmap format is rgb_565
Here is a comparison of the Picasso when loading the picture (1920x1080 pixel images are loaded into the 768x432 ImageView)
You can see glide loading picture quality is worse than Picasso (PS: I do not see ha), why? This is because the default bitmap format for glide is rgb_565, which is less than half the memory overhead of the argb_8888 format. Below is the memory overhead graph of Picasso under ARGB8888 with Glide under RGB565 (the application itself occupies 8m, so the baseline comparison is 8):
If you feel that the Glide in the default rgb_565 format will be acceptable, you can do nothing. But if you find it hard to accept, or if your actual needs have a higher demand for the quality of the picture, you can create a glidemodule subclass like the following code to convert the Bitmap format to argb_8888:
public class glideconfiguration implements glidemodule { @Override public void applyoptions (context context, Glidebuilder Builder) {
//Apply options to the builder here. Builder.setdecodeformat (decodeformat.prefer_argb_8888); }
@Override
public
void
registercomponents (context context, Glide Glide) {
//register modelloaders here. }}
Then define Glidemodule as Meta-data in Androidmanifest.xml
<meta-data android:name="com.inthecheesefactory.lab.glidepicasso.GlideConfiguration" android:value="GlideModule"/>
This will look a lot better.
Let's look at the memory overhead graph, although it seems that the memory overhead of this Glide is close to twice times that of the last time, but Picasso's memory overhead is still much larger than Glide.
But the problem with doing that is that you need to manually calculate the size of the ImageView, or if you have a specific size for ImageView, and in order to solve this problem, you can simplify your code in Picasso by doing so:
Picasso.with(this) .load("http://nuuneoi.com/uploads/source/playstore/cover.jpg") .resize(768432) .into(ivImgPicasso);
But the problem is that you need to proactively calculate the size of the ImageView, or that your imageview size is a specific value (not wrap_content), and you can:
Picasso.with(this) .load("http://nuuneoi.com/uploads/source/playstore/cover.jpg") .fit() .centerCrop() .into(ivImgPicasso);
Now the memory overhead of Picasso is almost the same as glide.
Although the memory overhead gap is not big, but on this issue glide outright Picasso. Because glide can automatically calculate the ImageView size in any case.
Image quality Details
This is the comparison when restoring ImageView to true size.
It is clear that some of the pixels in the Glide-loaded picture are blurred and do not look as smooth as Picasso. And until now, I have not found a way to visually change the image resizing algorithm.
But it's not a bad thing, because it's hard to detect.
Disk Cache
Picasso and glide differ greatly in the disk cache strategy. We just did an experiment using Glide and Picasso to load the same high-definition picture, and when I checked the cache directory after the experiment, I found that the Glide cached picture is the same size as the ImageView, and the Picasso cached picture is the same size as the original picture.
The problem with the smoothness above is still there, and if the RGB565 picture is loaded, the picture in the cache is also RGB565.
I try to adjust the ImageView to a different size, but no matter how large or small Picasso only one full size is cached. Glide is different, it caches the ImageView for each size. Although a picture has been cached once, if you want to display it again in a different size in another place, you need to re-download it, resize it to the new size, and then cache the size.
Specifically: If there is a 200x200 imageview on the first page, there is a 100x100 ImageView on the second page, the two ImageView would have been to display the same picture, but downloaded two times.
However, you can change this behavior so that glide both caches the full size and caches the other dimensions:
Glide.with(this) .load("http://nuuneoi.com/uploads/source/playstore/cover.jpg") .diskCacheStrategy(DiskCacheStrategy.ALL) .into(ivImgGlide);
The next time you load a picture in any ImageView, the full-size picture will be removed from the cache, resized, and then cached.
The advantage of glide in this way is that loading displays very quickly. The Picasso approach causes some delay because it needs to be resized before the display, even if you add this code to make it appear immediately:
//Picasso.noFade();
Picasso and Glide have their own strengths in disk caching strategies, and you should choose the most appropriate one for your needs.
For me, I prefer glide, because it is much faster than Picasso, although it takes a lot more space to cache.
features
You can do almost as many things as Picasso, and the code is almost the same.
Image resizing
// Picasso.resize(300200);// Glide.override(300200);
Center cropping
// Picasso.centerCrop();// Glide.centerCrop();
Transforming
// Picasso.transform(new CircleTransform())// Glide.transform(new CircleTransform(context))
To set up a bitmap or load Error graph:
// Picasso.placeholder(R.drawable.placeholder).error(R.drawable.imagenotfound)// Glide.placeholder(R.drawable.placeholder).error(R.drawable.imagenotfound)
As I said at the beginning of the blog post, if you are already familiar with how to use Picasso, it is a piece of cake for you to switch from Picasso to glide.
What glide can do and Picasso can't do
Glide can load gif dynamic graphs, while Picasso cannot.
And because the life cycle of glide and activity/fragment is consistent, GIF animations also automatically pause and replay with the activity/fragment state. The Glide cache is also the same here in GIF, resizing and then caching.
But judging from my test results, using Glide to display animations consumes a lot of memory, so use it with caution.
In addition to GIF animations, glide can decode any local video into a static picture.
Another feature is that you can configure the animation for a picture display, whereas Picasso has only one animation: fading in.
The last one is that you can use thumbnail () to produce a thumbnail of the picture you are loading.
In fact, there are some features, but not very important, such as converting an image into a byte array. Configuration
There are many options that can be configured, such as size, cache disk location, maximum cache space, bitmap format, and so on. You can view these configuration configurations on this page.
Size of Library
The size of Picasso (v2.5.1) is about 118kb, while the size of glide (v3.5.2) is about 430kb.
But the 312kb gap is not very important.
The number of methods for Picasso and glide are 840 and 2,678 respectively.
It must be noted that 2678 is a fairly large number for the 65,535 methods of the Dex file. It is recommended to turn on Proguard when using glide.
Summarize
Glide and Picasso are perfect libraries. Glide load images and disk cache in a way that is better than Picasso, faster, and glide more conducive to reducing the occurrence of outofmemoryerror, GIF animation is Glide's killer. But Picasso's picture is more high-quality. Which one do you like better?
Although I have been using Picasso for a long time, I have to admit that I prefer glide now. My advice is to use glide, but change the bitmap format to argb_8888, and let the glide cache cache both full size and size two.
Related Resources
- Glide 3.0:A Media Management library for Android
- Glide Wiki
- Android Picasso vs Glide
- Android:image loading Libraries Picasso vs Glide
Google recommended image loading Library Glide introduction