寻找Android的“杀手”内存caching机制

背景

Android有一个非常有限的最大堆大小,每个设备有不同的最大堆。

某些应用程序需要将内容(通常是图像)caching在内存中,而不仅仅是内部/外部存储。

当然,关于处理位图和使用尽可能less的内存有很多好的提示 ,但是caching也是需要的。

问题

我已经阅读了许多可能的caching解决scheme,但都没有提供一种caching,这将是一个杀手级caching解决scheme。 我想要的是具有下一个特性的caching机制:

  1. 无限制地使用堆,而不用担心内存不足。 应用程序需要内存,没有足够的可用内存? 所以释放一些(未被引用的)项目(和它们的键)。

  2. 线程安全性/并发性。

  3. 提供基于LRU的caching,以便最近使用的项目留下的机会更大。

  4. 尽可能保持活力(但不会导致任何崩溃)。 然而,不幸的是,在Android上,与Java相比,软/弱引用GC-ed非常快速。

  5. 能够处理隐藏其实际大小的对象。 在Android上,在API 10及以下版本中,位图并没有使用堆内存,而是被认为是这样,所以虚拟机无法知道何时释放它们,因为它认为使用相同数量的内存作为单个引用(4字节左右)。 这就是为什么一些解决scheme提供人为地告诉每个项目的大小,以及当它是时候删除它应该做什么。

一些很好的解决scheme

  1. LruCache – 来自API 12的一个类(你可以很容易地复制它的代码)。

    优点:#2(?),#3,#5。

    缺点:#1,#4,加上你需要复制它的源代码,因为它是在API 12上呈现的。

  2. 一个哈希映射,其值为软/弱参考 ,如本文第50页所示,摘自本演讲 。

    优点:#1(但不删除键),#2(需要使用ConcurrentHashMap )

    缺点:#3,#4,#5

  3. MapMaker (可从guava库中获得 ),就像以前的解决scheme的高级版本。

    优点:#1,#2

    缺点:#3,#4,#5

  4. 通过番石榴库caching解决scheme 。 优点和缺点是根据您的select。 不知道哪种configuration最适合需求,如果它在Android上正常工作。 可悲的是,我甚至无法成功编译Android库。

  5. Android查询 – 不知道它是如何工作的。 看起来很容易使用,但不知道它的优点和缺点。

有人知道杀手caching机制吗?

我对function#5不在乎,因为它是相当先进的,将来不会太需要,因为越来越多的人拥有更新的Android版本。

Solutions Collecting From Web of "寻找Android的“杀手”内存caching机制"

正如我所看到的,#1有一个实际的禁止问题。 您不能释放从应用程序的其他部分引用的对象; 因此,不可能创build一个能够随意释放记忆的结构。

我看到的唯一解决scheme是创build自己的caching,支持LRU,并能够处理弱和强引用。 一个项目开始作为一个强大的引用的东西,如果不使用一段时间,或内存约束强制执行,您将其更改为一个弱引用。 这并不是一件简单的事情,所有的应用程序都必须进行微调。

您可能正在寻找更一般的解决scheme,但如果您主要关注图像,请查看ImageLoader 。 我一直在使用它一段时间,它适用于我所需要的。 当初始化它时,你可以告诉它使用一个LRUCache并告诉它要使用的可用内存的百分比。

作为一个侧面说明, HttpResponseCache使从服务器caching数据非常非常好。

看看Android BitMap Cache,这是一个大大改进的LruCache版本。

http://www.senab.co.uk/2013/01/24/android-bitmapcache-v2-1/