webview緩存頁面

❶ wkwebview的緩存設置策略

對於iOS8之後新推出的WKWebView還是有顯著的有點相對於傳統的UIWebView; 但是對於一些網頁的緩存策略就比較蒼白了，盡管UIWebView已經有很有的緩存設置策略了，但是對於剛推出的WKWbeView並沒有設置緩存的功能；

UIWebView設置緩存的方法：

不過自iOS9之後WKWebView緩存設置的API才正式推出：

types是指存在指定緩存類型的一個集合，包括：

❷ WKWebView網頁緩存刷新問題

在開發過程中遇到前端改變圖片文字，客戶端沒有實時刷新出來，抓包發現也沒有請求網頁相關介面。由於不懂後端的知識，折騰了很久，網上也查找了很多都說需要清除緩存。

這是在網上查找的iOS9以上清除緩存方法

不建議使用上述方法，會浪費用戶流量，除非用戶手動清除緩存。其實主要原因是後端網頁設置的問題，通過head請求獲取介面返回信息如下：

上面標粗的是關鍵，通過測試發現WKWebView是否通過緩存取數據還是重新請求介面取決於 Expires，如上就是緩存時效性是30分鍾，想要實時刷新，可以讓後端不返回這個欄位或者這個過期事件設置短一些，例如1分鍾。建議靜態網頁可以設置長時間，需要實時刷新的建議後端不要設置這個欄位，以免客戶端無法實時顯示。

❸ iOS webView利用NSURLProtocol實現離線緩存

        最近公司有一個需求，要對webView（UIWebView）實現緩存機制。即在無網條件下，打開webView頁面，能讀取到網頁，有網情況下，緩存未過期也可以使用本地緩存，加快用戶讀取網頁速度。

        實現緩存策略的方案有很多，為了保證有效，可控等多方面因素，本文採用NSURLProtocol來實現該需求，它的優勢很多，樓主就不再累述了。

        關於NSURLProtocol，網上給出了很多資料，但很多方案都有缺陷，包括github上有star的項目，會遇到在特定情況下，網頁載入不出來的問題，導致一直顯示空白頁。本文成功解決了這些問題，目前該項目已在線上穩定運行。

        寫這篇文章，一方面為了自己，做一些整理，另一方面如果小夥伴，遇到類似需求後，不至於走太多彎路，所謂前人栽樹，後人乘涼。廢話不多說了，直接上內容。

首先關於URL Loading System

簡單來說， URL Loading System 是iOS一系列網路請求類的集合，包括老的NSConnection和現在流行的NSURLSession，還包括一些請求認證的類，一個sessionConfig的類，還有關於處理請求緩存的類等，當然也包括NSURLProtocol類。

當我們需要攔截URL請求時，我們只要通過 - registerClass: 方法注冊我們的NSURLProtocol類，然後去重寫NSURLProtocol類中的方法，就能對我們發起的請求做處理。

NSURLProtocol 是一個抽象類，所以使用的時候必須定義一個它的子類：

需要攔截URL的控制器中注冊該類：

記得在不需要的時候，及時關閉它：

注意一點：如果是基於 NSURLSession 進行的請求，注冊的時候需要注冊到 NSURLSessionConfiguration 中：

注冊成功之後，需要子類CLURLSessionProtocol去實現抽象方法：

+ (BOOL)canInitWithRequest:(NSURLRequest*)request

此處可以攔截需要處理的URL，已經處理過的請求，需要標記請求是否被處理過，防止死循環

+ (NSURLRequest *)canonicalRequestForRequest:(NSURLRequest *)request

這個方法用來統一處理請求 request 對象的，可以修改頭信息，或者重定向。沒有特殊需要，則直接return request;

如果要在這里做重定向以及頭信息的時候注意檢查是否已經添加，因為這個方法可能被調用多次，也可以在後面的方法中做。

+ (BOOL)requestIsCacheEquivalent:(NSURLRequest*)a toRequest:(NSURLRequest*)b

判斷網路請求是否一致，一致的話使用緩存數據。沒需要就調用 super 的方法。

- (void)startLoading

這個方法作用很大，把當前請求的request攔截下來以後，在這個方法裡面對這個request做各種處理，比如添加請求頭，重定向網路，使用自定義的緩存等。

重點：需要標記已經處理過的 request：

- (void)stopLoading

取消流程

流程圖：