在工作中当我们加载图片的时候会经常用到SDWebImage,但也就是仅仅那几个方法.面试过程中面试官却特别喜欢问SDWebImage的实现原理,今天呢我就SDWebImage整理下我的看法!
UIImageView+WebCache的具体实现
所有的实现最终都会调用这个方法：
实现原理
首先取消该UIView之前的下载队列:
[self sd_cancelCurrentImageLoad];
- (void)sd_cancelCurrentImageLoad {
[self sd_cancelImageLoadOperationWithKey:@"CALayerImageLoad"];
}
SD中有一个UIView的类别UIView+WebCacheOperation，给每个UIView用关联对象的方式添加了一个字典属性，用来记住此UIView的图片下载的Operation，UIView每次进行下载前先取消上一次的下载Operation，从而避免同一个UIView的并行下载。conformsToProtocol:这个方法是用来判断消息接收者是否实现了某个协议。
然后给当前要下载的图片URL设置一个key:
objc_setAssociatedObject(self,&imageURLKey,url,OBJC_ASSOCIATION_RETAIN_NONATOMIC);
这一步一般我们用不着，主要是为了下方的扩展方法用：
- (NSURL * ) sd_imageURL{
return objc_getAssociatedObject(self,&imageURLKey);
}
接着往下，做了一层url为空的保护，如果为空则用block回调一个错误。 ActivityIndicator一般说来用不上，可以略过。 如果url不为空，那么进入下载图片的操作，在下载完成的block里进行回调和调用setNeedsLayout进行布局。 需要注意的是如果是单独下载图片，请使用 SDWebImageManager进行下载，不要直接使用SDWebImageDownloader，因为它没有做缓存，把图片缓存到内存和磁盘文件是SDWebImageManager在维护。
UIButton+WebCache里边的操作是类似的，只是多一个一个状态而已。
开始分析图片下载过程
(1)先看下SDWebImageOptions的枚举参数
SDWebImageRetryFailed系统默认一张图片下载失败后，会把该图片加入失败的黑名单里，如果不传递该option，则下次下载同样的url时直接返回失败。如果传入该option，那么即使该图片之前下载失败了，也会再次进行下载.
SDWebImageLowPriority，表示低优先级，例如当scrollView在减速时会延迟下载。
SDWebImageHighPriority，表示高优先级，会把该次下载操作移动到下载队列的最前面。
SDWebImageCacheMemoryOnly， 表示下载的图片只缓存到内存，不进行写文件，不做磁盘缓存。
SDWebImageProgressiveDownload， 表示渐进式的下载和显示，SD默认是把图片全部下载后再显示出来，但是传入该参数可以做到下载一部分图片后先显示这一部分，也就是边下载边显示，效果上就是通常的一个人体的照片，先看到头，再看到肩膀，最后看到腿。当然这种下载图片的方式需要服务器的支持才行。
SDWebImageRefreshCached传入该option，则即使本地已经缓存了该图片，那么仍然会发起网络请求跟服务器通信，然后服务器的返回参数决定是否要再次下载该url表示的图片。同时缓存的方式改成使用NSURLCache，另如果图片命中缓存且远端图片同时有更新的话，会回调两次completionBLock。该参数主要是用于应对同一个url，但是图片会更改的情况。
SD的源码中主要是有以下几个影响： 命中缓存后先回调block，然后继续去下载图片，注意看这里在回调block之后并没有return，而是让代码往下走。
同时如果图片命中NSURLCache的缓存，不进行回调。注意此处如果命中缓存则downloadImage肯定是空的。
SDWebImageContinueInBackground这个最简单了，字面意思就是APP进入后台后继续下载图片，只不过其代码实现略复杂，臣妾看的也不是太懂，故略过不表。
SDWebImageHandleCookies缓存相关，HTTP的缓存不大懂，略过。
SDWebImageAllowInvalidSSLCertificates跟图片下载权限和服务器认证相关，一般用不上该option，具体原理不明，略过。。。
SDWebImageDelayPlaceholder这个选项一般也不用，如果设置的话，placeholder的UIImage就没效果了。
SDWebImageTransformAnimatedImage字面上看跟gif动图相关？不懂略过。
SDWebImageAvoidAutoSetImage这个选项没啥营养，就是给你一个机会在下载完成的时候可以对原图片做些操作，系统就不自动帮你设置了，而是直接回调block.
(2)关于SDWebImageDownloader这个类，其实就是个实际去下载的类，它的那些Option跟SDWebImageManager里的Option是类似的，只不过SDWebImageManager是面向用户的，封装了查找缓存的一些功能，更友好一些而已。
缓存部分SDImageCach
源码比较简单，提几个关键点即可。
1.把图片的url当成key，然后转成一个唯一的字符串，来作为存储本地磁盘的文件名
2.所谓内存缓存，其实就是一个 NSCache，相当于可变字典，只不过多了cost参数而已
3.查找缓存的过程就是，先查内存里(NSCache)有没有，有就返回，没有就继续查磁盘文件有没有，有的话先放到内存里，然后返回。用一个单独的队列来进行磁盘读写。
4.缓存自动清理的时机 无论是APP退到后台，或者APP被直接杀掉，都会进行图片的清理
该方法里会检查图片的有效期，默认是7天，如果过期则删除。 用到了NSURLContentModificationDateKey这个key，表示文件的修改时间，多数情况下都是图片文件的创建时间，因为基本下载好了以后就不会去修改了。
另如果你设置了最大的图片存储空间，那么系统也会在同一时间点做检查并清理。即使未过期，也会清理一些，按照文件创建的时间来排序做清理，更早创建的优先被清理。比较有意思的就是，清理工作会持续到图片只占你设定值的一半。
5.关于图片的解码，从磁盘中读取时，以及从网络上下载完成图片时，都会先解码再返回
解码函数可调用多次，只有第一次有效，解码一次之后anyAlpha的值就为YES，所以解码函数调用多次也无太大影响
另外SD的对图片的回调有UIImage和NSData两个参数，也就是说，UIImage是解码之后的图片，但是格式为NSData的imageData却是下载下来的图片原始数据。但是由于作者对方法封装的原因，使用SDWebImageManager的回调确实没有imageData的, 而使用SDWebImageDownloader的回调block是有NSData的参数回调的. SD存磁盘其实是拿图片的NSData的数据去存储的，并没有直接把解码的UIImage图片拿去存盘，所以在读磁盘文件时才需要先解码再返回了.
其实说这么多看着很费劲,一张图就可以解决了
