iOS多图异步下载和缓存机制

奋斗的郅博

大量小图显示指的也是多图下载。我们在很多项目中会遇到UITableView需要去显示一些标题、详情、图片等内容。我们需要去加载图片显示，有时候我们会为书写简单选择这种思路。

cell.textLabel.text = app.name;
cell.detailTextLabel.text = app.download;NSData *imageData = [NSData dataWithContentsOfURL:app.url];
cell.imageView.image = [UIImage imageWithData:imageData];

这样写有什么后果呢?

• 1.不可避免的卡顿(因为没有异步下载操作)
• 2.dataWithContentsOfURL：是耗时操作，将其放在主线程会造成卡顿。如果图片很多、很大，并且网络情况不好的话肯定会卡.
• 3.同一图片重复下载，耗费流量和系统开销(因为没有建立缓存机制)由于没有缓存机制，即使下载完成并显示了当前cell的图片，但是当该cell再一次需要显示的时候还是会下载它所对应的图片：耗费了下载流量，而且还导致重复操作。

怎么可以避免这些问题呢？

1.解决方案流程图

图片显示逻辑流程图

注：该流程图所需要的数据源：

1. 图片的URL：因为每张图片对应的URL都是唯一的，所以我们可以通过它来建立图片缓存和下载操作的缓存的键，以及拼接沙盒缓存的路径字符串。
2. 图片缓存(字典)：存放于内存中;键为图片的URL，值为UIImage对象。作用：读取速度快，直接使用UIImage对象。
3. 下载操作缓存(字典)：存放与内存中，键为图片的URL，值为NSBlockOperation对象。作用：用来避免对于同一张图片还要开启多个下载线程。
4. 沙盒缓存(文件路径对应NSData)：存放于磁盘中，位于Cache文件夹内。值为NSData对象(将UIImage转化为NSData才能写入磁盘里)。作用：程序断网，再次启动也可以直接在磁盘中拿到图片。

异步+缓存管理图片的相关实现代码

//图片缓存，下载操作缓存，沙盒缓存路径
　　/**
　　* 存放所有下载完的图片
　　*/@property (nonatomic, strong) NSMutableDictionary *images;/**
　　* 存放所有的下载操作(key是url，value是operation对象)
　　*/@property (nonatomic, strong) NSMutableDictionary *operations;/**
　　* 拼接Cache文件夹的路径与url最后的部分，合并成唯一约定好的缓存路径
　　*/#define CachedImageFile(url) [[NSSearchPathForDirectoriesInDomains(NSCachesDirectory, NSUserDomainMask, YES) lastObject] stringByAppendingPathComponent:[url lastPathComponent]]

//图片下载之前的查询缓存部分：
　　//先从images缓存中取出图片url对应的UIImage
　　UIImage *image = self.images[app.icon]; if (image) { //存在：说明图片已经下载成功，并缓存成功)
　　cell.imageView.image = image;
　　} else { // 不存在：说明图片并未下载成功过，或者成功下载但是在images里缓存失败，需要在沙盒里寻找对于的图片
　　// 获得url对于的沙盒缓存路径
　　NSString *file = CachedImageFile(app.icon); // 先从沙盒中取出图片
　　NSData *data = [NSData dataWithContentsOfFile:file]; if (data) { //data不为空，说明沙盒中存在这个文件
　　cell.imageView.image = [UIImage imageWithData:data];
　　} else {// 反之沙盒中不存在这个文件
　　// 在下载之前显示占位图片
　　cell.imageView.image = [UIImage imageNamed:@"placeholder"];// 下载图片
　　[self download:app.icon indexPath:indexPath];
　　}
　　}

