WKWebView緩存的那點事

WKWebView自從推出至今，一直有不斷地吐槽伴隨，誠然，WKWebView具備不少好處：速度更快、內存更少，可是它也有一些坑html

經過這幾天的研究，總結一下遇到的關於WKWebView緩存的一些事情nginx

一、二級頁面跳轉時仍然不可設置緩存策略web

用過UIWebView或WKWebView的朋友都知道，在loadRequest方法中的NSURLRequest對象，是能夠設置緩存策略的，如緩存

NSURLRequest * urlReuqest = [[NSURLRequest alloc]initWithURL:url cachePolicy:1 timeoutInterval:30.0f];
        [_webView loadRequest:urlReuqest];

咱們經過設置urlRequest的緩存策略爲 NSURLRequestReloadIgnoringLocalCacheData的操做，指定了接下來的請求必須從服務器端獲取，不能加載本地緩存

    OK，而後咱們執行了一個網頁跳轉，跳轉到了一個新的連接，這時候，咱們能夠經過代理方法指定是否讓UIWebView或WKWebView進行跳轉服務器

    可是這時候！咱們若是打印WebView的request成員變量的cachePolicy屬性，會發現它變成了NSURLRequestUseProtocolCachePolicy！也就是變成了系統默認的緩存策略url

    這樣會致使若是有一個靜態頁面，該靜態頁面進行了更改，這時候前臺已經加載過的設備，除非清除掉所有緩存，不然一直不會加載出新的頁面spa

這個問題若是由APP端進行更改的話，只能用清理所有頁面緩存的方法解決，好比後臺更新了頁面，能夠更新一個狀態時前臺執行清理緩存的方法，這樣頁面就會從新加載，出現修改後的頁面代理

另外一個解決辦法是由服務器更改，我截取了一下百度小說訪問後的response的header文件，發現這樣一個字段code

"Accept-Ranges" = bytes;
    "Cache-Control" = "max-age=0";
    Connection = "keep-alive";
    "Content-Length" = 114;
    "Content-Type" = "text/html";
    Date = "Wed, 03 Aug 2016 08:00:23 GMT";
    Etag = "\"579f13e2-72\"";
    Expires = "Wed, 03 Aug 2016 08:00:23 GMT";
    "Last-Modified" = "Mon, 01 Aug 2016 09:18:26 GMT";
    Server = nginx;

百度小說的response的header中，包含了一個Expires字段，該字段和Date，也就是訪問頁面的時間相同，這樣每一次進入小說這個頁面的時候，其實是告訴App端的WebView，緩存已通過期，須要從新加載了，因此每次進入小說頁面的時候，均可以實時更新

咱們也能夠在Nginx服務器設置一個這樣的模組，生成一個Expires字段，與訪問時間同步，這樣就能夠略過WebView的緩存了orm

2.經過JS端增長參數

公司的大牛建議我使用這種辦法，並且他不建議在APP端進行修改，因此咱們訪問了原網頁，爲跳轉的window.href增長了一個時間戳，這樣實際上和百度小說的解決辦法是同樣的，每次進入頁面時都不加載緩存並直接訪問新頁面