我讀過一些開源項目的網(wǎng)絡(luò)請求緩存的代碼，基本上都是采用在本地存文件的方式進(jìn)行緩存。如果你打算在你的項目中加入網(wǎng)絡(luò)請求的緩存，可能你并不需要自己造一個輪子，了解一下 NSURLCache 就足夠。本文為大家接收的就是ios開發(fā)中的NSURLCache相關(guān)使用，一起來看看吧。

緩存

首先， NSURLCache 提供的是內(nèi)存以及磁盤的綜合緩存機(jī)制。許多文章談到，使用NSURLCache 之前需要在 AppDelegate 中緩存空間的設(shè)置：

- (BOOL)application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions

{

NSURLCache *URLCache = [[NSURLCachealloc] initWithMemoryCapacity:4 * 1024 * 1024

diskCapacity:20 * 1024 * 1024

diskPath:nil];

[NSURLCachesetSharedURLCache:URLCache];

}

然而如果你不添加上面的代碼，并且運行如下代碼，可以看到：

print(NSURLCache.sharedURLCache().diskCapacity)//output://10000000

print(NSURLCache.sharedURLCache().memoryCapacity)//output://512000

也就是說，其實默認(rèn)就已經(jīng)設(shè)置好了512kb的內(nèi)存緩存空間，以及10MB的磁盤緩存空間?？赡苣愕拇a中并沒有寫任何與 NSURLCache 有關(guān)的東西，但其實它已經(jīng)默默的開始幫你進(jìn)行緩存了。

已經(jīng)緩存上了，但是怎么使用緩存呢？請繼續(xù)往下。

緩存策略

GET

不用多說， NSURLCache 只會對你的 GET 請求進(jìn)行緩存。

NSURLRequestCachePolicy

NSURLRequest 中有個屬性：

public var cachePolicy: NSURLRequestCachePolicy { get }

你可以通過這個屬性來設(shè)置請求的緩存策略，

public enum NSURLRequestCachePolicy : UInt {

case UseProtocolCachePolicy // 默認(rèn)值

case ReloadIgnoringLocalCacheData // 不使用緩存數(shù)據(jù)

case ReloadIgnoringLocalAndRemoteCacheData // Unimplemented

public static var ReloadIgnoringCacheData: NSURLRequestCachePolicy { get }

case ReturnCacheDataElseLoad // 無論緩存是否過期都是用緩存，沒有緩存就進(jìn)行網(wǎng)絡(luò)請求

case ReturnCacheDataDontLoad // 無論緩存是否過期都是用緩存，沒有緩存也不會進(jìn)行網(wǎng)絡(luò)請求

case ReloadRevalidatingCacheData // Unimplemented

}

其實其他幾個值都比較好理解，唯獨默認(rèn)值 UseProtocolCachePolicy 讓我不太懂。

字面上的意思是 按照協(xié)議的緩存策略進(jìn)行緩存 ，那么這是什么協(xié)議呢？ http協(xié)議。

詳細(xì)：RFC 2616, Section 13

服務(wù)器返回的響應(yīng)頭中會有這樣的字段： Cache-Control: max-age or Cache-Control: s- maxage ，通過Cache-Control 來指定緩存策略， max-age 來表示過期時間。根據(jù)這些字段緩存機(jī)制再采用如下策略：

· 如果本地沒有緩存數(shù)據(jù)，則進(jìn)行網(wǎng)絡(luò)請求。

· 如果本地有緩存，并且緩存沒有失效，則使用緩存。

· 如果緩存已經(jīng)失效，則詢問服務(wù)器數(shù)據(jù)是否改變，如果沒改變，依然使用緩存，如果改變了則請求新數(shù)據(jù)。

· 如果沒有指定是否失效，那么系統(tǒng)將自己判斷緩存是否失效。（通常認(rèn)為是6-24小時的有效時間）

其實我以前對 Cache-Control 之類的也并不太了解 T_T，自己默默的print了一下響應(yīng)頭，你可以看到：

print((responseas? NSHTTPURLResponse)?.allHeaderFields)

//響應(yīng)頭中：Cache-Control: no-cache

這也就是為什么，雖然 NSURLCache 一直在默默的緩存，但是我并沒有感受到，當(dāng)然或許你那里不一樣。這個 no-cache 就表示不緩存。

這里要額外提一句，看到網(wǎng)上有同學(xué)說自己出現(xiàn)了某個請求數(shù)據(jù)一直使用緩存，沒有被更新。這種情況可能就是服務(wù)器返回的 Cache-Control 有誤。

打開沙盒路徑下的Library/Caches 中，你可以看到緩存文件：

這可以說明存在磁盤上的數(shù)據(jù)是存在數(shù)據(jù)庫里的，性能不用擔(dān)心。打開數(shù)據(jù)庫文件就可以看到請求的數(shù)據(jù)。

在 cfurl_cache_response 表中可以看到有一個字段是 request_key ，通過里面的值可以推斷每一個response 是通過請求的 url+參數(shù) 來作為 key 儲存的。

當(dāng)然，經(jīng)過我的多次試驗，在 Cache-Control: no-cache 的情況下， NSURLCache也會進(jìn)行緩存，但是并不使用緩存數(shù)據(jù)。

總結(jié)一下：默認(rèn)情況下 NSURLCache 的緩存策略是根據(jù)http協(xié)議來的，服務(wù)器通過 Cache-Control: max-age 字段來告訴 NSURLCache 是否需要緩存數(shù)據(jù)。

緩存封裝

如果你不打算采用http協(xié)議的緩存策略，依然可以使用 NSURLCache 進(jìn)行緩存。

public funccachedResponseForRequest(request: NSURLRequest) -> NSCachedURLResponse?

你可以通過這個方法，傳入請求，來獲取緩存。 NSCachedURLResponse 保存了上次請求的數(shù)據(jù)以及響應(yīng)頭。

public funcstoreCachedResponse(cachedResponse: NSCachedURLResponse, forRequestrequest: NSURLRequest)

NSURLSessionDelegate 協(xié)議中有如下方法，可以對即將緩存的數(shù)據(jù)進(jìn)行修改，添加userInfo,在代理方法中必須調(diào)用completionHandler，傳入將要緩存的數(shù)據(jù)，如果傳nil則表示不緩存。

optionalpublic funcURLSession(session: NSURLSession,

dataTask: NSURLSessionDataTask,

willCacheResponseproposedResponse: NSCachedURLResponse,

completionHandler: (NSCachedURLResponse?) -> Void)

在 Alamofire 中可以這樣寫：

Alamofire.Manager

.sharedInstance

.delegate

.dataTaskWillCacheResponse = { (session, task, cachedResponse) -> NSCachedURLResponse? in

var userInfo = [NSObject : AnyObject]()

// 設(shè)置userInfo

return NSCachedURLResponse(response: cachedResponse.response,

data: cachedResponse.data,

userInfo: userInfo,

storagePolicy: cachedResponse.storagePolicy)

}

 

來源：伯樂在線