Google recommended image loading Library Glide introduction

Editor's recommendation: Rare earth nuggets, which is an application for technology developers, you can get the latest and best technical dry goods in the Nuggets, not only Android knowledge, front end, back end so that product and design are covered, want to be a friend of the whole stack of engineers do not miss!

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.

I am very interested in the success of it. I spent all night playing and decided to share some of my own experience. Before I start, I want to say that glide and Picasso have a 90% similarity, which is exactly the clone version of Picasso. But there is a lot of difference in the details.

Import Library

Picasso and Glide are on the jcenter. Adding dependencies in your project is straightforward:

Picasso

123	dependencies {    compile ‘com.squareup.picasso:picasso:2.5.1‘}

Glide

1234	dependencies {    compile ‘com.github.bumptech.glide:glide:3.5.2‘    compile ‘com.android.support:support-v4:22.0.0‘}

Glide need to rely on support Library V4, don't forget. In fact, support Library v4 is already the application standard, this is not a problem.

Basis

As I said, Glide and Picasso are very similar, glide the way to load pictures is the same as Picasso.

Picasso

123	Picasso.with(context)    .load("http://inthecheesefactory.com/uploads/source/glidepicasso/cover.jpg")    .into(ivImg);

Glide

123	Glide.with(context)    .load("http://inthecheesefactory.com/uploads/source/glidepicasso/cover.jpg")    .into(ivImg);

Although the two look the same, glide is easier to use because the glide with method not only accepts the context, but also accepts activity and Fragment,context automatically obtained from them.

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 ARGB_8888 less than half the memory overhead of the 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 are satisfied with the default effect, you can do nothing RGB_565 , but if you find it hard to accept, you can create a new one that GlideModule converts the bitmap format to ARGB_8888 :

12345678910111213

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.    }}

同时在AndroidManifest.xml中将GlideModule定义为meta-data

12	<meta-data android:name="com.inthecheesefactory.lab.glidepicasso.GlideConfiguration"            android:value="GlideModule"/>

This will look a lot better.

Let's take a look at the memory overhead graph, which looks like glide twice as much as the last memory, but Picasso's memory overhead is still greater than glide.

The reason for this is that Picasso loads the full-size picture into memory and then lets the GPU redraw the size in real time. The size of the glide load and the size of the ImageView are consistent and therefore smaller. Of course, Picasso can also specify the size of the loaded picture:

1234	Picasso.with(this)    .load("http://nuuneoi.com/uploads/source/playstore/cover.jpg")    .resize(768, 432)    .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:

12345

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 the same, 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.

As you can see, the glide loaded picture is not Picasso so smooth, I haven't 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. The Picasso cache is full-sized, while the glide cache is the same size as ImageView.

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:

1234	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:

12	//Picasso.noFade();

Picasso and Glide have their own strengths, and you choose the right one according to 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

12345

// Picasso.resize(300, 200); // Glide.override(300, 200);

Center cropping

12345

// Picasso.centerCrop(); // Glide.centerCrop();

Transforming

12345

// Picasso.transform(newCircleTransform())  // Glide.transform(newCircleTransform(context))

To set up a bitmap or load Error graph:

1234567

// Picasso.placeholder(R.drawable.placeholder).error(R.drawable.imagenotfound) // Glide.placeholder(R.drawable.placeholder).error(R.drawable.imagenotfound)

Almost like Picasso, switching from Picasso to glide is a piece of cake for you.

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, glide animations consume too much memory, so use it sparingly.

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 can be usedthumbnail()产生一个你所加载图片的thumbnail。

其实还有一些特性，不过不是非常重要，比如将图像转换成字节数组等。

配置

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 configurations on this page Configuration  .

Size of Library

The size of Picasso (v2.5.1) is about 118kb, while the size of glide (v3.5.2) is about 430kb.

Anyway 312KB difference might not being that significant.

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

English original Introduction to Glide, Image Loader Library for Android, recommended by Google

Reproduced in the source.

Google recommended image loading Library Glide introduction