Glide vs. Picasso

Glide and Picasso are the most used image loading library in the world of android applications. Most of the android application developers have used any of these or both libraries in their career. Both libraries provide number of features, very fast and optimized. They are also well tested on many applications. On the surface, it looks like both are working on the same mechanism. But they both are very different in the way how they download images, caches images and loads them into memory. Today, we are going to look into the core differences between both the libraries and try to figure out which one is the best for application development.

We are comparing Glide v3.7.0 and Picasso v2.5.2 versions for this article. The latest available version might be different depending on when you are reading this article.

Import to the project:

Picasso and Glide, both are on jcenter. You can simply import those into your project with below dependency.



support-v4 dependency is not needed for most of the projects as most of them uses support library by default.

Size and Method Count:

While comparing the sizes of the .jar file of both the libraries, Glide is almost 3.5 times larger than Picasso in size.


Picasso has method count of 849, while Glide has total 2678 method count. 2678 is quite a lot for 65535 methods limit of Android DEX file. You should enable ProGuard if you choose to use Glide.



Both libraries have almost same syntax if you want to simply load the image from the URL and display them into the image view. Both support the fade animations and center crop. You can also add placeholder image to display while loading the image or while the image loading fails.



One thing in which Glide dominates is, it is designed to work with Activity and Fragment’s life cycle too. You can pass the activity or fragment context with Glide.with() and it will brilliantly integrate with activity lifecycle callbacks such as onPause() or onResume().


Disk caching:

Both the library supports caching the image in the disk. They download the images from the URL and store those images on the disk by caching. But there are some differences how they store the images in the cache.

Picasso downloads the image and stores the full-size image (in my case the image resolution was 1160*750) in the cache and whenever we ask for the same image, it will return the full-size image and resize them to fit into the ImageView in real time.

On the other hand, Glide works differently. Glide downloads the image from the given URL, resize it to the size of the image view and stores it to the disk cache. So if you are loading the same image in two different sized image views, Glide will store two different copies of the same image in the cache with different resolutions. That will increase the disk cache size, but it has some of its own benefits. We will see that in the next section.

When I tried to adjust ImageView to the different sizes, Picasso cached only single size of the image and that is full-size. While Glide caches separate files for each size of ImageView. On down point of this approach is, although an image has already been loaded once, if you need to load the image in another size ImageView, it needs to be downloaded once again before be resized to the right resolution and then be cached.


By default, Glide uses RGB_555 configuration while Picasso loads images in ARGB_8888 configuration to load the bitmap into memory. So for fair comparison, I made some changes in GlideModule to load images in ARGB_8888 format by creating a new class which extended from GlideModule like this:

Below is the graph of memory consumption of loading the image in Glide and Picasso:


By looking into the graph, we can see that Glide is more memory efficient (about 8 MB) than Picasso (about 13 MB). This is pretty much understandable as we discussed in the earlier section, that Picasso loads the full-size image into the memory and relies on GPU to resize that image to fit into the size of the ImageView. While Glide loads an image that is already resized as per the ImageView, that requires significantly less memory than loading the full image like Picasso. This helps to prevent your app from throwing popular OutOfMemoryError.

Time taken to load the Image:

When we try to load an image from the URL, both libraries checks their local caches and if the image is not present in the cache, they will download the image from the URL.

When I tried to download images from the URL, Picasso was quite fast in loading the image from the internet than Glide. Maybe because after downloading the image, Picasso directly pushes the full-size image to the memory; while Glide resizes the image as per the dimension of the ImageView. That needs some time to resize the image. (You can reduce this time by using thumbnail() which we will discuss in later section.)


But while loading the image from the cache, Glide wins the battle. This is because of an advantage of the way Glide was designed. While the Picasso causes some delay on loading since it needs to be resized the image first in real-time before images are set to an ImageView. Even if you use .noFade()to appear it instantly.


Other features that Glide support but not Picasso:

  • Animated GIF support: Glide supports animated GIF images out of the box. Loading GIF is simple. Just use the same Glide.with(...).load(...)call and if the image you load is an animated GIF. Also, because of Glide integrates with your activity life-cycle, animated GIFs are also paused in onStop() to avoid draining the battery in the background. While as of now, Picasso does not support animated GIF images. So, if you want to display some animated GIF, then Glide is the only option here.
  • Thumbnail support: With Glide, you can load multiple images into the same view at the same time. To first load a thumbnail at 1/10th the size of your view and then load the full image on top, you can use below code:

 This will reduce the time your user has to see image loading spinners without sacrificing quality.

  • Configurations & Customization: One good thing about Glide is, it provides various conflagrations and customization options. So, you can tweak Glide library as per your requirement. You can read more about this at configuration page.


Neither Glide nor Picasso is perfect. You can use any of this library based on your application requirement. If you want the smaller app and you require very fewer features in the image loading, than Picasso is best. But If you want more customization, animated GIF support, and very better memory management, you should use Glide as your image loader library.

In my opinion, Glide is the winner over here as it handles memory very well and prevents my app from OutOfMemoryError. Also, loads image much faster than Picasso. And yes, the support for animated GIFs is almost killer.



Keep your device screen on smartly!!!

Ideally, when you user is looking at the screen, your application should prevent the device screen from turning off.

This is the huge deal for the blogging, messaging applications. These applications display textual content to their user. Reading those textual content takes more time to the user. While reading that content (let say an article) if the user does not interact with the display and the screen turns off because of the screen timeout that is frustrating to the user. It will destroy the concentration of the user and breaks the link.

