轉:http://www.cnblogs.com/renshengruozhiruchujian/p/5886382.html?
SDWebImage在iOS項目中是一個很常用的開源庫，而且眾所周知的是，它是基于URL作為Key來實現圖片緩存機制的。在90%左右的情況下，
圖片與URL是一一對應的，即使服務器修改了圖片也會相應的變更URL。但是在少數情況下，服務器修改了圖片后不會變更相應的URL，也就是
說圖片本身的內容變了然而它的URL沒有變化，那么按照對SDWebImage的常規使用方法的話，客戶端肯定更新不到同一URL對應到服務器已變
更的圖片內容。
基于這一現象，我們來進行分析。
客戶端第一次請求圖片時，Charles抓包得知response header里有一個名為Last-Modified、數據是時間戳的鍵值對。
客戶端第二次及以后請求圖片時，通過Charles抓包發現，服務器返回304 not modified狀態，說明服務器在接收客戶端請求后通過某種判斷邏輯得出結論：“客戶端已緩存的圖片與服務器圖片都是最新的”，那么服務器如何判斷的呢？
通過查閱HTTP協議相關的資料得知，與服務器返回的Last-Modified相對應的request header里可以加一個名為If-Modified-Since的key，value即是服務器回傳的服務端圖片最后被修改的時間，第一次圖片請求時If-Modified-Since的值為空，第二次及以后的客戶端請求會把服務器回傳的Last-Modified值作為If-Modified-Since的值傳給服務器，這樣服務器每次接收到圖片請求時就將If-Modified-Since與Last-Modified進行比較，如果客戶端圖片已陳舊那么返回狀態碼200、Last-Modified、圖片內容，客戶端存儲Last-Modified和圖片；如果客戶端圖片是最新的那么返回304 Not Modified、不會返回Last-Modified、圖片內容。
關于服務器的比較邏輯，需要強調一下。
經查資料得知，Apache比較時是看If-Modified-Since之后有沒有更新圖片，Nginx比較時是看If-Modified-Since與Last-Modified是否相等，所以對于Apache服務器環境客戶端每次都要嚴格的存儲服務器回傳的Last-Modified以便下次請求時作為If-Modified-Since的值傳給服務器，對于Nginx服務器環境客戶端不必存儲服務器回傳的Last-Modified，每次請求時只需將圖片自身的fileModificationDate作為If-Modified-Since的值傳服務器即可。在實際開發中，如果遇到明明傳了If-Modified-Since、服務器圖片也變更了、但是客戶端卻請求不到最新的圖片的情況時，那么就需要查看一下服務器對這兩個時間戳的比較邏輯。
那么，現在我們可以回到SDWebImage上來了。通過查看SDWebImageDownloader的源碼得知，它開放了一個headersFilter的block，意在讓開發者可以對所有圖片請求追加一些額外的header，這正合我意。那么我們就可以在諸如AppDelegate didFinishLaunching的地方追加如下代碼：
SDWebImageDownloader *imgDownloader = SDWebImageManager.sharedManager.imageDownloader;
imgDownloader.headersFilter? = ^NSDictionary *(NSURL *url, NSDictionary *headers) {
NSFileManager *fm = [[NSFileManager alloc] init];
NSString *imgKey = [SDWebImageManager.sharedManager cacheKeyForURL:url];
NSString *imgPath = [SDWebImageManager.sharedManager.imageCache defaultCachePathForKey:imgKey];
NSDictionary *fileAttr = [fm attributesOfItemAtPath:imgPath error:nil];
NSMutableDictionary *mutableHeaders = [headers mutableCopy];
NSDate *lastModifiedDate = nil;
if (fileAttr.count > 0) {
if (fileAttr.count > 0) {
lastModifiedDate = (NSDate *)fileAttr[NSFileModificationDate];
}
}
NSDateFormatter *formatter = [[NSDateFormatter alloc] init];
formatter.timeZone = [NSTimeZone timeZoneWithAbbreviation:@"GMT"];
formatter.locale = [[NSLocale alloc] initWithLocaleIdentifier:@"en_US"];
formatter.dateFormat = @"EEE, dd MMM yyyy HH:mm:ss z";
NSString *lastModifiedStr = [formatter stringFromDate:lastModifiedDate];
lastModifiedStr = lastModifiedStr.length > 0 ? lastModifiedStr : @"";
[mutableHeaders setValue:lastModifiedStr forKey:@"If-Modified-Since"];
return mutableHeaders;
};
然后，加載圖片的地方以前怎么寫還是怎么寫，但別忘了Option是SDWebImageRefreshCached
NSURL *imgURL = [NSURL URLWithString:@"http://handy-img-storage.b0.upaiyun.com/3.jpg"];
[[self imageView] sd_setImageWithURL:imgURL
placeholderImage:nil
options:SDWebImageRefreshCached];
經測試，服務器只修改圖片不變更URL的時候，客戶端也可以更新到最新的圖片。
從以上第一段代碼內容可以看出我采用的是與ngix服務器比較邏輯對應的代碼，BTW:我測試的服務器是又拍云，說明又拍云的比較邏輯是等與不等的關系判斷，不是大小關系的判斷。
這里順便說一下，如果服務器的環境是類似于Apache的比較邏輯時，客戶端可以把Last-Modified存放在圖片的名稱上(這需要修改SDWebImage源碼，不建議)，或者用一個plist文件存放圖片key名稱與時間的對應關系(這個不用修改源碼)。
OK，到此這次的主題已得到完美解決。
其實，在抓取服務器返回的數據包時，還發現response header中還有一個ETag，與之相對應的request header中可以追加一個
If-None-Match的key，這對header與Last-Modified、If-Modified-Since的作用是相同的，即服務器是否需要返回最新的圖片，
當然它們在服務器端的判斷邏輯應該是等與不等的判斷，Etag在客戶端的存儲同樣可以采用在plist文件中存放圖片key名稱與Etag的對應
關系。
有關Last-Modified 與 If-Modified-Since
SDWebImage load pictures and something about setting HTTP headers
重點推薦-AFNetWorking 和 SDWebImage 圖片緩存對比
重點推薦-How Does Caching Work in AFNetworking? : AFImageCache & NSUrlCache Explained
