标签：android android-5-0-lollipop fresco bitmapcache

我正在学习Facebook的壁画库.我看到在ashmem上存储位图的选项是inPurgeable非常棒.它需要我们非常关心内存管理,但会降低Davilk堆上的OutOfMemoryError.
我想知道为什么Android 5.0不会持续支持inPurgeable中的BitmapFactory.Options.
ART有任何变化吗？
谁能解释一下我的原因？提前致谢.

编辑
根据Ed George的回答：
 为什么Facebook工程师仍然使用Android 3.0中的inPurgeable – > 4.4？
他们是否将Dalvik堆分配与性能可预测性进行权衡？

解决方法:

这在Fresco的blog post中得到了解答.请参阅“可清除位图”和“吃蛋糕并吃它”一节.如果您使用Fresco,您将获得更快的性能和更少的OOM,并且您不会失去性能可预测性.

请注意,尽管Fresco在管理位图内存方面也遇到了很多麻烦,但要小心避免内存泄漏并尽快关闭位图.如果您尝试使用NDK而不是使用Fresco,则需要同样小心.

谷歌本可以在Android API中构建类似Fresco的解决方案,但他们选择不这样做.公平地说,Android 5.0有许多改进,使位图分配比以前更少痛苦.像位图这样的大对象被放置在堆上的单独内存空间中并单独进行垃圾收集,这要快得多.所以也许他们认为这就足够了.

标签：android,android-5-0-lollipop,fresco,bitmapcache
来源： https://codeday.me/bug/20190609/1204750.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。