SDWebImage学习中的疑惑及总结

1、很多地方都调用了 scaledImageForKey方法，比如根据key从磁盘缓存中获取图片后已经是一张UIImage了，进一步调用了scaledImageForKey，原因是？

命名图片时候以xxx@2x.png、xxx@3x.png结尾，但在创建Image时并不需在后面添加倍数，只需调用[UIImage imageNamed:@"xxxx"]即可，因为Xcode会帮我们根据当前分辨率自动添加后缀。
eg:如果你有一张5050的二倍图片，当你以[UIImage imageNamed:@"xxxx@2x"]的方法加载图片的时候，你会发现图片被拉伸了，它的大小变为100100，这是因为Xcode会自动添加二倍图后缀，以xxx@2x@2x去查找图片，当它找不到的时候就把xxx@2x图片当做一倍图片处理，所以图片的size就变大了，而ScaledImageForKey方法就是解决这件事情，以防url里面包含@"2x"、@"3x"等字符串，从而使图片size变大。

2、 SDWebImageDownloaderOperation中申明两个

// This is weak because it is injected by whoever manages this session. If this gets nil-ed out, we won't be able to run
// the task associated with this operation
@property (weak, nonatomic) NSURLSession *unownedSession;
// This is set if we're using not using an injected NSURLSession. We're responsible of invalidating this on
@property (strong, nonatomic) NSURLSession *ownedSession;

不太了解其中使用的区别？

- (id<SDWebImageOperation>)downloadImageWithURL:(NSURL *)url options:(SDWebImageDownloaderOptions)options progress:(SDWebImageDownloaderProgressBlock)progressBlock completed:(SDWebImageDownloaderCompletedBlock)completedBlock；

方法中初始化SDWebImageDownloaderOperation里面的几个GCD，注意理解为什么使用同步、异步操作，及栅栏块。

1D91B78F-BCB6-41F0-9E80-45BB3D3086DD.png

4.图片的读写操作、解压缩都比较消耗系统资源，项目中在- (NSOperation *)queryDiskCacheForKey:(NSString *)key done:(SDWebImageQueryCompletedBlock)doneBlock；方法中根据key从缓存中查询获取图片时，通过异步操作如果内存的缓存中没有该图片，则对该图片进行内存缓存的写操作，使用了自动释放池。其他地方为啥没有采用？比如解压图片方法decodedImageWithImage。

原来在 decodedImageWithImage方法中已使用自动释放池。使用该方法批量下载图片时，@autoreleasepool会释放bitmaps上下文、用到的变量来释放内存。iOS7下，内存报警告时，不要忘记调用[[SDImageCache sharedImageCache] clearMemory];
图片在UIImageView上面显示的时候需要解压，而这个解压操作是在主线程里面进行的，比较耗时，这样就会产生延时效果，在后台解压能够解决这一问题。当你用 UIImage 或 CGImageSource 的几个方法创建图片时，图片数据并不会立刻解码。图片设置到 UIImageView 或者 CALayer.contents 中去，并且 CALayer 被提交到 GPU 前，CGImage 中的数据才会得到解码。这一步是发生在主线程的，并且不可避免。如果想要绕开这个机制，常见的做法是在后台线程先把图片绘制到 CGBitmapContext 中，然后从 Bitmap 直接创建图片。

5.用SDWebImageDownloaderOperation下载回来的图片为什么要进行decoder处理，即调用方法 decodedImageWithImage？

下载一张图片所需消耗的“空间”（内存）包括3个方面：
磁盘空间或者通过internet传输所消耗的空间
解压缩空间，通常是长X宽X高X4字节（RGBA）
当显示在一个view中时，view本身也需要空间来存储layer

将一张图片显示到屏幕上所消耗的“时间”包括3个方面：
从磁盘上alloc/init UIImage的时间
解压缩的时间（这个部分所用时间占比非常大）
将解压缩后的比特转换成CGContext的时间，通常需要改变尺寸，混合，抗锯齿工作

由于UIImage的imageWithData函数是每次画图的时候才将Data解压成ARGB的图像，所以在每次画图的时候，会有一个解压操作，这样效率很低，但是只有瞬时的内存需求。为了提高效率通过SDWebImageDecoder将包装在Data下的资源解压，然后画在另外一张图片上，这样这张新图片就不再需要重复解压了。这种做法是典型的空间换时间。

