4

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 decreases OutOfMemoryError on Davilk heap. I wonder why Android 5.0 doesn't continously support BitmapFactory.Options inPurgeable.
Are there any changes in ART?
Can anyone explain the reason for me? Thanks in advance.

EDIT
According to Ed George's answer:
Why do Facebook engineers still use inPurgeable from Android 3.0 -> 4.4?
Do they trade off Dalvik heap allocations for performance predictability?

Huy Duong Tu
  • 7,798
  • 5
  • 25
  • 46

2 Answers2

3

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.

tyronen
  • 2,558
  • 1
  • 11
  • 15
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.

Ed Holloway-George
  • 5,092
  • 2
  • 37
  • 66
  • So Why does fresco lib still use inPurgeable for android 3.0 -> 4.4 if it decreases performance? – Huy Duong Tu May 18 '15 at 08:40
  • You'd have to ask the authors that, but I'd imagine it would be because a decrease in performance wasn't recognised or attributed to that method pre-API 21 – Ed Holloway-George May 18 '15 at 08:43
  • Because inPurgeable combined with lockPixels puts the bitmap in ashmem and not on the Java heap. This means bitmap memory can be manually managed instead of being reclaimed by (expensive) GC. – Karthik Jun 09 '15 at 07:42