在UITableViewCell中使用AlamofireImage

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

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

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

假设您正在讨论该UIImageView类别,是的,它确实解决了许多困扰天真异步图像检索问题的问题,即:

如果在所讨论的单元格的上方或下方插入单元格,则已NSIndexPath更改的事实不会影响所讨论image的单元格的异步更新.

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

这样做的一个含义是,它避免了对于先前与该重用单元关联的行的图像的图像请求更新可见行的图像视图.(这避免了简单实现可能遇到的慢速连接上的图像"闪烁".)

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

AlamofireImage还提供图像大小调整例程,这在显示单元格的缩略图时非常重要.如果不调整图像大小,则在使用大型资源时可能会占用大量内存(特别是在可能显示许多缩略图图像的集合视图中).

就UITableViewCellAlamofireImage可能无法正常处理的问题而言,它包括:

关于缓存,AlamofireImage依赖于底层NSURLCache而不是通过NSCache本地持久存储进行自己的缓存.虽然我理解为什么作者这样做(有一种直观的吸引力,只要NSURLCache 应该能够优雅地做到这一点),你应该意识到这NSURLCache可能有问题,只能根据记录不完整的规则进行缓存(如果资源超过5%)总缓存大小,它不会被缓存;如果HTTP标头不正确,它将不会缓存,等等.).因此,必须小心缓存问题.

关于预热(预取与可见行相邻的单元格的图像),AlamofireImage在这里做的不多.您可能希望查看与可见行相邻的单元格的一些低优先级请求管理,以便不会对可见单元格性能产生负面影响,同时还可以在用户滚动时与这些行关联的图像.

最重要的是,在使用UIImageView类别时,说"你不需要担心细胞重用的东西"是夸大其辞的.您仍然需要仔细设计您的单元重用逻辑,例如:

确保您没有任何绕过图像视图更新的路径,即使有问题的行可能没有要显示的图像;

确定是否需要调整图像大小;

确认NSURLCache在您的情况下正确缓存;

决定是否要创建和缓存缩略图;

等等.

但确实如此,一个执行良好的UIImageView类别可以预防许多过于简单的异步图像检索例程的陷阱.但这不是银弹.