Apple在一周前在UITableView中发布了一些关于延迟加载图像的示例代码。我检查了它并将它实现到我自己的UITableView（这是一个用于快速滚动的drawRect），看看是否与我已经在做的不同。
实施后我不确定什么是最好的;新代码或我已经拥有的代码。我的3GS速度没有太大提升。
“沙盒”方法：懒惰加载图片，然后保存到沙箱中的本地tmp文件夹。 每次显示单元格时，它会查找具有该文件名的图像是否已位于沙箱文件夹中。如果是，它将检索图像并显示它，如果没有继续下载，则在本地保存，然后显示它。这样做的好处是，第二次打开应用程序时，图像不会为空白。它们已经下载并准备好显示。
缓存方法：这也会懒惰地加载图像，但是，现在我在tableview中显示的数组中的每个对象上都包含一个UIImage。我现在下载图像并将其放入对象的数组中，而不是在本地保存图像。现在，不是每次检查文件名，而是检查UIImage！= nil是否使用缓存图像（或者如果为nil则下载）。
一个小的区别还在于缓存代码在将图像缓存到单元格中显示的精确大小之前调整图像的大小，而沙箱代码示例中使用的图像实际上比它需要显示的图像大一点，这意味着它必须在滚动时动态调整大小。我几个月前读到这可能有点贵，而且我也不确定它在使用缓存图像而不是沙盒存储图像方面是否会产生很大差异，因此无论如何都会占用更多的CPU（相比之下）使用上面的缓存代码从缓存中保存的内容。）
我想我的问题是我是否应该为缓存代码烦恼？同样，新代码不会立即在新的启动时加载图像，而旧代码实际上是因为它已经在沙箱中。由于我没有重复使用图像，因此我需要加载很多图像（从沙箱或缓存中），因此我没有注意到速度的巨大差异。事实上，在我的3GS上，在我看来几乎是不可能的。滚动不是如此平滑，我认为这是由于我无法重复使用的大量图像（每个单元格的图像不同）。我也想知道一旦文件夹中有1000多个图像，沙箱方法是否会变慢，例如，最终让它看到的图像不仅仅是100左右。
我希望我有意义。我希望对细节非常了解，如果需要，我很乐意提供更多细节。
谢谢！
答案 0 :(得分：1)
如果您的代码已经有效，并且没有紧迫问题，请不要更改。
如果您的滚动实际 太慢，那么也许您可以使用各种想法，并尝试获取UIImage，如果它不存在，则从沙箱中加载它，如果它是不在那里，然后下载它。
答案 1 :(得分：0)
判断性能是否存在明显差异的唯一好方法是使用仪器等分析工具（用于测量两种技术的显示帧率等）或Shark（用于确定代码中的热点）。您的确切实施可能存在细微差别，这可能会导致我们可以提供的任何一般性答案与您在应用程序中看到的实际性能之间存在显着差异。
主要关注“沙箱”方法的事情不是性能而是磁盘空间使用。用户不会感谢您使用不必要的文件填充他们的iPhone或iPod Touch，特别是如果没有一直使用所有图像或者经常更改使用的图像集。如果不了解您的应用程序，就无法猜测这些缓存图像的加载频率。
如果您在自己的设备上进行本地测试，则可能是在Wifi网络上。我的建议是关闭Wifi以进行部分测试，看看当你必须通过蜂窝网络获取所有图像时这两种方法的表现如何。我还建议尝试寻找旧设备（iPhone 3G或更糟糕的设备），因为3GS实际上隐藏了可能让旧设备上的用户烦恼的潜在性能问题。
我个人在我的应用程序中多次使用过LazyTableImages技术（前提是它在WWDC09和最近的'发布'之间没有大幅改变）并且发现它正是我需要的。然而，在我的情况下，在磁盘上缓存图像不是一个选项，你不应该过分强调我的轶事 - 描述你自己的代码并使用它显示的结果。
虽然将图像存储在内存中可能会更快，但您需要确保在应用程序中正确处理内存警告（正如您应该做的那样！）。否则长时间使用将导致内存缓存中的许多图像并触发内存警告，如果您的应用程序不是为处理这些而构建的，那么由于内存资源不足，操作系统最多会杀死您的应用程序。
答案 2 :(得分：0)
您提出的两种方法都有利弊 - 我建议您在应用中使用两者的元素。
最好将图像保存在内存中并在以后保存（可能在您的应用程序退出时）。如果您有大量图像，使用Core Data保存它们可能比使用常规文件更快。
最好避免动态调整大小，即在tableView：cellForRowAtIndexPath：或tableView：willDisplayCell：forRowAtIndexPath：方法或任何与绘制单元格内容视图有关的方法中。如果可以，请让图像提供商（内容管理？）提供表格视图显示大小的图像。