android - 寻找Android的 "killer"内存缓存机制

Question

就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用资料或专业知识的支持，但这个问题可能会引发辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the help center寻求指导。




9年前关闭。




背景

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

一些应用程序需要能够在内存中缓存内容(通常是图像)，而不仅仅是在内部/外部存储中。

当然还有很多nice tips关于处理位图和使用尽可能少的内存，但缓存也是需要的。

问题

我已经阅读了许多可能的缓存解决方案，但没有一个提供一种可以成为杀手级缓存解决方案的缓存。我想要的是一种具有以下功能的缓存机制:

无限使用堆，不用担心内存不足。应用程序需要内存并且没有足够的可用内存？所以释放一些(未引用的)项目(及其 key )。

线程安全/并发。

提供基于 LRU 的缓存，以便最近使用的项目有更高的保留机会。

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

能够处理隐藏其真实大小的对象。在 Android 上，在 API 10 及更低版本上，位图不使用堆内存，但被认为是这样的，因此 VM 无法知道何时释放它们，因为它认为使用与单个引用相同的内存量(4字节左右)。这就是为什么一些解决方案可以人为地告诉每个项目的大小，以及何时删除它。

一些好的可能解决方案

LruCache - API 12 中的一个类(尽管您可以轻松复制它的代码)。

优点:#2(？)，#3，#5。

缺点:#1、#4，加上你需要复制它的源代码，因为它是在 API 12 上提供的。

一个哈希图，其值具有软/弱引用 ，如图here第 50 页，取自 this lecture .

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

缺点:#3、#4、#5

MapMaker (可从 the guava library 获得)，这就像先前解决方案的高级版本。

优点:#1、#2

缺点:#3、#4、#5

Caching solutions通过 Guava 库。优点和缺点取决于您的选择。不确定哪种配置最适合需求，以及它是否在 Android 上运行良好。可悲的是，我什至无法为 Android 编译库。

Android query - 不知道它是如何工作的。看起来很容易使用，但不确定它的优缺点。

问题

有人知道杀手缓存机制吗？

我不太关心功能 #5，因为它非常先进，并且随着越来越多的人拥有更新的 Android 版本，将来不会那么需要。

Answer 1

正如我所看到的，#1 存在一个实际的禁止问题。您不能释放从应用程序的其他部分引用的对象；因此，不可能创建一个随意释放内存的构造。

我看到的唯一解决方案是创建自己的支持 LRU 并且能够处理弱引用和强引用的缓存。一个项目开始是一个强引用的东西，如果有一段时间不使用，或者强制执行内存限制，你可以将其更改为弱引用。这并不容易创建，并且必须确保在所有应用程序中进行微调。