Picasso VS Glide

Original: Introduction to Glide, Image Loader Library for Android, recommended by Google

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

Dependencies {      ' com.squareup.picasso:picasso:2.5.1 '  }  

Glide

Dependencies {      ' com.github.bumptech.glide:glide:3.5.2 '      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

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 the same, glide is easier to use because the glide with method not only accepts the context, but also accepts activity and Fragment,context are automatically fetched 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.

Glide 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, 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 :

Public class Glideconfiguration implements Glidemodule {         @Override      void  applyoptions ( Context context, Glidebuilder Builder) {          //  Apply options to the builder here.           Builder.setdecodeformat (decodeformat.prefer_argb_8888);      }         @Override      void  registercomponents (context context, Glide Glide) {          //  Register modelloaders here.       }  }  

Also defined in the AndroidManifest.xml will GlideModulemeta-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 (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:

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 (PS: This consumes traffic), 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.

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.

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.

Characteristics

You can do almost as many things as Picasso, and the code is almost the same.

Image resizing

// Picasso. Resize (+//  Glide. Override (300, 200);

Center cropping

// Picasso  //  Glide. Centercrop ();

Transforming

// Picasso. Transform (new//  Glide. Transform (new Circletransform (context))

Setting the Placeholder and Error image

// Picasso  //  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.

Resources

There's not much online resources for glide. However, here are some of the links I have found that can be accessed below.

-Glide 3.0:a Media Management library for Android

-Glide Wiki

-Android Picasso vs Glide

-Android:image Loading libraries Picasso vs Glide

Picasso VS Glide