关于使用沙箱与缓存进行 UITableView 异步图像下载的建议

Question

苹果一周前刚刚发布了一些关于 UITableView 中延迟加载图像的示例代码。我检查了它并将其实现到我自己的 UITableView（这是一个用于快速滚动的 drawRect 视图）中，看看与我已经在做的事情是否有区别。

实施后我不确定什么是最好的；新代码或我已有的代码。我没有看到我的 3GS 的速度有太大的提高。

“沙盒”方法：延迟加载图像，然后保存到沙盒中的本地 tmp 文件夹中。每次显示该单元格时，它都会查找具有该文件名的图像是否已位于沙箱文件夹中。如果是，则检索图像并显示它，如果不是，则继续下载，将其保存在本地，然后显示。这样做的好处是，当您第二次打开应用程序时，图像不会是空白的。它们已经被下载并准备好显示。

缓存方法：这也会延迟加载图像，但是，现在我在表视图中显示的数组中的每个对象上包含一个 UIImage。现在，我不再将图像保存在本地，而是下载图像并将其放入对象的数组中。现在，它不再每次都检查文件名，而是只检查 UIImage != nil 是否并使用缓存的图像（如果 nil 则下载）。

一个小的区别是，缓存代码在将图像缓存到单元格中显示的确切大小之前会调整图像大小，而沙箱代码示例中使用的图像实际上比它需要显示的图像要大一些，这意味着滚动时它也必须动态调整大小。我几个月前读到，这样做可能有点昂贵，而且我也不确定使用缓存图像而不是沙箱存储图像是否有很大区别，因此无论如何都会占用更多 CPU 资源（与到您使用上面的缓存代码从缓存中保存的内容）。

我想我的问题是我是否应该担心缓存代码？同样，新代码不会在新启动时立即加载图像，而旧代码实际上会加载图像，因为它已经在沙箱中。由于我没有重复使用图像，因此我有很多图像要加载（从沙箱或缓存），所以我没有注意到速度上的巨大差异。事实上，在我看来，在我的 3GS 上这几乎是不可能的。滚动不是丝般光滑，我认为这是由于大量图像无法重复使用（每个单元格有不同的图像）。我还想知道，一旦文件夹中有 1000 多张图像，沙箱方法是否会变慢，例如，最终让它查看的图像不仅仅是 100 张左右。

我希望我说得有道理。我想要非常彻底地了解细节，并且如果需要的话我很乐意提供更多细节。

谢谢！

Answer 1

判断性能是否存在明显差异的唯一好方法是使用分析工具，例如 Instruments（用于测量两种技术的显示帧率等）或 Shark（用于确定代码中的热点）。您的具体实现可能存在细微差异，这可能会导致我们给出的任何一般答案与您在应用程序中看到的实际性能之间存在显着差异。

我对“沙盒”方法主要关心的不是性能，而是磁盘空间使用情况。用户不会喜欢您用不必要的文件填充他们的 iPhone 或 iPod Touch，特别是如果所有图像未一致使用或使用的图像集经常更改。如果不了解有关应用程序的更多信息，就不可能猜测这些缓存图像的加载频率。

如果您在自己的设备上进行本地测试，则可能使用 Wifi 网络。我的建议是在测试过程中关闭 Wifi，看看当您必须通过蜂窝网络获取所有图像时这两种方法的表现如何。我还建议尝试寻找较旧的设备（iPhone 3G 或更差），因为 3GS 实际上隐藏了潜在的性能问题，这些问题可能会让使用旧设备的用户感到烦恼。

我个人曾多次在我的应用程序中使用 LazyTableImages 技术（前提是它在 WWDC09 和最近的“发布”之间没有发生巨大变化），并且发现它正是我所需要的。然而，在我的情况下，在磁盘上缓存图像不是一个选项，并且您不应该过分考虑我的轶事 - 分析您自己的代码并使用它显示的结果。

编辑：

显而易见的答案是访问内存缓存将比访问文件系统更快，但当然最终的结果取决于分析。如果图像已经在内存中，则不需要从闪存读取它们并由 UIImage 解析。不过，传统的权衡在这里发挥作用 - 内存缓存与磁盘空间。

虽然将图像存储在内存中可能会更快，但您需要非常确保正确处理应用程序中的内存警告（无论如何您都应该这样做！）。否则，长时间使用将导致内存缓存中出现很多很多图像并触发内存警告，如果您的应用程序不是为处理这些而构建的，那么您的应用程序最多会因缺乏内存资源而被操作系统杀死。