在UITableViewCell内部使用AlamofireImage [英] Using AlamofireImage Inside UITableViewCell

问题描述

我已经阅读了很多，表示通过使用AlamofireImage帮助器方法（例如 af_setImageWithURL（））或任何等效库，您无需担心单元重用的东西（此外，许多已发布的教程实际上就是这样做的）。也就是说，在后台下载完成后，我不必保持对单元格的弱引用或通过使用tableView的 cellForRowAtIndexPath（）方法来更新其imageView来获取该单元格，就像我们通常手动执行请求一样。

I've been reading a lot of answers here saying that by using AlamofireImage helper methods (e.g. af_setImageWithURL()) or any equivalent library, you don't need to worry about cell reusing stuff (Plus, many published tutorials actually just do that). That is to say, I don't have to keep a weak reference to the cell or getting it by using tableView's cellForRowAtIndexPath() method to update its imageView after the background downloading finishes, like what we usually do if request made manually.

首先，这是真的吗？如果是这样，它是如何在库中完成的，原因是我试图跟踪AlamofireImage的 af_setImageWithURL（）代码，但我找不到任何努力来确保我们仍然在我们发出请求的同一单元上工作。我错过了什么吗？

First of all, is that true? And if so, how it was done inside the library, cause I tried to trace AlamofireImage's af_setImageWithURL() code, and I cannot find any effort made to make sure we're still working on the same cell we made the request from. Am I missing something?

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

I am sorry if it sounds stupid, but I am really confused.

推荐答案

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

Assuming you're talking about the UIImageView category, yes, it does solve a number of problems that plague naïve asynchronous image retrieval issues, namely:

• 如果在相关单元格的上方或下方插入了单元格，则 NSIndexPath为事实更改不会影响所涉及单元格的图像的异步更新。

• If a cell is inserted above or below the cell in question, the fact that the NSIndexPath has changed will not affect the asynchronous updating of the image for the cell in question.

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

If you scroll quickly to row 100, as you call af_setImageWithURL on reused cells, the requests for prior rows that were previously associated with this reused cell will be canceled.

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

• 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.)

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

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也提供图像大小调整例程，这在显示单元格的缩略图时非常重要。如果不调整图像大小，则在使用大型资产时（尤其是在其中可以看到许多缩略图的集合视图中），可能会占用过多的内存。

AlamofireImage also provides image resizing routine, which is important when showing thumbnail images for cells. If you don't resize images, you can have extravagant memory usage if using large assets (especially in collection views in which many thumbnail images may be visible).

关于AlamofireImage可能无法如我们所愿处理的 UITableViewCell 问题，它包括：

In terms of UITableViewCell issues that AlamofireImage might not handle as gracefully as we'd like, it includes:

• 关于缓存，AlamofireImage依赖于基础 NSURLCache ，而不是通过<$自己进行缓存c $ c> NSCache 或本地持久存储。虽然我理解了作者为什么这样做（只要 NSURLCache 应该能够做到这一点，这有一定的直观吸引力），但您应该请注意， NSURLCache 可能会出现问题，仅按照记录不充分的规则进行缓存（如果资源超过总缓存大小的5％，则不会被缓存；不会如果HTTP标头不太正确，则进行缓存等）。因此，必须谨慎对待缓存问题。

• Regarding caching, AlamofireImage relies upon the underlying NSURLCache rather than doing its own caching via NSCache or to local persistent storage. While I understand why the author did that (there's a certain intuitive appeal, insofar as NSURLCache should be able to do this elegantly), you should be aware that NSURLCache can be problematic, only cacheing in accordance with poorly documented rules (if resource exceeds 5% of total cache size, it doesn't get cached; it won't cache if the HTTP headers aren't quite right, etc.). So one has to be careful on the caching issue.

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

Regarding preheating (the prefetching of images for cells that are adjacent to the visible rows), AlamofireImage doesn't do much here. You might want to see some low priority request management for cells that are adjacent to the visible rows, so that visible cell performance isn't adversely affected, but also so that the images associated with those rows are already when the user scrolls.

底线是夸张的说法，当您使用 a字样时说您无需担心单元重用的东西 UIImageView 类别。您仍然需要仔细设计单元复用逻辑，例如：

Bottom line, it is an overstatement to say "you don't need to worry about cell reusing stuff" when using a UIImageView category. You still need to carefully design your cell reuse logic, e.g.:

• 请确保您没有任何绕过更新的路径。图像视图，即使该行可能没有要显示的图像；


• 标识是否需要调整图像大小；


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


• 确定是否要创建和缓存缩略图；


• 等等

• Make sure you don't have any paths that bypass the updating of the image view, even if the row in question might not have an image to show;
• Identify whether image resizing is necessary;
• Confirm that NSURLCache is caching correctly in your situation;
• Decide whether you want to create and cache thumbnails;
• Etc.

但是，确实可以很好地执行 UIImageView 类别过于简单的异步图像检索例程的陷阱。但这不是灵丹妙药。

But it is true that a well-executed UIImageView category can forestall many pitfalls of overly-simplistic asynchronous image retrieval routines. But it's no silver bullet.

这篇关于在UITableViewCell内部使用AlamofireImage的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！