Ym -- Android (video and image) Loading and caching class library Glide,

Ym -- Android (video and image) Loading and caching class library Glide,

Reprinted please indicate this article from Cym blog (http://blog.csdn.net/cym492224103). Thank you for your support!

Preface

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

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 depends on Support Library v4. Don't forget. In fact, Support Library v4 is already a standard application, which is not a problem.

Basic

As I mentioned, Glide and Picasso are very similar. Glide loads images in the same way 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 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.

When Activity/Fragment is used as the with () parameter, the image loading will be consistent with the Activity/Fragment lifecycle. 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:

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

At the same timeAndroidManifest.xmlLieutenant GeneralGlideModuleDefinedmeta-data

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

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

12345

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:

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

12	//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

12345

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

Center Cropping

12345

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

Transforming

12345

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

Set bitmap or load error map:

1234567

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

Additional content:
Glide's primary goal is to make the list of any type of images quickly and smoothly scroll as much as possible. Another goal is to efficiently obtain, display, and adjust the size of remote images.


Features:
1. gif animation decoding: by calling the Glide. with (context). load ("image path") method, GIF animated images can be automatically displayed as animated images. If you want more control, you can also use Glide. with (context ). load ("image path"). the asBitmap () method loads static images and uses Glide. with (context ). load ("image path"). the asGif () method is used to load animated images;
2. Local video file decoding: by calling the Glide. with (context). load ("image path") method, Glide can load and display all video files on Android devices;
3. Support for thumbnails: to reduce the time required to load multiple images simultaneously in the same view component, you can call Glide. with (context ). load ("image path"). thumbnail ("scaling ratio"). the into ("view component") method loads a thumbnail and controls the parameter size in thumbnail () to control the display of thumbnails of different proportions;
4. Integrated Activity lifecycle: when the Activity is paused and restarted, Glide can intelligently pause and re-start requests, and when the connection status of the Android device changes, all failed requests can be automatically re-requested;
5. transcoding supported: Glide's toBytes () and transcode () methods can be used to obtain, decode, and transform background images. The transcode () method can also change the image style;
6. Support for Animation: added the function of supporting the fade-in and fade-out animation effects (calling the crossFade () method) and viewing animation attributes;
7. Support for OkHttp and Volley: HttpUrlConnection is selected as the network protocol stack by default, and OkHttp and Volley can also be selected as the network protocol stack;
8. Other functions: for example, the Drawables object can be used as a placeholder During image loading, the image request is optimized, the width and height of the image can be reset, And the thumbnails and the cache of the original image can be used.

Related Resources

-Glide 3.0: a media management library for Android

-Glide Wiki

-Android Picasso vs Glide

-Android: Image loading libraries Picasso vs Glide

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