Home » Android » What's the use and advantages of using ImageDecoder of Android P?

What's the use and advantages of using ImageDecoder of Android P?

Posted by: admin May 14, 2020 Leave a comment

Questions:

Background

Android P presents a new API for loading images, using ImageDecoder class.

The problem

Not much is documented about this class, so I’m just curious about its usage, and whether I should consider using it when possible, instead of Glide library, for example, which Google itself recommends on using:

For most cases, we recommend that you use the Glide library to fetch,
decode, and display bitmaps in your app. Glide abstracts out most of
the complexity in handling these and other tasks related to working
with bitmaps and other images on Android. For information about using
and downloading Glide, visit the Glide repository on GitHub.

What I’ve found

I’ve found some articles about it, giving clues of what it can do and how to use it:

However, according to my tests, loading a GIF animation is worse using this API (takes more memory, uses about the same CPU) compared to Movie class, which in itself is worse than third party libraries such as android-gif-drawable . What I’ve tested is a rather long GIF animation. On the third party library it took about 59MB. Using Movie class it took about 168MB, and using the new ImageDecoder API it took 200-300MB …

So in short, what I’ve found about this API, is that:

  1. It’s supposed to replace BitmapFactory
  2. It supports loading animated GIF/WEBP
  3. It has some listeners for pre/post processing
  4. It’s supposed to be more efficient, but I don’t see it, at least not in terms of memory usage.

The questions

  1. Are there any advantages of using this API, over what we already have in third party libraries ? Meaning Glide for static images, and “android-gif-drawable” for GIF (and maybe something for WEBP that I didn’t search) ?

  2. Does it perform better behind the scenes, and I shouldn’t care about its memory usage?

  3. Does it have a memory/disk cache? If so, how does it manage its memory cache now that Android doesn’t store Bitmaps in the heap memory (wrote about it here) ?

  4. Is it possible this API will be available in the support library? Otherwise I don’t see much need to use it at all… EDIT: seems it might be on the support library. Link here.

How to&Answers: