缓存已存储在文件系统上的解码位图答案

【问题标题】：Caching decoded bitmap already stored on file system缓存已存储在文件系统上的解码位图
【发布时间】：2013-11-25 20:11:09
【问题描述】：

我正在制作一些小位图，其中大约 100 个。但它们是非常小的缩略图大小的图像。我的设计是从服务器下载列表并将它们保存在本地文件系统上。当用户需要位图时，我会这样做

BitmapFactory.decodeFile(pathName);

我的问题基本上是：我应该缓存解码的位图吗？这样下次调用时，我可以返回已经解码的图像，而不是再次解码。在某些情况下，这些位图在我的整个应用程序中使用，因此对解码的调用很频繁。但另一方面，我会缓存大约 100 个位图。所以新的代码是

if(null == bitmap)
    return (bitmap = BitmapFactory.decodeFile(pathName));
else return bitmap;

有人可以谈谈新设计在空间/时间复杂性、性能、声音设计等方面的成本/收益吗？此外，位图通常显示在 ListView 中。

为什么@dumazy 的反应对我的情况并不明显：

当我从服务器下载时，我将元数据存储在哈希图中：

Map<String,MyIcon> myIcons …

MyIcons 类是这样的：

class MyIcon{

   String filepath;//path of image on local filesystem.
   String url;// url to where image is on server
   Bitmap myImage;// for caching so not to decode each time
   ...//other fields about the icon

//then a number of methods
}

所以从我的角度来看，使用 LruCache 意味着在 MyIcon 中创建一个扩展 LruCache 的静态嵌套类。然后对于 MyIcon 的每个实例，当从 LruCache 中逐出位图时，我需要确保关联的 myImage 设置为 null。这看起来很复杂，我什至不确定它会起作用。也许这里的 Java 专家可以告诉我如何知道它是否有效，我应该实现它。

【问题讨论】：

标签： java android android-layout caching bitmap

【解决方案1】：

位图解码需要相当长的时间。最佳做法是使用LruCache。看看这个教程here

由于您使用的是 ListView，因此只能在 Adapter 的 getView() 方法中加载它们。还可以使用 AsyncTask 来初始加载它们

【讨论】：

感谢您的文章，读起来很好。但我不太确定这对我来说是不是最好的解决方案。但根据您的回答，我似乎应该限制我拥有的缓存位图的数量。我会在我的重构中考虑到这一点。 +1。