摘要:原文聊一聊應用緩存導讀是提供的一種應用緩存機制基于它應用可以實現離線訪問為此瀏覽器還提供了應用緩存的雖然的技術已被標準廢棄但這不影響我們嘗試去了解它也正是因為的應用緩存機制如此誘人餓了么和郵箱等都還在使用著它描述對熟悉的同學可以跳過此
原文: 聊一聊H5應用緩存-Manifest
導讀Manifest 是 H5提供的一種應用緩存機制, 基于它web應用可以實現離線訪問(offline cache). 為此, 瀏覽器還提供了應用緩存的api--applicationCache. 雖然manifest的技術已被web標準廢棄, 但這不影響我們嘗試去了解它. 也正是因為manifest的應用緩存機制如此誘人, 餓了么 和 office 365郵箱等都還在使用著它!
描述對manifest熟悉的同學可以跳過此節.
鑒于manifest應用緩存的技術, 我們可以做到:
離線訪問: 即使服務器掛了, 或者沒有網絡, 用戶依然可以正常瀏覽網頁內容.
訪問更快: 數據存在于本地, 省去了瀏覽器發起http請求的時間, 因此訪問更快, 移動端效果更為明顯.
降低負載: 瀏覽器只在manifest文件改動時才去服務器下載需要緩存的資源, 大大降低了服務器負載.
manifest緩存的過程如下(來自網絡):
支持性主流瀏覽器都支持manifest應用緩存技術. 如下表格:
IE | Edge | Firefox | Chrome | Safari | Opera | ios | Android |
---|---|---|---|---|---|---|---|
10+ | 12+ | 3.5+ | 4+ | 4+ | 11.5+ | 7.1+ | 2.3+ |
H5標準中, Offline Web applications 部分有如下描述:
This feature is in the process of being removed from the Web platform. (This is a long process that takes many years.) Using any of the offline Web application features at this time is highly discouraged. Use service workers instead.?[SW]
因此后續我將在其他文章中繼續介紹 service workers, 本篇繼續關注manifest.
如何開啟應用緩存manifest使用緩存清單進行管理, 緩存清單需要與html標簽進行關聯. 如下:
...
在html標簽中指定manifest文件, 便表示該網頁使用manifest進行離線緩存. 該網頁內需要緩存的文件列表需要在 test.appcache 文本文件中指定.
manifest緩存清單就像寫作文一樣, manifest采用經典的三段式. 分別為: CACHE, NETWORK 和 FALLBACK. 如下, 先看一個栗子?:
CACHE MANIFEST # v1.0.0 content.css NETWORK: app.js FALLBACK: /other 404.html
其中第一行必須以 CACHE MANIFEST 開頭, 后可跟若干字符注釋, 注釋從#號開始. 跟在 CACHE MANIFEST 行后的文件, 每行列出一個, 這些文件是需要緩存的文件. 因此 content.css 會被緩存, 不需要訪問網絡.
第二段內容以 NETWORK: 開始, 跟在該行后的文件表示需要訪問網絡. 如: app.js 將直接從網絡上下載, 并不走manifest cache, 如果除了第一段中緩存的文件以外, 其他文件都從網絡上獲取, 那么此時可將 app.js 改為 * (通配符).
第三段內容以 FALLBACK: 開始, 跟在該行后的文件表示會有一個替代方案. 如: 當訪問 /other 路徑時, 如果訪問失敗, 那么將自動加載 404.html 作為替代.
manifest緩存狀態每個manifest緩存都有一個狀態, 標示著緩存的情況. 一份緩存清單只有一個緩存狀態, 即使它被多個頁面引用. 以下是各個緩存狀態:
UNCACHED(未緩存): 表明應用緩存對象還沒有初始化完成.
IDLE(空閑): 應用緩存并未處于更新狀態.
CHECKING(檢查): 正在檢查是否存在更新.
DOWNLOADING(下載): 清單更新后, 重新下載全部資源到臨時緩存中.
UPDATEREADY(更新就緒): 新版本的緩存下載完成, 全部就緒, 隨即觸發事件 updateready.
OBSOLETE(廢棄): 應用緩存已被廢棄.
上述緩存狀態常量依次取值0, 1, 2, 3, 4, 5.
applicationCacheapplicationCache是操作應用緩存的瑞士軍刀, 也是唯一的一把刀.
首先我們來獲取該對象.
//webview下 var cache = window.applicationCache; //shared worker中 var cache = self.applicationCache;
以下是其屬性和方法介紹(大神請繞過):
status: 返回當前頁面的應用緩存的狀態, 通常開啟應用緩存的頁面可能返回1, 其他頁面則返回0.
update(): 手動觸發應用緩存的更新.
(1) 若有更新, 則依次觸發①檢查事件(Checking event), ②下載事件(Downloading event), ③下載進度事件(Progress event), ④更新完成事件(UpdateReady event);
(2) 若無更新, 則依次觸發①檢查事件(Checking event), ②無更新事件(NoUpdate event);
(3) 在未開啟應用緩存的頁面調用將拋出Uncaught DOMException 錯誤.
update() 方法通常在長時間不關閉的頁面使用, 比如說郵箱應用, 用于定期檢測可能的更新.
abort(): 取消應用緩存的更新. 可用于節省有限的網絡帶寬.
swapCache(): 如果存在一個更新版本的應用緩存, 那么它將切換過去, 否則將拋出 Uncaught DOMException 錯誤. 通常, 我們會在updateready事件觸發之后手動調用swapCache()方法, swapCache的切換只對后續加載的緩存文件有效, 已經加載成功的資源并不會重新加載.
那么如何利用好上述api更新一個頁面的應用緩存呢? 別急, Beginner"s Guide to Using the Application Cache 一文中提供了如下的樣板方法:
// Check if a new cache is available on page load. window.addEventListener("load", function(e) { window.applicationCache.addEventListener("updateready", function(e) { if (window.applicationCache.status == window.applicationCache.UPDATEREADY) { // Browser downloaded a new app cache. // Swap it in and reload the page to get the new hotness. window.applicationCache.swapCache(); if (confirm("A new version of this site is available. Load it?")) { window.location.reload(); } } else { // Manifest didn"t changed. Nothing new to server. } }, false); }, false);manifest緩存獨立性
manifest的緩存和瀏覽器默認的緩存是兩套機制, 相互獨立, 并且不受瀏覽器緩存大小限制(Chrome下測試結果).
各個manifest文件的緩存相互獨立, 各自在獨立的區域進行緩存. 即使是緩存同一個文件, 也可能由于緩存的版本不一致, 而造成各個頁面資源不一致.
manifest緩存規則遵循全量緩存的規律. 即: manifest文件改動后, 將重新緩存一遍所有的文件(包括html本身和動態添加的需要緩存的文件,即使緩存列表中沒有該html). 第一次緩存過程中如果出現緩存失敗的文件, 那么, 第二訪問, 又將重新緩存一遍所有的文件. 以此類推.
manifest文件本身不能寫進緩存清單, 否則連同html和資源在其緩存失效之前, 將永遠不能獲得更新.
即使manifest文件丟失, 緩存依然有效. 不過從此以后, 引入該manifest的html, 將永遠不能獲得更新.
webview的緩存現象通常, webview的緩存有如下三種現象:
普通網頁(無manifest文件), 不受manifest緩存影響, 緩存只走 http cache.
包含manifest文件的網頁, 緩存文件只受manifest緩存影響(只有manifest文件改變時才會更新緩存資源), 緩存資源完全與 http cache 無關, 但是 NETWORK 段落后需要訪問網絡的文件, 將繼續走 http cache.
webview直接加載manifest緩存過的文件時, 優先加載第一個manifest緩存的該文件, 如果沒有找到manifest緩存, 那么它將自動尋找 http cache 或者 在線加載.
最佳實踐通常只使用一個manifest文件, 并保證緩存的文件盡可能的少, 以減小manifest每次更新清單中文件所耗費的時間和流量.
如果一定要使用兩個及以上manifest文件, 緩存文件請盡量不要相同.
如果以上兩條都不能保證, 那么, 請保證盡可能在manifest緩存的狀態更新時, 主動去刷新網頁.(此時并不能保證不同網頁之間同一個緩存文件版本一致)
具體落地步驟如果緩存的文件需要加參數運行, 建議將參數內容加到hash中, 如:cached-page.html#parameterName=value
manifest 的引入可以使用絕對路徑或者相對路徑, 如果你使用的是絕對路徑, 那么你的manifest文件必須和你的站點處于同一個域名下.
manifest文件你可以保存為任意的擴展名, 但是響應頭中以下字段須取以下定值, 以保證manifest文件正確被解析, 并且它沒有http緩存.
Content-Type: text/cache-manifest Cache-Control: max-age=0 Expires: [CURRENT TIME]如何更新緩存
更新manifest文件后, webview將自動更新緩存.
js更新緩存(手動觸發manifest更新):?window.applicationCache.update();
其他chrome瀏覽器下通過訪問?chrome://appcache-internals/?可以查看緩存在本地的資源文件.
另外, 除了本文參考的一篇 MDN 的文章以及 HTML5 Rocks的 Beginner"s Guide to Using the Application Cache 一文, 還有如下三個鏈接可供您比較閱讀, 謝謝.
Cache manifest in HTML5?on Wikipedia
Offline Web Applications?W3C Working Group Note
Offline Web applications?at WHATWG
本問就討論這么多內容,大家有什么問題或好的想法歡迎在下方參與留言和評論.
本文作者: louis
本文鏈接: http://louiszhai.github.io/20...
參考文章
Using the application cache | MDN
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/61854.html
摘要:要快,但是我們的服務也必須萬無一失,后續我會分享百度移動端首頁的前端架構設計那么這樣的優化,是如何做到的呢,又如何兼顧穩定性,架構性,與速度呢別急,讓我們把這些優化一一道來。百度移動端首頁的很多就是這樣緩存在客戶端的。 歡迎大家收看聊一聊系列,這一套系列文章,可以幫助前端工程師們了解前端的方方面面(不僅僅是代碼):https://segmentfault.com/blog/fronte...
摘要:的編譯構建上一篇文章詳解中介紹了基于事件流編程,是個高度的插件集合,整體介紹了的編譯流程。本文將單獨聊一聊最核心的部分,編譯構建。的編譯重要的構建節點的構建中總會經歷如下幾個事件節點。 webpack的編譯&構建 上一篇文章webpack詳解中介紹了webpack基于事件流編程,是個高度的插件集合,整體介紹了webpack 的編譯流程。本文將單獨聊一聊最核心的部分,編譯&構建。 web...
摘要:如圖圖顧名思義,,是級別的存儲。如筆者寫的一篇淺析文章聊一聊百度移動端首頁前端速度那些事兒讀者們可以嘗試使用。 歡迎大家收看聊一聊系列,這一套系列文章,可以幫助前端工程師們了解前端的方方面面(不僅僅是代碼):https://segmentfault.com/blog/frontenddriver 在web開發越來越復雜的今天,前端擁有的能力也越來越多。其中最重要的一項莫過于web存儲。...
閱讀 3160·2021-11-04 16:09
閱讀 3121·2021-09-23 11:49
閱讀 3605·2021-09-09 09:33
閱讀 3624·2021-08-18 10:22
閱讀 2045·2019-08-30 15:55
閱讀 3631·2019-08-30 15:53
閱讀 2660·2019-08-28 18:08
閱讀 893·2019-08-26 18:18