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?
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.