阅读别人的代码，主要目的当然是为了学习。如果直接下载源码，然后像教科书一样一个一个文件的阅读，常常会遇到这两个问题：1、作者为什么要用方案A，好像方案B也可以啊；2、我艹，这坨垃圾代码，换我1/10就搞定了。
罗马非一日建成，开源代码也不是一天就写成这个样子。忽略过程而只专注结果，往往会错过很多东西。于是，我开始换另一种阅读源码的方式：从提交日志追溯代码的更迭。
1
第一个版本的SDWebImage（那个时候还不是这个名字）只有4个文件，3个类组成。一个是缓存，包含内存缓存和磁盘缓存。内存缓存用的是NSMutableDictionary，磁盘则是文件，以url的md5作为文件名。清理机制很简单，收到内存警告时，就清掉内存缓存，磁盘缓存是7天。看文件最后修改时间，如果大于7天就删除，时机是程序退出前（监听UIApplicationWillTerminateNotification）。
第二个UIImageView的子类，设置一个URL。如果url在缓存中，就set image；如果没有，创建一个NSOperation下载。
第三个就是下载Operation。下载方式比较简陋，用的是-[NSData initWithContentsOfURL:]
2
作者加了一个Motivation提到，加载远程图片以前用的方法都是NSURLConnection的异步模式（sendAsynchronousRequest）。当时他用的是Three20，发现它的速度比Youtube慢了10倍。后来发现，原来NSURLConnection用的是epoll并且工作在主线程上，自然速度就跟不上。（epoll强调的是高并发，对单个连接而言，同步模式速度更快）
3
很贴心的把磁盘缓存的目录从NSDocumentDirectory挪到了NSCachesDirectory。
4
调用方式把子类方式改为Category，而把原来的子类改为加到UIImageView的第一个subview中。
5
可能觉得这种加到UIImageVIew第一个subview的hack方式不太好，而且有同一个url重复下载问题。于是乎搞了一个SDWebImageManager的单例。
然后，1.0就这么发布了。
6
将NSData下载图片放送改为NSURLConnection的同步模式，主要目的是让每次下载都强制更新，而不是用系统缓存。
7
作者有抛弃了NSOperation，改为NSURLConnect异步模式。原因嘛，NSOperation太重太慢（我觉得主要问题还是它对并行处理不好，如果前面一个连接被服务器stuck了，后面的就一直处于等待中）。作者找到了sendAsynchronousReqest慢点原因，connect默认塞到了NSEventTrackingRunLoopMode中，这是负责处理UI事件的runloop。改为塞到其它runloop就没这个问题了
NSURLRequest *request = [[NSURLRequest alloc] initWithURL:url cachePolicy:NSURLRequestReloadIgnoringLocalCacheData timeoutInterval:15];
self.connection = [[[NSURLConnection alloc] initWithRequest:request delegate:self startImmediately:NO] autorelease];
// Ensure we aren't blocked by UI manipulations (default runloop mode for NSURLConnection is NSEventTrackingRunLoopMode)
[connection scheduleInRunLoop:[NSRunLoop currentRunLoop] forMode:NSRunLoopCommonModes];
[connection start];
附带一个好处是，下载到一半可以cancel
8
新增SDWebImageDecoder。后台IO线程先decode图片后，再通知主线程显示。decode不是什么特别的技术，如果图片很多，还是很有必要的。
9
内存cache之前，检查一下当前剩余内存。小于12M就清掉老的Cache。
不过后来用NSCache缓存内存图片，去掉了12M限制。
10
新加参数SDWebImageRefreshCached，对于头像之类的图片很适用。它先还是会用SDWebImage的cache查找，同时仍然发起一个HTTP请求，只不过这个NSURLRequest启用了NSURLRequestUseProtocolCachePolicy，由系统帮我们处理缓存，抓包后发现，request自动加上了If-Modified-Since，并返回了304错误。
SDWebImage的缓存策略从发布起到现在没有太大改变，依然是URL为key，内存＋本地文件缓存，重点提高了对外扩展接口，多格式支持和图片解压。LUR提了好多年，换NSCache后，估计不会针对性的对其实现了。针对小文件，用数据库做缓存；目录图片太多时，分目录保存，这些我觉得都可以加上。
