轉載

http://blog.handy.wang/blog/2016/01/29/sdwebimagehuan-cun-zhi-tu-pian-urlbu-bian/

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的對應
關係。