The use of Android's glide library loading picture and its comparison with Picasso _android

Glide

Glide is a media management framework for efficient, open source, Android devices that follows the BSD, MIT, and Apache 2.0 protocol releases. Glide has the ability to capture, decode, and display video stills, pictures, animations, and so on, and it has a flexible API that allows developers to apply glide to almost any network protocol stack. The main purpose of creating glide is two, one is to achieve smooth Picture list scrolling effect, the other is to support remote image acquisition, sizing and display.
Glide 3.0 has added a number of important features, and it also supports building with Gradle and maven. This release includes a number of new features that are noteworthy, such as support for GIF animations and video stills decoding, smart pause and restart requests, support thumbnails, and more, as follows:

GIF animation decoding: by invoking the Glide.with (context). Load ("Picture path") method, an animated GIF picture can be automatically displayed as an animation effect. If you want more control, you can also use the Glide.with (context). Load ("Picture path"). Asbitmap () method loads a static picture, using the Glide.with (context). Load (picture path). Asgif () method to load an animated picture
Decoding of local video stills: by invoking Glide.with (context). Load ("Picture path") method, Glide is able to support the loading and display of all video stills in Android devices
Thumbnail support: To reduce the time to load multiple pictures simultaneously in the same view component, you can invoke Glide.with (context). Load ("Picture path"). Thumbnail ("thumbnail"). into ("View component") method to load a thumbnail and to control the size of the parameters in thumbnail () to control thumbnails showing different proportions
Integration of activity Lifecycle: When activity is paused and restarted, glide can make smart pauses and restart requests, and all failed requests can be automatically restarted when the connection status of the Android device changes
Transcoding support: Glide's tobytes () and Transcode () Two methods can be used to obtain, decode, and transform background images, and the Transcode () method can also change the style of the picture
Animated support: New support for graphics fade animation effects (calling the Crossfade () method) and viewing the properties of an animation
Okhttp and Volley support: Default selection httpurlconnection as network protocol stack, also can choose Okhttp and volley as network protocol stack
Other features: such as the use of Drawables objects as placeholders, optimization of picture requests, width and height of images, and caching of thumbnails and original images during image loading

Import Library

Picasso and Glide are on the jcenter. Adding dependencies in your 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 '
}

Either way, Glide needs the Android Support Library V4 package, and don't forget to add the Android Support Library V4 package As the code above does. But that's not a big problem, because Android Support Library V4 is basically the standard for every new Android project.

Basis

As I said, Glide and Picasso are very similar, glide loading pictures is 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 very similar, Glide's code is certainly better designed because the Glide with () method not only accepts the context, but also accepts activity and Fragment. In addition, the with () method can automatically extract the context from the various things you put into it for its own use.

The advantage of Activity/fragment as the WITH () parameter is that the picture load is consistent with the life cycle of the activity/fragment, such as the paused state is suspended and automatically reloaded at resumed time. So I suggest that you pass the activity and fragment to glide, not the context, when you pass the ginseng.

The default bitmap format is rgb_565

The following is a comparison of loading pictures with Picasso (1920x1080 pixel images loaded into 768x432 ImageView)

You can see the glide load of the picture quality is worse than Picasso (PS: I do not see ha), why? This is because the glide default bitmap format is rgb_565, which is less than half the memory overhead in the argb_8888 format. The following is the memory overhead map of Picasso under ARGB8888 and Glide under RGB565 (the application itself occupies 8m and therefore is compared with 8):

