AlamofireImage在UITableViewCell中的应用

Question

我在这里读到了很多answers，说通过使用AlamofireImage助手方法(例如af_setImageWithURL())或任何类似的库，您不需要担心单元格重用的问题(另外，许多已发表的教程实际上就是这样做的)。也就是说，我不必保留对单元格的弱引用，也不必使用tableView的cellForRowAtIndexPath()方法在后台下载完成后更新其imageView，就像我们通常在手动发出请求时所做的那样。

首先，这是真的吗？如果是这样的话，它是如何在库中完成的，因为我试图跟踪AlamofireImage的af_setImageWithURL()代码，我找不到任何努力来确保我们仍然在处理来自同一个单元的请求。我是不是遗漏了什么？

如果这听起来很愚蠢，我很抱歉，但我真的很困惑。

Answer 1

假设您讨论的是UIImageView类别，是的，它确实解决了一些困扰天真异步图像检索问题的问题，即：

• 如果将单元格插入到所述单元格的上面或下面，则NSIndexPath已更改的事实不会影响该单元格的image的异步更新。
• 如果快速滚动到第100行，即在重用单元格上调用af_setImageWithURL时，先前与此重用单元格关联的先前行的请求将被取消。

- One implication of this is that it avoids the image view for a visible row getting updated with the image request for the image for the row previously associated with this reused cell. (This avoids the "flickering" of images on slow connections that simplistic implementations can experience.)
- Another implication of this is that it avoids the performance problem where the image associated for cell 100 could get backlogged behind the image request for rows 1-99.

​

• AlamofireImage还提供图像调整例程，这在显示单元格缩略图时非常重要。如果不调整图像的大小，如果使用大型资产(特别是在可以看到许多缩略图的集合视图中)，则可以使用大量内存。

就UITableViewCell问题而言，AlamofireImage可能不会像我们希望的那样优雅地处理这些问题，它包括：

• 关于缓存，AlamofireImage依赖于底层的NSURLCache，而不是通过NSCache或本地持久存储进行自己的缓存。虽然我理解作者为什么这么做( NSURLCache应该能够很好地做到这一点，这有一定的直觉吸引力)，但是您应该知道，NSURLCache可能是有问题的，只能按照文档不清楚的规则进行缓存(如果资源超过缓存总量的5%，它就不会缓存；如果headers不太正确，它就不会缓存等等)。因此，在缓存问题上必须小心。
• 关于预热(为相邻可见行的单元格预取图像)，AlamofireImage在这里做得不多。您可能希望看到与可见行相邻的单元格的一些低优先级请求管理，这样可见单元格的性能不会受到不利影响，而且在用户滚动时，与这些行关联的图像也已经出现。

说到底，在使用UIImageView类别时，说“您不需要担心单元格重用”是言过其实的。您仍然需要仔细设计单元重用逻辑，例如：

• 确保您没有任何绕过更新图像视图的路径，即使所讨论的行可能没有要显示的图像；
• 确定是否需要调整图像大小；
• 确认NSURLCache在您的情况下是正确的缓存；
• 决定是否要创建和缓存缩略图；
• 等。

但是，一个执行良好的UIImageView类别确实可以防止过度简化的异步图像检索例程的许多缺陷。但这不是银弹。