ImageLoaders: Continued

In the previous article, I compared the UniversalImageLoader (UIL) and Picasso libraries for optimal memory usage. Among the comments were some subtleties of the use of libraries and requests to test other bootloaders. These questions gave rise to the second part of the benchmark with the participation of 5 libraries.
Results:
So, libraries will take part in benchmark:
UIL , Picasso , Glide , Query , Volley

Sources can be found here.

In the first part of the article I will conduct experiments with measuring the memory used with the participation of five libraries.
In the second part I will compare the libraries in terms of their settings and visual characteristics.
')

Used memory

If someone is interested to get acquainted with the details of the experiment - they can be found in the previous article .
I will say briefly: I will test libraries for loading images and measure the memory used by them on equal terms. Graphs on the device were drawn using the GraphView library.

Download small images 240x240

In this experiment, it is possible to note a decrease in the memory consumption of UIL due to the hack from the author of the library:

imageView.post(new Runnable() { @Override public void run() { imageLoader.displayImage(...); } }); 

Download large images without format conversion

Query library behaves in a very interesting way. I did not climb into the source, but I have an assumption that the cache is based on the list, and not the set. Otherwise, I do not know how to explain the duplication of images on the backward scrolling grid.
Just unpleasantly surprised Volley . Very often the image in ImageView is not loaded. Debug pointed out that sometimes attempts are made to set recycled Bitmap. There is probably some problem with the choice of pictures to be cleaned.

Downloading large images with converting to RGB565 format and fitting the image to the size of the ImageView

As a rule, large images do not require a 24-bit format, in most cases RGB565 is sufficient.
Most easily convert format allows UIL . It is enough to specify the necessary Bitmap.Config in the image loading options. For the rest of the libraries, the conversion had to be written.

In this experiment, Glide stood out, taking more memory than Volley , Query and Picasso together. At once I want to clarify: it was possible to limit the size of the cache, but in the experiment I wanted to see how the libraries work with memory in the basic configuration. Each global cache limit cleaning is a noticeable plug in the work of the UI thread. Therefore, from the library I would like some kind of gradual cleaning, so to speak.

Loading small images (240x240) with subsequent rounding

Unfortunately, such successful results of Volley cannot be taken into account, since I did not see the pictures on the back pass. They all turned out to be recycled, even considering that I didn’t cause the original to recycle () during the transformation. No good.

Glide , apparently, performs the conversion of all the pictures in RGB565, since the pictures have a black background instead of a transparent one. No good.

The easiest way to do the transformation is with UIL and Query . UIL has a built-in class RoundBitmapDisplayer, which can be connected to download options.
For Query, it is enough to specify in the options the radius of the image rounding.
For Picasso and Glide, the inclusion of the transformation to the load looks like one of the steps in Builder-a.

 Glide.load(url).centerCrop().transform(roundTransformation).into(imageView); Picasso.with(context).load(url).transform(picassoRoundTransformation).noFade().into(imageView); 

For Volley, I had to redefine ImageView and do Bitmap-a conversion in the setImageBitmap () method.
If anyone has a better solution, offer your options.

Visual characteristics.

Picasso is inferior to other libraries in image loading speed. I don’t know how to explain it, but it’s a fact: Picasso images appear a little later.

Glide , as mentioned above, converts images into RGB565, which can cause trouble when transforming images.

UIL loads images visually faster. But you need to take into account one feature: when using FadeInBitmapDisplayer for a smooth display of pictures, it is better to use an advanced constructor.

 new FadeInBitmapDisplayer(duration, true, true, false) 

In this configuration, the picture will only be animated for the first time (while the map is still in the cache), and when browsing it will not strain the eye with excessive animation. This is IMHO.
In Picasso, the fade in effect works by definition in this mode.

Volley, in turn, often does not display converted images because they are already recycled (). I am waiting in the comments for your suggestions for correcting this bug.

Query visually surprised nothing. Loading pictures looks intermittent. The order in which the pictures were requested is rarely observed.

Bootloader configuration

UIL is the undisputed leader in the ability to tune boot parameters. Thanks to the Builder-pattern of settings, you can easily get acquainted with the library's capabilities. In principle, you can do without a manual. UIL also allows you to connect OnScollListener to pause requests for a time scrolling list.

Glide and Picasso are the easiest libraries to integrate. Picasso has the advantage of having a maven repository. If you need to quickly integrate the loading of images, while getting the optimal settings and economical consumption of memory - the choice for Picasso .

Picasso and UIL provide interfaces that allow you to upload a picture anywhere.

Volley requires a long preparation for use. You need to create and configure the cache instance and boot queue yourself. In the markup, you must use the NetworkImageView widget or its heirs. For me, this is a significant inconvenience. The only acceptable way to use this library for downloading images is if the Network of your project is built on Volley.

Query , in principle, is not hard to configure. But the use case offered by the authors in adapters confuses me a little. To download each image, you need to create an instance of the AQuery class, which in itself is rather heavy. This is not the best library if you want to save CPU time on garbage collection.

Often there is a need to use your HTTPClient to upload images. Volley and UIL provide tools to configure the connection. On the Internet, I also met the integration of the custom HttpClient in Picasso . But as far as I understand, standard means will not do this.

findings

The more libraries - the harder it became to draw any conclusions. I will try in one sentence to characterize each library.

Picasso - if you need to quickly integrate and not worry about the memory used
UIL - if your project requires a specific load setting, but at the same time allows you to perform this setting quickly and clearly
Glide is a clone of Picasso (maybe the other way around), but consumes a bit more memory.
Volley - use is justified if your Network is built on Volley , and the connection requires specific HttpClient configuration for the entire project
Query is a difficult to understand and integrate library with poor documentation, yet it does show excellent results in saving device memory.

Waiting for your comments and tips!