我正在fresco学习Facebook. 我看到ashmem使用该选项存储位图inPurgeable非常棒。我们需要非常关心内存管理，但OutOfMemoryError在Davilk heap. 我想知道为什么 Android 5.0 不继续支持BitmapFactory.Options inPurgeable.
有什么变化ART吗？
谁能解释我的原因？提前致谢。
编辑
根据 Ed George 的回答：
为什么 Facebook 工程师仍然使用 Android 3.0 -> 4.4 的 inPurgeable？
他们是否权衡了 Dalvik 堆分配以换取性能可预测性？
这在 Fresco 的博客文章中得到了回答。请参阅“可清除位图”和“吃蛋糕也吃”部分。如果您使用 Fresco，您将获得更快的性能和更少的 OOM，并且不会失去性能可预测性。
请注意，虽然 Fresco 在管理位图内存方面也遇到了很多麻烦，但要非常小心以避免内存泄漏并尽快关闭位图。如果您尝试自己使用 NDK 而不是使用 Fresco，则需要同样小心。
Google 也可以构建一个类似 Fresco 的解决方案作为 Android API 的一部分，但他们选择不这样做。公平地说，Android 5.0 有许多改进，使位图分配比以前更痛苦。像位图这样的大对象被放置在堆上的单独内存空间中，并单独进行垃圾收集，这要快得多。所以也许他们觉得这就够了。
该文档提供以下内容：
此字段在 API 级别 21 中已弃用。从 LOLLIPOP 开始，此字段被忽略。在 KITKAT 及以下版本中，如果将其设置为 true，则生成的位图将分配其像素，以便在系统需要回收内存时可以清除它们。在这种情况下，当需要再次访问像素时（例如，绘制位图，调用 getPixels()），它们将被自动重新解码。
进一步的解释似乎回答了你的问题：
虽然 inPurgeable 可以帮助避免大的 Dalvik 堆分配（从 API 级别 11 开始），但它牺牲了性能可预测性，因为视图系统尝试绘制的任何图像都可能导致解码延迟，从而导致丢帧。因此，大多数应用程序应避免使用 inPurgeable 以实现快速流畅的 UI。要最小化 Dalvik 堆分配，请改用 inBitmap 标志。