If you are using Samsung devices you might know there is one feature called “Smart Stay”. When this feature is enabled, the device will prevent your screen from turning off regardless of your screen timeout settings. But, this technology is only available on some Samsung devices. What if we want to use that technology in our application to solve above problem? Today, I am going to present the solution of this problem.

Here is the solution:

Prevent-Screen-Off” library handles screen on/off timing smartly. It prevents device display from turning off when the user is looking at the screen and he/she might be reading some textual content provided by your application. As soon as the user stop looking at the screen it will allow phone screen to turn off.

How this works?

  • This library uses the front camera to sense when you are looking at your device
  • This uses Google Play Services Mobile Vision API to track users eye using the device front camera. This uses the same algorithm to detect user’s eyes used in “UserAwareVideoView”. (I wrote a whole article regarding how UserAwareVideoView works. You can find it from here.)
  • It keeps the screen from turning off regardless of the screen timeout setting if the user is looking at the screen by detecting user’s eyes.

Integrating the library in your application:

Let’s dive into some technical stuff and see how you can integrate this library in your application and use it.

Add Gradle dependency:

  • To start with the integration, first provide the Gradle dependency of the library by entering below lines in your module level build.gradle.

This library adds android.permission.CAMERA and android.permission.WAKE_LOCK permission in your applications AndroidManifest.xml file.

Initialize in your activity:

  • First, you need to inherit AnalyserActivity in the activity which you want to control screen on/off automatically. The library will synchronize with your activity life-cycle and start and stop eye tracking based on your activity state.
  • Library will start tracking user eyes as soon as activity comes into the foreground. If the user is looking at the screen this will prevent the screen from turning off.
  • When library detects that the user is not looking at the screen, this will turn off the screen after some time.
  • It will stop eye tracking when your activity goes into the background to preserve the battery.
  • Implement ScreenListener to receive the callbacks from the library.
  • Handle the callbacks and errors received from ScreenListener.
  • That’s it. You successfully integrated the library. By the way, if you want to try our sample application before integration, you can find it from this link.

This library won’t work if,

  • When camera fails to initialize or your front camera is being used by another application. In that case, you will receive Errors.UNDEFINED error code in onErrorOccured event.
  • When the light source is behind the user or there is low light in the surrounding environment, so that eye tracking is not possible. In that case, you will receive Errors.LOW_LIGHT error code in onErrorOccured event. At this point, you can show a message to your user to go to the place where enough light available.
  • Google Play Service not available. In that case, you will receive Errors.PLAY_SERVICE_NOT_AVAILABLE error code in onErrorOccured event. In this case, the library will automatically display the dialog to install or update Google Play Services application from the play store, if the device supports Google Play Service.
  • If the device does not have the front camera. In that case, you will receive Errors.FRONT_CAMERA_NOT_AVAILABLE error code in onErrorOccured event. In this case, we are helpless. 😦

Where can you use this feature?

  • Tracking user’s eye using device camera consumes more battery. So, it is advisable that you don’t integrate automatic screen control in every screen of your application.
  • You can integrate this features in your application activity, which has more textual content to read. An e.g. activity that shows chat conversation in messaging app or activity that displays full article in your blogging application. (This list can be extended for may other use cases. Let me know if you have more ideas in comments.)

For the full sample application and the source code, visit GitHub.

User Aware Video View

These days all new smartphones are packed with lots of sensors and most of the smartphone contains the front (selfie) camera. So, why don’t we make use of them to improve the user experience? While watching the video on your device is the most important feature for many social sharing, messaging and media applications.

UserAwareVideoView is a customized video viewer that smartly play and pause the video based on your user is looking at the video or not. If the user is not looking at the screen then this will automatically pause the video, so your user does not miss any part of the video.

UserAwareVideoView inherits the android framework’s default VideoViewclass. So, it has all the features that video viewer has. More than that it makes it easy to convert your all the default video views to UserAwareVideoView in your existing application.

How does it work?

At its core UserAwareVideoView uses Google Play Service Mobile Vision API for the image processing. It uses front camera of the device to track user’s eyes.

When VideoView.start() is called, it starts the eye tracking algorithm and starts tracking the user’s eyes. It also starts monitoring surrounding light intensity and if the light intensity is not enough for processing camera output, it stops tracking the user’s eyes.

If the user is not looking at the device screen, UserAwareVideoView will pause the video and it will resume the video as soon as the user starts looking at the screen. Pretty amazing huh!!!

Whenever VideoView.stopPlayback() or VideoView.pause() is called, this will UserAwareVideoView will release the camera and stop eye tracking to consume the battery.

How to integrate?

To start with the integration, first provide the Gradle dependency of the library by entering below lines in your module level build.gradle.


This library automatically adds android.permission.CAMERA permission in your applications AndroidManifest.xml file.

Add the UserAwareVideoView in you xml layout of your activity or fragment. You can use UserAwareVideoView just like you use the default VideoView in your layout.

Initialize the UserAwareVideoView in your activity/fragment by following three steps:

  • Step-1: Check for the Camera permission in run-time.
  • Step-2: Register UserAwarenessListener to get the callbacks from the UserAwareVideoView whenever error occurs in eyes detection or eye detection starts stops.
  • Step-3: Handle errors that may occur while eyes detection. There are main 4 errors. You can detect those errors by error code. Below is the snippet showing how you can handle different errors.

That’s it. You are ready with UserAwareVideoView.


By using the UserAwareVideoView, you can make your application smart that responds to the user’s activity and uses the phone’s sensors to control the video playback so that your user don’t miss any part of the video.

For the full sample application and the source code, visit GitHub.