虽然我在下面的原始答案试图解决与异步图像检索相关的几个关键问题，但它仍然从根本上受到限制。正确的实现还可以确保如果您快速滚动，可见单元格的优先级高于已滚动到屏幕外的单元格。它还将支持取消先前的请求（并在适当的时候为您取消它们）。
虽然我们可以将这些类型的功能添加到下面的代码中，但最好采用一个既定的、经过验证的解决方案，该解决方案利用下面讨论的NSOperationQueue技术NSCache，但也解决了上述问题。UIImageView最简单的解决方案是采用支持异步图像检索的已建立类别之一。AFNetworking和SDWebImage库都有可以优雅UIImageView地处理所有这些问题的类别。
您可以使用GCDNSOperationQueue或GCD进行延迟加载（有关不同异步操作技术的讨论，请参阅并发编程指南）。前者的优势在于您可以精确指定允许多少并发操作，这对于从 Web 加载图像非常重要，因为许多 Web 服务器限制了它们将从给定客户端接受的并发请求的数量。
基本思想是：
- 在单独的后台队列中提交图像数据的请求；
- 下载完图像后，将 UI 更新分派回主队列，因为您不应该在后台进行 UI 更新；
- 在主队列上运行已调度的最终 UI 更新代码时，请确保
UITableViewCell它仍然可见，并且它没有被出列和重用，因为有问题的单元格滚动出屏幕。如果您不这样做，则可能会暂时显示错误的图像。
您可能希望将您的代码替换为以下代码：
首先，为您定义一个NSOperationQueue用于下载图像以及NSCache存储这些图像的属性：
@property (nonatomic, strong) NSOperationQueue *imageDownloadingQueue;
@property (nonatomic, strong) NSCache *imageCache;
其次，初始化这个队列并缓存在viewDidLoad：
- (void)viewDidLoad
{
[super viewDidLoad];
self.imageDownloadingQueue = [[NSOperationQueue alloc] init];
self.imageDownloadingQueue.maxConcurrentOperationCount = 4; // many servers limit how many concurrent requests they'll accept from a device, so make sure to set this accordingly
self.imageCache = [[NSCache alloc] init];
// the rest of your viewDidLoad
}
第三，您cellForRowAtIndexPath可能看起来像：
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
btnBack.hidden = FALSE;
static NSString *CellIdentifier = @"Cell";
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
if (cell == nil) {
cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier] autorelease];
cell.selectionStyle = UITableViewCellSelectionStyleNone;
cell.accessoryType = UITableViewCellAccessoryDisclosureIndicator;
cell.backgroundColor = [UIColor clearColor];
cell.textLabel.font = [UIFont fontWithName:@"Noteworthy" size:17.0];
cell.textLabel.font = [UIFont boldSystemFontOfSize:17.0];
cell.textLabel.textColor = [UIColor blackColor];
cell.textLabel.highlightedTextColor = [UIColor blackColor];
}
cell.textLabel.text = [NSString stringWithFormat:@" %@", [test.arrTitle objectAtIndex:indexPath.row]];
// code change starts here ... initialize image and then do image loading in background
NSString *imageUrlString = [NSString stringWithFormat:@"http://%@", [test.arrImages objectAtIndex:indexPath.row]];
UIImage *cachedImage = [self.imageCache objectForKey:imageUrlString];
if (cachedImage) {
cell.imageView.image = cachedImage;
} else {
// you'll want to initialize the image with some blank image as a placeholder
cell.imageView.image = [UIImage imageNamed:@"blankthumbnail.png"];
// now download in the image in the background
[self.imageDownloadingQueue addOperationWithBlock:^{
NSURL *imageUrl = [NSURL URLWithString:imageUrlString];
NSData *imageData = [NSData dataWithContentsOfURL:imageUrl];
UIImage *image = nil;
if (imageData)
image = [UIImage imageWithData:imageData];
if (image) {
// add the image to your cache
[self.imageCache setObject:image forKey:imageUrlString];
// finally, update the user interface in the main queue
[[NSOperationQueue mainQueue] addOperationWithBlock:^{
// Make sure the cell is still visible
// Note, by using the same `indexPath`, this makes a fundamental
// assumption that you did not insert any rows in the intervening
// time. If this is not a valid assumption, make sure you go back
// to your model to identify the correct `indexPath`/`updateCell`
UITableViewCell *updateCell = [tableView cellForRowAtIndexPath:indexPath];
if (updateCell)
updateCell.imageView.image = image;
}];
}
}];
}
return cell;
}
第四，也是最后，虽然人们可能倾向于在内存不足的情况下编写代码来清除缓存，但事实证明它是自动执行的，因此这里不需要额外的处理。如果你在模拟器中手动模拟低内存的情况，你不会看到它因为NSCache没有响应而驱逐它的对象UIApplicationDidReceiveMemoryWarningNotification，但是在实际运行过程中，当内存低时，缓存会被清除。实际上，NSCache本身不再优雅地响应低内存情况，因此您确实应该为此通知添加观察者并在低内存情况下清空缓存。
我可能会建议一些其他优化（例如，也许还将图像缓存到持久存储中以简化未来的操作；我实际上将所有这些逻辑都放在我自己的AsyncImage类中），但首先看看这是否解决了基本的性能问题。