It’s been a while, but then I have a list of different things to share from what all I have learnt from my lessons. I believe there are many sources out there, but this is just a brief of may be everything available (or just another quick reference).
So one of the quick question that I have come across, of course there are other questions too that are common and available on every site, but I thought of jotting them down for my own reference and for those new to it too. (Other questions i have come across will be available soon in the coming blog posts 🙂 )
- If you are using a couple of image loading functionalities, then which one would you go for?
Well this is a little tricky. Why should we really bother when we just need to display images in a lazy loading fashion, whichever library we take, we shouldn’t really care!
Well, hold on. Just like the way it is in life, we have many things to do, but we only take up things that are worth it and suitable, it is so with programming too. Especially, when dealing with mobile devices, we need to be careful what we pick as it might affect the loading time and also many other resources that can be expensive. I will not be able to impose on you which library you should select but then I will just highlight the pros and cons may be of the libraries, and you could take a call as to which library to pick.
Let’s look at the different image loading libraries that we have (I will only be talking about what I have worked with and probably those that I know about):
- Every image is just cached once (the original size), so if you wish to load the same image for different image views , it will only download it once, and use that image after resizing it
- When an image is zoomed, the quality of Picasso is better if compared against glide (very less hard pixels, though this should not make much of a difference to the normal eye)
- It is quite easy to call (just one line unlike in the case of UIL)
- You do not have to create an instance of the ImageLoader
- The image downloaded is of the original size, and this means that resizing would take place later on. This is CPU intensive when it comes to GPU rendering of the image
- Memory consumption in the case of Picasso is quite high as compared to Glide, hence this is one key point we need to consider (as memory is expensive in Android)
- Offers just the fade in animation for an image
- It will cause an out of memory if large images are downloaded from the web
- Glide (recommended by Google in Google I/O 2014)
- When an image is downloaded, the resized image gets downloaded, thus we don’t have to worry about resizing the image.
- It allows the user to pass in an Activity, a Fragment hence the context it uses can be bound to the lifecycle of the instance that is passed while unlike in Picasso we just have an option of passing the context
- Although same images of different sizes would be downloaded, we can let Glide cache all these images so that network calls are not made all the time
- Memory consumption is way less than Picasso (almost 50%) since it resizes the image first before downloading it
- It is much faster as compared to any image loader mentioned in the list, since it downloads an already resized image and then loads it into the ImageView, while in the case of the other loaders, the image has to be resized first before it is loaded into the ImageView (so it is relatively faster when it comes to display)
- One more added advantage is, you can use it to load GIF images (which is memory consuming though)
- Can be used to load still images
- Offers multiple animations (including custom ones) for loading images
- Several images of the same would be downloaded for different sizes (uses a lot of disk space for caching)
- The image quality is not that smooth
- The default bitmap format is RGB_565 which can be changed to ARGB_8888 using GlideModule*
- It is easily customizable
- It is a very popular library available for quite a while now
- It is always possible for you to define everything yourself like the configuration, disk cache everything
- It allows you to maintain a single instance but that would mean that the configuration defined would be applicable for the whole app while in the case of Volley and Picasso you are allowed to define multiple configurations
- Locks up the UI Thread in some cases as compared to Volley or even Picasso (if the lag is in the scroll you could may be try this thread.
- Disk cache mechanism is slow as compared to the other libraries
- Fresco (facebook)
- It uses ashmem heap instead of java heap to store the images such that more memory is available for the application to use
- It allows resizing of jpeg images which means we don’t have to worry about resizing and OOM exceptions
- Has better cropping capabilities than any other library
- Progressive JPEG images can be streamed
- Can be used to load GIFs and WebPs
- It is a very huge library (this means that you would cross the 65k limit)
- It will display large images with high resolutions without OOM issues
- You can use your own network requests to load an image
- Requests made can be prioritized and also cancelled whenever needed
- The images when displayed as centerCrop scale type are blurred
- This is a network library that handles the network calls to a larger extent, it is not just another image loading library
- You have to create a custom class in order to handle caching of images
- AQuery (Android Query)
- Loads the images asynchronously
- You can specify the aspect ratio for the image to be loaded or the size of the image
- Possible to perform transformations easily without creating custom ones
- It’s a version for Android just like JQuery
- It hangs up the UI thread which is not what we really look forward too if working with very large number of list items and/or images
- And I believe there are many more…..
I suggest you try out the famous libraries available and then you could decide for yourself as to what library you wish to use. Any suggestions or corrections are welcome 🙂
- [*]The cheese factory