Android 5.0 Doesn't Support BitmapFactory.Options InPurgeable

I'm learning the fresco lib of Facebook. I see that storing bitmap on ashmem with the option is inPurgeable so great. It takes us a lot of care about memory management but decrease

Solution 1:

This was answered in Fresco's blog post. See the section on "Purgeable bitmaps" and "Having our cake and eating it too". If you use Fresco, you will get the faster performance and fewer OOMs, and you won't lose performance predictability.

Note though Fresco also goes to a lot of trouble to manage bitmap memory, being very careful to avoid memory leaks and close bitmaps as soon as possible. If you tried using the NDK yourself instead of using Fresco, you'd need to be equally careful.

Google could have also built a Fresco-like solution as part of the Android API, but they chose not to. To be fair, Android 5.0 has a number of improvements that make bitmap allocation less painful than it was earlier. Large objects like bitmaps are placed in a separate memory space on the heap and garbage-collected separately, which is much faster. So perhaps they felt that was enough.

Solution 2:

The documentation offers the following:

This field was deprecated in API level 21. As of LOLLIPOP, this is ignored. In KITKAT and below, 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.

With the further explanation that seemingly answers your question:

While inPurgeable can help avoid big Dalvik heap allocations (from API level 11 onward), it sacrifices performance predictability since any image that the view system tries to draw may incur a decode delay which can lead to dropped frames. Therefore, most apps should avoid using inPurgeable to allow for a fast and fluid UI. To minimize Dalvik heap allocations use the inBitmap flag instead.