在UITableViewCell中使用AlamofireImage
我一直在阅读大量的答案 ，通过使用AlamofireImage帮助器方法（例如af_setImageWithURL() ）或任何等价的库，你不需要担心细胞重用的东西（另外，许多发表的教程实际上只是这样做） 。 也就是说，在后台下载完成之后，我不必保留对单元格的弱引用，也不必通过使用tableView的cellForRowAtIndexPath()方法来更新它的imageView，就像我们通常手动进行请求所做的那样。
首先，这是真的吗？ 如果是这样，在库里面是怎么做的，因为我试图跟踪AlamofireImage的af_setImageWithURL()代码，我找不到任何努力来确保我们仍然在我们提出请求的单元格上工作。 我错过了什么吗？
如果听起来很愚蠢，我很抱歉，但我真的很困惑。
假设你在谈论UIImageView类，是的，它确实解决了一些困扰初级asynchronous图像检索问题的问题，即：
-
如果一个单元格插入到所讨论的单元格的上方或下方，那么
NSIndexPath已经改变的事实将不会影响所述单元格的image的asynchronous更新。 -
如果快速滚动到第100行，因为您在重用单元格上调用
af_setImageWithURL，则之前与此重用单元格关联的先前行的请求将被取消。-
其中一个含义是它避免了可视行的图像视图更新了先前与该重用单元相关的行的图像的图像请求。 （这可以避免简单实现可能遇到的缓慢连接上的图像“闪烁”。）
-
这另一个含义是它避免了与单元100相关的图像可能在行1-99的图像请求之后积压的性能问题。
-
-
AlamofireImage还提供图像大小调整例程，这对于显示单元格的缩略图时非常重要。 如果您不调整图像大小，如果使用大型资源（特别是在可以看到许多缩略图图像的收集视图中），则可能会产生过多的内存使用量。
就AlamofireImage可能无法正常处理的UITableViewCell问题而言，它包括：
-
关于caching，AlamofireImage依赖于底层的
NSURLCache而不是通过NSCache或本地持久性存储进行自己的caching。 虽然我明白为什么作者这样做（有一个直观的吸引力，因为NSURLCache应该能够做到这一点），你应该知道，NSURLCache可以是有问题的，只caching根据logging不当的规则（如果资源超过5占总高速caching大小的百分比，不会被caching;如果HTTP标头不正确，则不会高速caching等）。 所以在caching问题上必须小心。 -
关于预热（与可见行相邻的单元的图像预取），AlamofireImage在这里没有太多的工作。 您可能想要查看与可见行相邻的单元格的低优先级请求pipe理，以便可见的单元格性能不会受到负面影响，而且还会使用户滚动时与这些行关联的图像已经存在。
底线是，在使用UIImageView类别时，说“你不需要担心单元重用的东西”是夸张的。 你仍然需要仔细devise你的单元复用逻辑，例如：
- 确保没有绕过图像视图更新的任何path，即使所讨论的行可能没有要显示的图像;
- 确定是否需要调整图像大小;
- 确认
NSURLCache在您的情况下正确caching; - 决定是否要创build和caching缩略图;
- 等等。
但是，一个执行得很好的UIImageView类别可以避免过度简化的asynchronous图像检索例程的许多缺陷。 但这不是银弹。