9

我在这里阅读了很多答案，说通过使用 AlamofireImage 辅助方法（例如af_setImageWithURL()）或任何等效库，您无需担心单元格重用的东西（另外，许多已发布的教程实际上就是这样做的）。也就是说，在后台下载完成后，我不必保持对单元格的弱引用或使用tableView的cellForRowAtIndexPath()方法更新其imageView，就像我们通常手动发出请求时所做的那样。

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

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

4

1 回答 1

14

假设您正在谈论该UIImageView类别，是的，它确实解决了许多困扰幼稚异步图像检索问题的问题，即：

  • 如果在相关单元格的上方或下方插入一个单元格，则 已更改的事实NSIndexPath不会影响相关image单元格的异步更新。

  • 如果您在调用af_setImageWithURL重用单元格时快速滚动到第 100 行，则对先前与此重用单元格关联的先前行的请求将被取消。

    • 这样做的一个含义是它避免了可见行的图像视图随着对先前与此重用单元关联的行的图像的图像请求而更新。（这避免了简单实现可能遇到的慢速连接上的图像“闪烁”。）

    • 这样做的另一个含义是，它避免了与单元格 100 相关联的图像可能积压在第 1-99 行的图像请求之后的性能问题。

  • AlamofireImage 还提供图像大小调整例程，这在显示单元格的缩略图时很重要。如果您不调整图像大小，则在使用大型资源时可能会占用大量内存（尤其是在可能可见许多缩略图的集合视图中）。

对于UITableViewCellAlamofireImage 可能无法像我们希望的那样优雅处理的问题，它包括：

  • 关于缓存，AlamofireImage 依赖于底层而不是通过或本地持久存储NSURLCache进行自己的缓存。NSCache虽然我理解作者为什么这样做（有一定的直观吸引力，只要能够优雅地做到这一点），您应该知道这NSURLCache 可能NSURLCache是有问题的，只能根据记录不充分的规则进行缓存（如果资源超过 5%总缓存大小，它不会被缓存；如果 HTTP 标头不完全正确，它不会缓存，等等）。因此，在缓存问题上必须小心。

  • 关于预热（预取与可见行相邻的单元格的图像），AlamofireImage 在这里没有做太多。您可能希望看到与可见行相邻的单元格的一些低优先级请求管理，这样可见单元格的性能不会受到不利影响，而且当用户滚动时，与这些行关联的图像已经存在。

UIImageView最重要的是，在使用类别时说“您无需担心单元格重用东西”是夸大其词。您仍然需要仔细设计您的单元重用逻辑，例如：

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

但确实，一个执行良好的UIImageView类别可以避免许多过于简单的异步图像检索例程的陷阱。但这不是灵丹妙药。

于 2016-02-14T18:31:28.270 回答