6、下载图片时，通过委托方法 - (void)URLSession:(NSURLSession *)session dataTask:(NSURLSessionDataTask *)dataTask didReceiveData:(NSData *)data；逐步接收图片的数据，每接收一部分都进行了解压操作在进行回调处理，为什么不用一个变量保存解压后的图片数据，而再次在 NSURLSessionTaskDelegate代理中的 - (void)URLSession:(NSURLSession *)session task:(NSURLSessionTask *)task didCompleteWithError:(NSError *)error；方法再次对图片 imageData进行解压？

边下载边解压，是为了支持 SDWebImageProgressiveDownload模式；

7、具有alpha通道的图片为什么不需要进行解压操作而直接返回？
具有alpha通道，肯定就是PNG图片，PNG解压比JPG简单很多。当 Xcode 优化一个 PNG 文件的时候，它将 PNG 文件变成一个从技术上讲不再是有效的PNG文件。但是 iOS 可以读取这种文件，并且这比解压缩正常的 PNG 文件更快。

8、在NSURLSessionTaskDelegate委托的方法中- (void)URLSession:(NSURLSession *)session task:(NSURLSessionTask *)task didCompleteWithError:(NSError *)error；动画图片为什么不用decode操作？

• 大致结构及流程

框架结构 流程图

1、入口 setImageWithURL:placeholderImage:options: 会先把 placeholderImage 显示，然后 SDWebImageManager 根据 URL 开始处理图片。
2、进入 SDWebImageManager-downloadWithURL:delegate:options:userInfo:，交给 SDImageCache 从缓存查找图片是否已经下载 queryDiskCacheForKey:delegate:userInfo:.
3、先从内存图片缓存查找是否有图片，如果内存中已经有图片缓存，SDImageCacheDelegate 回调 imageCache:didFindImage:forKey:userInfo: 到 SDWebImageManager。
4、SDWebImageManagerDelegate 回调 webImageManager:didFinishWithImage: 到 UIImageView+WebCache 等前端展示图片。
5、如果内存缓存中没有，生成 NSInvocationOperation 添加到队列开始从硬盘查找图片是否已经缓存。
6、根据 URLKey 在硬盘缓存目录下尝试读取图片文件。这一步是在 NSOperation 进行的操作，所以回主线程进行结果回调 notifyDelegate:。
7、如果上一操作从硬盘读取到了图片，将图片添加到内存缓存中（如果空闲内存过小，会先清空内存缓存）。SDImageCacheDelegate 回调 imageCache:didFindImage:forKey:userInfo:。进而回调展示图片。
8、如果从硬盘缓存目录读取不到图片，说明所有缓存都不存在该图片，需要下载图片，回调 imageCache:didNotFindImageForKey:userInfo:。
9、共享或重新生成一个下载器 SDWebImageDownloader 开始下载图片。
10、图片下载由 NSURLConnection 来做，实现相关 delegate 来判断图片下载中、下载完成和下载失败。
11、connection:didReceiveData: 中利用 ImageIO 做了按图片下载进度加载效果。
12、connectionDidFinishLoading: 数据下载完成后交给 SDWebImageDecoder 做图片解码处理。
13、图片解码处理在一个 NSOperationQueue 完成，不会拖慢主线程 UI。如果有需要对下载的图片进行二次处理，最好也在这里完成，效率会好很多。
14、在主线程 notifyDelegateOnMainThreadWithInfo: 宣告解码完成，imageDecoder:didFinishDecodingImage:userInfo: 回调给 SDWebImageDownloader。
15、imageDownloader:didFinishWithImage: 回调给 SDWebImageManager 告知图片下载完成。
16、通知所有的 downloadDelegates 下载完成，回调给需要的地方展示图片。
17、将图片保存到 SDImageCache 中，内存缓存和硬盘缓存同时保存。写文件到硬盘也在以单独 NSInvocationOperation 完成，避免拖慢主线程。
18、SDImageCache 在初始化的时候会注册一些消息通知，在内存警告或退到后台的时候清理内存图片缓存，应用结束的时候清理过期图片。
19、SDWI 也提供了 UIButton+WebCache 和 MKAnnotationView+WebCache，方便使用。
20、SDWebImagePrefetcher 可以预先下载图片，方便后续使用。