1. 程式人生 > >UIWebview使用快取並且保證實時性(iOS web資源快取解決方案、非同步後臺更新。離線快取)

UIWebview使用快取並且保證實時性(iOS web資源快取解決方案、非同步後臺更新。離線快取)

webview快取策略的介紹

使用webview載入頁面的時候,最理想的情況是: 資原始檔沒有更新,就只加載快取檔案。如果有更新,則第一時間使用新的檔案。

UIWebview中提供的快取策略

  • NSURLRequestUseProtocolCachePolicy 快取策略定義在 web 協議實現中,用於請求特定的URL。是預設的URL快取策略。
  • NSURLRequestReloadIgnoringLocalCacheData 從服務端獲取資料,忽略本地快取
  • NSURLRequestReloadIgnoringLocalAndRemoteCacheData //原始檔註釋中寫到沒有實現
  • NSURLRequestReloadIgnoringCacheData 被NSURLRequestReloadIgnoringLocalCacheData替換了
  • NSURLRequestReturnCacheDataElseLoad 已經存在的快取資料用於請求返回,不管它的過期日期和已經存在了多久。如果沒有請求對應的快取資料,從資料來源讀取
  • NSURLRequestReturnCacheDataDontLoad 已經存在的快取資料用於請求返回,不管它的過期日期和已經存在了多久。如果沒有請求對應的快取資料,不要去資料來源讀取,該請求被設定為失敗,這種情況多用於離線模式
  • NSURLRequestReloadRevalidatingCacheData //原始檔中寫到沒有實現

其中我覺得最接近理想狀態的就是預設的快取策略了-NSURLRequestUseProtocolCachePolicy。 這個快取策略的快取模式,經過探究,如下圖所示: 

預設快取策略的流程圖 我們會遇到兩個問題:     1.在“是否過期”這個判斷的地方,倘若後端開發人員沒有設定過期時間,那麼將會導致立馬過期,即使有快取的情況下,都會無法載入資源。儘管伺服器資源沒有更新。     2.當網路差的時候,快取已經過期,則向伺服器發出詢問是否有更新,通常返回304的狀態碼的情況比較多,返回304則又會使用快取。而這種情況在網路差的時候,發出請求這個部分時間非常的耗時。也就容易造成白屏了。

application cache

這個是h5中用到的一個快取方式。使用manifest配置檔案,告知客戶端哪些需要更新,哪些不需要更新。使用這種方式,需要枚舉出所有需要快取的配置檔案,每次開啟頁面都要去請求配置檔案是否有更新,如果配置檔案有更新,則更新配置檔案中列出的資原始檔。 缺點:多個頁面引用同一個js,將會快取兩份js檔案。需要服務端配合 優點:快速的展現快取的內容,後臺去更新快取,下次再開啟該資源時將使用最新的。

自定義一種較為優的快取策略

既可以快速的載入快取的內容(可以離線載入),又可以實時的更新。

跟application cache的方式差不多,快速載入快取,後臺去非同步更新,但是沒有它的缺點。不會快取多份檔案,不需要服務端配合,意味著不需要改變服務端的東西。客戶端開發人員就可以搞定。成本很小。快速又節約流量。 自定義cache策略圖

如上圖所示,發出網路請求後,會優先載入本地的快取內容。使得資源得以實施的載入,杜絕白屏現象。然後非同步去更新快取。 這裡的快取策略依賴於自己的設定,使用webview自帶的快取策略即可。然後根據 當前時間 - 上一次更新時間 > 設定更新間隔時間按 這個條件來選擇是否更新。     這樣做的好處是防止白屏,又能實時更新。

附上github demo的地址:demo地址
使用方法:

pod 'JWNetAutoCache'

或者直接下載檔案,將JWNetAutoCache目錄下的兩個檔案引入。
在需要開啟的時候呼叫

[JWCacheURLProtocol startListeningNetWorking];

使用結束後呼叫

[JWCacheURLProtocol cancelListeningNetWorking];

程式碼侵入性小。可以隨時的移除。快取還是使用原來系統的方式來進行儲存。移除後無感知。