无论是社交类的网络相册、电商类的商品清单、还是电子书城的书架等应用场景，大量图片的下载都是必备的应用需求。
在iOS系统中，相比 NSURLConnection ，NSURLSession 提供了一套更优秀的网络处理解决方案，并且使用的接口更加简单，对开发者更加友好。那么 NSURLSession 能胜任多任务下载吗？
NSURLSession 多任务的局限性
NSURLSession 本身能处理多任务下载， 我们可以使用dataTaskWithURL方法为每个URL发起请求:
NSURLSession *session = [NSURLSession sharedSession];
[[session dataTaskWithURL:[NSURL URLWithString:londonWeatherUrl]
completionHandler:^(NSData *data,
NSURLResponse *response,
NSError *error) {
NSLog(@"Handle response"); // 断点位置
}] resume];
可见，NSURLSession 内部开辟NSOperationQueue 来处理多任务，NSURLSession 的 block 使用简单，但能实现的功能有限，所以，要想控制下载的过程，就必须使用代理：
// NSURLSessionDataDelegate
- URLSession:dataTask:didReceiveResponse:completionHandler: //接收到服务器的响应
- URLSession:dataTask:didReceiveData: //接收到服务器的数据
- URLSession:dataTask:willCacheResponse:completionHandler: //指定缓存数据
// NSURLSessionDataDelegate
- URLSession:task:didCompleteWithError: //下载完成
- URLSession:task:willPerformHTTPRedirection:newRequest:completionHandler: //重定向
然而，对一个NSURLSession而言，所有任务都会走同一个代理方法，导致代理中需要编写许多区分不同任务的代码，为防止公共属性访问冲突，需要对处理过程加锁，这导致了性能的下降；
当然，有人会说，每个任务用不同的 NSURLSession 就好了，诚然，这可以解决代理复用的问题，但正如前面提到的，每个NSURLSession自己会维护一个NSOperationQueue，这种处理方法相当于为每个下载任务开辟了一个NSOperationQueue，却只放入一个操作对象，不但代码非常别扭，在大量任务时会增加系统的开销。
那么，该如何有效地将任务分开，分别控制下载进程，优雅的处理多任务下载呢？
SDWebImage的解决方法
SDWebImage 作为GitHub 获得Star 20K+ 的优秀库，在实现了大量图片异步下载、缓存、解码一系列功能的同时，提供了简洁的使用接口，达到了优异的性能，它内部也是使用NSURLSession下载图片的，那么它是如何控制NSURLSession的呢？让我们到SDWebImage的源码中一探究竟。
下载相关的类
SDWebImage 中负责下载的主要有两个类：
- SDWebImageDownloader 封装了 NSURLSession ，同时作为 Session 的代理，并初始化了一个 NSOperationQueue ，管理所有的下载过程。
- SDWebImageDownloaderOperation 实现了一张图片的整个下载过程，通过 task 启动下载任务，开辟新线程处理下载到的图片等等。
它们的关系如下图，实心箭头表示持有关系，虚线表示间接使用：
下载的主要过程解析
下载入口
下载的过程首先从 Downloader 的 downloadImage 方法开始：
- (nullable SDWebImageDownloadToken *)downloadImageWithURL:(nullable NSURL *)url
options:(SDWebImageDownloaderOptions)options
progress:(nullable SDWebImageDownloaderProgressBlock)progressBlock
completed:(nullable SDWebImageDownloaderCompletedBlock)completedBlock
若URL未被下载过，一个 SDWebImageDownloaderOperation 就会被创建，并添加到 downloadQueue 中，由队列负责执行，这时，还没实际下载，只有Operation 被提交执行，才会开始真正的下载。
启动下载
接着来到 SDWebImageDownloaderOperation 中看看下载的启动 ：
下载的启动过程放在了 start 方法中，而不是 main 方法，这是因为main方法执行完成后，会自行退出，无法控制线程的生命周期。
在 star 方法中，一个 NSURLSessionTask 实例被创建，并通过以下方法启动起来：
[self.dataTask resume];
这时，实际的下载过程是在NSURLSession的队列中进行的，SDWebImageDownloaderOperation 的线程处于【等待】的状态中。
下载完成
下载完成后，在 SDWebImageDownloader 中获得NSURLSessionTaskDelegate 回调：
- (void)URLSession:(NSURLSession *)session task:(NSURLSessionTask *)task didCompleteWithError:(NSError *)error
在该代理方法中，通过遍历 self.downloadQueue.operations 查询 NSURLSessionTask 对应的 SDWebImageDownloaderOperation，调用 Operation 实现的同名代理方法URLSession:dataTask:didReceiveResponse:completionHandler:，将执行的过程切回到 Operation 中，在这里完成最后的收尾工作，调用
[self done];
需要注意的是，以下属性的 setter 方法：
- (void)setFinished:(BOOL)finished {
[self willChangeValueForKey:@"isFinished"];
_finished = finished;
[self didChangeValueForKey:@"isFinished"];
}
- (void)setExecuting:(BOOL)executing {
[self willChangeValueForKey:@"isExecuting"];
_executing = executing;
[self didChangeValueForKey:@"isExecuting"];
}
自定义实现并发操作对象时，必须覆盖这些属性的实现，以便可以返回操作的状态，并且必须为这些键路径生成KVO通知（即setter中的willChangeValueForKey和didChangeValueForKey），否则会造成 NSOperation 无法退出。
到这里就将一张图片下载的主要过程分析完了，其他网络错误处理、缓存处理过程，可以沿着这个流程进一步加以分析，这里限于篇幅就不展开了。
NSOperation vs GCD
这里补充一点的是，在 Operation 过程中，切到主线程发通知、调用解码器等，都使用GCD开辟新线程，从而释放出 NSURLSession 的下载线程，这是比较有意思的部分，NSOperation 内部的具体实现是用GCD的，体现了NSOperation 和 GCD 的区别与联系：
- NSOperation 用于控制复杂过程的生命周期；
- GCD 用于快速执行异步操作；
- 两者都是启用多线程的手段，可以协同工作。
总结
SDWebImage的下载方案中的优点：
- 异步下载图片，开辟多个线程处理各阶段过程，使主线程不卡顿
- 灵活使用 NSOperation 和 GCD，使得代码条理清晰