If you feel that Glide in the default rgb_565 format, the quality of the pictures can be acceptable, you can do nothing. But if you find it hard to accept, or if your actual needs have higher requirements for the quality of the picture, you can create a glidemodule subclass like the following code to convert the Bitmap format to argb_8888:

 The public class Glideconfiguration implements Glidemodule {

  @Override
  the public void applyoptions 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 "/>

That would look a lot better.

Let's take a look at the memory overhead graph, although it looks like the Glide memory cost is close to twice times the last time, but Picasso's memory overhead is still much larger than the Glide.

But the problem with the above is that you need to manually calculate the size of the ImageView, or you set the size of the ImageView, in order to solve this problem, you can simplify your code by doing this in Picasso:

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 actively calculate the size of the ImageView, or your imageview size is a specific value (rather than wrap_content), you can also:

Picasso.with (this).
  load ("http://nuuneoi.com/uploads/source/playstore/cover.jpg")-Fit
  ()
  . Centercrop ()
  . into (Ivimgpicasso);

Now Picasso's memory overhead is about the same as glide.

While the memory overhead gap is small, the glide is a Picasso on this issue. Because glide can automatically calculate the size of ImageView in any case.

Details of image quality

This is the comparison of restoring the ImageView to its true size.

Obviously, some pixels in the Glide load are blurry and do not appear to be Picasso as smooth. And until now, I haven't found a way to visually change the image sizing algorithm.

But that's not a bad thing, because it's hard to detect.

Disk caching

Picasso and glide are very different on the disk caching strategy. We've just done an experiment using Glide and Picasso to load the same HD picture, and I checked the cache directory after the experiment and found that the Glide cached picture is the same size as the ImageView, while the Picasso cached picture is the same size as the original picture.

The smoothness problem mentioned above still exists, and if the RGB565 picture is loaded, the picture in the cache is RGB565.

I try to resize the ImageView to a different size, but regardless of size Picasso only cache one full-size. Glide is different, it is cached for each size imageview. Although a picture has been cached once, if you want to be in another place again in different sizes, you need to download, adjust to the size of the new size, and then the size of the cache.

Specifically: If the first page has a 200x200 ImageView, in the second page has a 100x100 ImageView, the two ImageView would have to show the same picture, but need to download two times.

However, you can change this behavior so that glide caches both full-sized and 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 cached.

The advantage of glide is that the load display is very fast. The Picasso approach is caused by the need to resize before displaying, even if you add the code to show it immediately:

Picasso
. Nofade ();

Picasso and Glide have their own strengths in the disk caching strategy, and you should choose the right one according to your needs.

For me, I prefer glide, because it is much faster than Picasso, although it requires a lot of space to cache.

Characteristics

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

Image resizing

Picasso
Resize (in);

Glide
. Override (300, 200);

Center cropping

Picasso
. Centercrop ();

Glide
. Centercrop ();

Transforming

Picasso
. Transform (New Circletransform ())

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

To set up a bitmap or load an error diagram:

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 my blog post, if you are already familiar with how to use Picasso, switching from Picasso to glide is a piece of cake for you.

What glide can do, and Picasso can't.

Glide can load gif dynamic graphs, while Picasso cannot.

Also because the life cycle of glide and activity/fragment is consistent, GIF animations are automatically paused and replayed with the activity/fragment state. The Glide cache is the same here in GIF, resized and then cached.

But judging from one of my test results, using Glide to display animations consumes a lot of memory, so use them 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 to display the picture, and 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 the image into a byte array. Configuration

There are many options that can be configured, such as size, cached disk location, maximum cache space, bitmap format, and so on. You can view these configuration Configuration on this page.

Size of Library

The size of the 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 Picasso and glide methods is 840 and 2,678, respectively.

It must be noted that 2678 is a fairly large number for the limitations of the 65,535 methods of the Dex file. It is recommended that you open Proguard when using glide.

Summarize

Glide and Picasso are perfect libraries. Glide load images and disk caching is better than Picasso, faster, and glide more conducive to reducing the occurrence of outofmemoryerror, GIF animation is the killer of glide. But Picasso's picture is more quality. Which one do you like better?

Although I used Picasso for a long time, I have to admit that I like glide better now. My advice is to use glide, but replace the bitmap format with argb_8888, and have glide cache cache full size and resize two different sizes.