2.3 图片的下载部分：
　　/**
　　* 下载图片
　　* @param imageUrl 图片的url
　　*/- (void)download:(NSString *)imageUrl indexPath:(NSIndexPath *)indexPath
　　{ // 取出当前图片url对应的下载操作(operation对象)
　　NSBlockOperation *operation = self.operations[imageUrl]; if (operation) return; // 创建操作，下载图片
　　__weak typeof(self) appsVc = self;
　　operation = [NSBlockOperation blockOperationWithBlock:^{ NSURL *url = [NSURL URLWithString:imageUrl]; NSData *data = [NSData dataWithContentsOfURL:url];// 下载
　　UIImage *image = [UIImage imageWithData:data]; // NSData -> UIImage
　　// 回到主线程
　　[[NSOperationQueue mainQueue] addOperationWithBlock:^{ if (image) { // 如果存在图片(下载完成)，存放图片到图片缓存字典 中
　　appsVc.images[imageUrl] = image; //将图片存入沙盒中
　　//1. 先将图片转化为NSData
　　NSData *data = UIImagePNGRepresentation (image); //2. 再生成缓存路径
　　[data writeToFile:CachedImageFile(imageUrl) atomically:YES];
　　} // 从字典中移除下载操作 (保证下载失败后， 能重新下载)
　　[appsVc.operations removeObjectForKey:imageUrl]; // 刷新当前表格，减少系统开销
　　[appsVc.tableView reloadRowsAtIndexPaths:@ [indexPath] withRowAnimation:UITableViewRowAnimationNone];
　　}];
　　}]; // 添加下载操作到队列中
　　[self.queue addOperation:operation]; // 将当前下载操作添加到下载操作缓存中 (为了解决重复下载)
　　self.operations[imageUrl] = operation;
　　}

UITableView滑动过程图片的处理

关于UITableView我们知道，tableViewCell是有重用机制的，也就是说，内存中只有当前可见的cell数目的实例，滑动的时候，新显示cell会重用被滑出的cell对象。这样就存在一个问题：
一般情况下在我们会在cellForRow方法里面设置cell的图片数据源，也就是说如果一个cell的imageview对象开启了一个下载任务，这个时候该cell对象发生了重用，新的image数据源会开启另外的一个下载任务，由于他们关联的imageview对象实际上是同一个cell实例的imageview对象，就会发生2个下载任务回调给同一个imageview对象。这个时候就有必要做一些处理，避免回调发生时，错误的image数据源刷新了UI。如第三方的SDWebImage提供的UIImageView扩展的解决方案就很实用：imageView对象会关联一个下载列表（列表是给AnimationImages用的，这个时候会下载多张图片），当tableview滑动，imageView重设数据源（url）时，会cancel掉下载列表中所有的任务，然后开启一个新的下载任务。这样子就保证了只有当前可见的cell对象的imageView对象关联的下载任务能够回调，不会发生image错乱。同时，SDWebImage管理了一个全局下载队列（在DownloadManager中）,并发量设置为6.也就是说如果可见cell的数目是大于6的，就会有部分下载队列处于等待状态。而且，在添加下载任务到全局的下载队列中去的时候，SDWebImage默认是采取LIFO策略的，具体是在添加下载任务的时候，将上次添加的下载任务添加依赖为新添加的下载任务。这样可以优化性能不至于使其出现卡顿的情况（滑动时候不进行加载）。

 [wself.downloadQueue addOperation:operation];
        if (wself.executionOrder == SDWebImageDownloaderLIFOExecutionOrder) {
            // Emulate LIFO execution order by systematically adding new operations as last operation's dependency
            [wself.lastAddedOperation addDependency:operation];
            wself.lastAddedOperation = operation;
        }

需要注意的部分

1.关于图片缓存：
下载成功，拿到了图片，就将图片添加到图片缓存中;下载失败，什么都不做（反正此时也没有图片）。在这种机制下，就没有删除缓存里某个图片项的情况，因为图片缓存永远不会出现重复添加多个相同图片的情况，缓存中只要有一张对应的图，就直接拿去用了，不会再去加载。
2.关于沙盒缓存：
同样地，对于沙盒缓存也是一个道理：有图就将其转化为NSData，写入磁盘，并对应唯一的路径，没有图就不写。所以即使是要下载相同的图片，因为当前url对应的沙盒路径已经存在文件了，所以直接拿就可以了，不会再下载。
3.关于下载操作缓存
我们需要在下载回调完成后，立即将当前的下载操作从下载操作缓存中删去（为了要避免下载失败后，无法再次下载的情况的发生）。由于将下载操作加入到下载操作缓存的时机是在下载开始的那一刻而不是下载成功的那一刻。如果在下载开始的那一刻加入到缓存中的话，这个缓存信息就包括两个情况：下载成功和下载失败：下载成功也就有相应的图片缓存和沙盒缓存，假如下载失败了，那就肯定不会有对应的图片缓存和沙盒缓存，也就肯定会来到判断当前的下载操作是否在下载操作缓存里这一步。因为没有被删去，它是存在的。导致曾经下载失败的图片永远不会再次下载。
因此，无论下载成功或是失败，在图片下载的回调里都要将当前的下载操作从下载操作队列中移走：用来保证如果下载失败了，就可以重新开启对应的下载