Why would I ever NOT use BitmapFactory's inPurgeable option?

Asked 15/8, 2011 at 17:10 Answered 7/11, 2013 at 20:52

Android's BitmapFactory.Options.inPurgeable has been recommended in various places as a way to avoid OutOfMemory exceptions in Android 2.x and earlier (Android 3.1 fixes this).

If inPurgeable is so great, why would I ever NOT want to use it? The documentation seems very light on details about what this option is doing:

If this is set to true, then the resulting bitmap will allocate its pixels such that they can be purged if the system needs to reclaim memory. In that instance, when the pixels need to be accessed again (e.g. the bitmap is drawn, getPixels() is called), they will be automatically re-decoded

Seems great. What's the catch?

Katelin answered 15/8, 2011 at 17:10 Comment(0)

The documentation has subsequently been updated with additional information which addresses your original question.

Summary: use of this flag is no longer recommended.

Sindhi answered 7/11, 2013 at 20:52 Comment(2)

Indeed, this flag has since (as of API 21) been deprecated. – Dagger 10/2, 2015 at 5:58

What should i use now? – Gobbledegook 1/7, 2020 at 20:24

If your are reading your bitmaps from the filesystem, using this flag wil force Android to keep the file open (at least in 4.0.4) to be able to re-read it. After reading more than 1024 files, you will reach the limit of opened files and get a "Too many open files" error.

You can observe the beahavior by using the lsof command from a rooted terminal and review all opened files.

Discobolus answered 31/7, 2013 at 14:37 Comment(1)

What are you meaning by "from the filesystem"? Did you mean taken pictures by camera, or selected images from Gallery too? – Depressive 11/11, 2016 at 12:37

This flag is currently completely ignored, that's the catch.

Update by @slodge: please anyone who is reading this and seeing it as the correct answer also read the comments - 'This flag is currently completely ignored' is true in certain cases only - in other cases (e.g. when using decodeByteArray on downloaded data) then this flag is not ignored and is very, very useful

Peradventure answered 15/8, 2011 at 17:36 Comment(9)

lol, I just logged back in to edit my question to remove the part that said "it does seem to make my app better behaved when loading many images" when I saw your comment. – Katelin 15/8, 2011 at 17:52

I've run the ApiDemo's "PurgeableBitmap" activity and it seems to consistently run out of memory at 128 or 122 (depending on device) with the NonPurgeable, but Purgeable is consistently 200 on both. This suggests the flag is not completely ignored. Can you expand on this at all? Thanks – Apul 27/8, 2011 at 4:52

Romain, by "currently", do you mean Honeycomb+? Because the "external' memory problem has been resolved? – Revelationist 30/9, 2011 at 20:46

By currently I mean "any available version of Android." And I don't know what external memory problem you are talking about. – Peradventure 30/9, 2011 at 23:26

Romain, this setting most definitely fixes the OOM issues and the "external" memory (as reported by GC messages) ballooning out of control and running the VM out of memory. I tested on Gingerbread in both VM and real devices. There is no way it can be completely ignored as without it, I couldn't even scroll through a [sufficiently long] ListView with Bitmaps without crashing OOM. – Revelationist 4/10, 2011 at 18:40

Romain, I looked at the source and found that decodeByteArray() calls nativeDecodeByteArray(), which then definitely uses inPurgeable (not sure exactly for what, but it's used for copying memory). See google.com/codesearch#uX1GffpyOZk/core/jni/android/graphics/… and google.com/codesearch#9OZVrqQu3Xg/trunk/googleclient/…. Am I too far off here? – Revelationist 4/10, 2011 at 21:25

Looks like it's used with decodeByteArray, which I didn't know you were using. It should definitely be ignored with decodeResource for instance. – Peradventure 4/10, 2011 at 21:51

Heh, never said which function we were using, but your reply made it seem like it's not used by anything. – Revelationist 4/10, 2011 at 22:11

decodeByteArray crashes every time I don't use inPurgeable, even on ridiculously small images (4Ko…) – Nuclei 11/10, 2011 at 15:16

For the re-decode to happen, the bitmap must have access to the encoded data, either by sharing a reference to the input or by making a copy of it.

If you don't have access to the encoded data anymore, then this could be a problem right? What if you were live decoding bitmaps from a streaming ByteArray and your application just decides to reclaim the memory, wouldn't that cause your Bitmap to lose those pixels?

Jade answered 15/8, 2011 at 17:30 Comment(0)

Recommended topics

Hot tags