Introduction to the image loading library Glide recommended by Google, and google loading library glide

Introduction to the image loading library Glide recommended by Google, and google loading library glide

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

Initial http://jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0327/2650.html

At the Google Developer Forum held in Thailand, Google introduced us to a library named Glide, written by bumptech. This 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 its success. I spent a whole night playing and decided to share some of my experiences. Before I start, I would like to say that Glide and Picasso have 90% similarity. To be precise, it is the clone version of Picasso. However, there are many differences in details.

Import to Warehouse

Both Picasso and Glide are on jcenter. Adding dependencies to a project is simple:

Picasso

dependencies {    compile 'com.squareup.picasso:picasso:2.5.1'}

Glide

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

Glide dependencySupport Library v4Don't forget. ActuallySupport Library v4It is already a standard for applications. This is not a problem.

Basic

As I mentioned, Glide and Picasso are very similar. Glide loads images in the same way 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 more easy to use, because the Glide with method not only accepts Context, but also accepts Activity and Fragment, the Context will automatically get from them.

The advantage of using Activity/Fragment as the with () parameter is that image loading will be consistent with the lifecycle of Activity/Fragment. For example, Paused is Paused, it is automatically reloaded when Resumed is used. Therefore, we recommend that you pass Activity and Fragment to Glide instead of Context when passing parameters.

The default Bitmap format is RGB_565.

The following is a comparison between image loading and Picasso (1920x1080 pixels of images are loaded into the ImageView of 768x432)

We can see that the image quality loaded by Glide is worse than Picasso (ps: I can't see it). Why? This is because the default Bitmap format of Glide isRGB_565, RatioARGB_8888The memory overhead of the format is reduced by half. The following figure shows the memory overhead of Picasso in ARGB8888 and Glide in RGB565 (the application occupies 8 m and therefore uses 8 as the baseline ):

If you use the defaultRGB_565The results are satisfactory, but you can create a newGlideModuleConvert the Bitmap formatARGB_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.    }}

At the same timeAndroidManifest.xmlLieutenant GeneralGlideModuleDefinedmeta-data

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

This looks much better.

Let's take a look at the memory overhead diagram. This time it seems that Glide has spent two times the previous memory, but the memory overhead of Picasso is still much larger than Glide.

The reason is that Picasso loads a full-size image to the memory, and then allows the GPU to re-paint the size in real time. The size of Glide is the same as that of ImageView, so it is smaller. Of course, Picasso can also specify the size of the loaded image:

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 calculate the size of the ImageView, or your ImageView size is a specific value (instead of wrap_content). You can also do this:

Picasso.with(this)    .load("http://nuuneoi.com/uploads/source/playstore/cover.jpg")    .fit()    .centerCrop()    .into(ivImgPicasso);

Now the memory overhead of Picasso is similar to that of Glide.

Although the memory overhead is insufficient, Glide wins Picasso in this case. Because Glide can automatically calculate the ImageView size.

Image Quality details

This is a comparison of how to restore the ImageView to a real hour.

You can see that the images loaded by Glide are not as smooth as Picasso, and I have not found a method that can intuitively change the image size adjustment algorithm.

But this is not a bad thing, because it is hard to detect.

Disk cache

The disk cache policies of Picasso and Glide vary greatly. Picasso is cached in full size, while Glide is cached in the same size as ImageView.

The above mentioned smoothness problem still exists. If the image is loaded with RGB565, the cached image is also RGB565.

 

I tried to adjust the ImageView to different sizes, But no matter the size of Picasso, only one full size is cached. Glide is different. It caches the Image view of each size once. Although an image has been cached once, if you want to display it again in different sizes in another place, you need to download it again and adjust it to a new size, and then cache the size.

Specifically, assume that there is a x ImageView on the first page, and there is a x ImageView on the second page. The two imageviews are supposed to display the same image, but you need to download it twice.

However, you can change this behavior so that Glide caches both the full size and other sizes:

Glide.with(this)     .load("http://nuuneoi.com/uploads/source/playstore/cover.jpg")     .diskCacheStrategy(DiskCacheStrategy.ALL)     .into(ivImgGlide);

The next time you load an image in any ImageView, the full-size image will be taken out of the cache, adjusted again, and then cached.

Glide has the advantage of fast loading and display. The Picasso method causes some latency due to the need to re-adjust the size before the display, even if you add this code to make it display immediately:

//Picasso.noFade();

Picasso and Glide have their own strengths. You can choose the right one based on your needs.

For me, I prefer Glide because it is much faster than Picasso, although it requires more space for caching.

Features

You can do almost the same thing and code as Picasso.

Image Resizing

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

Center Cropping

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

Transforming

// Picasso.transform(new CircleTransform()) // Glide.transform(new CircleTransform(context))

Set bitmap or load error map:

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

Similar to Picasso, converting from Picasso to Glide is just a piece of cake for you.

 

What Glide can do but Picasso cannot do

Glide can load GIF dynamic images, while Picasso cannot.

Meanwhile, because the lifecycles of Glide and Activity/Fragment are the same, gif animations are automatically paused and replayed along with the Activity/Fragment status. Glide is also cached in gif. Adjust the size and then cache the image.

However, according to one of my test results, Glide animation consumes too much memory, so use it with caution.

In addition to gif animation, Glide can also decode any local video into a static image.

Another feature is that you can configure an animation for image display, while Picasso has only one animation: fading in.

The last one is availableThumbnail () generates the thumbnail of the image you load.

There are still some features, but they are not very important, such as converting an image into a byte array.

Configuration

There are many configurable options, such as size, cached disk location, maximum cache space, and bitmap format. You can view these configurations on this page.Configuration.

Library size

Picasso (v2.5.1) is about KB, while Glide (v3.5.2) is about KB.

Anyway 312KB difference might not be that significant.

However, the 312kb gap is not very important.

The number of Picasso and Glide methods is 840 and 2678, respectively.

It must be noted that, for the limit of 65535 methods of DEX files, 2678 is a considerable number. We recommend that you enable ProGuard when using Glide.

Summary

Glide and Picasso are both perfect libraries. Glide is faster than Picasso in image loading and disk caching, and Glide is more conducive to reducing the occurrence of OutOfMemoryError. gif animation is the killer of Glide. However, the quality of Picasso images is higher. Which one do you prefer?

Although I have used Picasso for a long time, I have to admit that I prefer Glide now. I suggest using Glide, but changing the Bitmap format to ARGB_8888, allowing Glide to cache the full size and change the size at the same time.

 

Related Resources

-Glide 3.0: a media management library for Android

-Glide Wiki

-Android Picasso vs Glide

-Android: Image loading libraries Picasso vs Glide