、HTML5離線緩存技術
支持離線緩存是HTML5中的一個重點,離線緩存就是讓用戶即使在斷網的情況下依然可以正常的運行應用。傳統的本地存儲數據的方式有 localstorage,sessionstorage和cookie。但是這些傳統的方式有著致命的弊端。首先這些傳統的存儲方式的最大使用空間有 限,最多不超過5M;其次它們處理大規模的結構化數據的能力有限。鑒于傳統方式的局限性,HTML5提出了三種新的離線緩存解決方案:Web SQL,indexedDB和File System。
其中Web SQL已經不包含在HMLT5規范中,成了一個獨立的規范,Web SQL使用的SQL是SQLite。由于無法統一各個瀏覽器廠商實現的SQL語言,故Web SQL已經被廢棄,由indexedDB取代,但是目前很多瀏覽器支持Web SQL,而且相對于indexedDB和 File System來說,Web SQL的效率最高,訪問速度最快,穩定性也最好。
indexedDB也支持本地存儲大量對象,并使用健壯的數據訪問機制檢索數據。但是目前支持Indexedb的瀏覽器很少,而且規范還在持續更新中,暫時還沒有形成一個統一的標準。
在離線環境中,WebDataBase 雖然能夠存儲并有效地管理和維護客戶端的數據集合,但是仍不能滿足對包含大段數據文件的存儲和多種不同格式 文件的保存,于是我們就需要離線的文件管理系統來維護我們工作了,基于HTML5的File System API 就充當這這個角色。File System非常適合大量的存儲媒體文件。對于手機端而言,不同的瀏覽器的實現有所不同,有的瀏覽器是將文件寫入到ROM中,如QQ手機瀏覽器,有的瀏覽 器是將文件寫到SD卡中,如百度瀏覽器。所以理論上File System可用的空間非常大。
二、手機瀏覽器支持離線緩存的情況
測試采用的寫數據的方式是key-value對,其中value的值150k左右。
由于Web SQL,indexedDB和File System的可用空間容量與手機Temporary storage有關,故測試數據與手機機型和瀏覽器本身的狀態有關,故上述數據僅供參考。測試的過程中還發現有些瀏覽器HTML5跑分,分數雖然拿到了, 但是實際并沒有完全實現相關標準。
測試結果顯示,手機瀏覽器對Web SQL,indexedDB和File System支持情況參差不齊,除了chrome支持所有的三種標準之外,其它的手機瀏覽器支持都不全,對于開發者來說,如果想要用到這些技術,必須先探 測瀏覽器是否支持該標準,只有支持了才可以使用相關的API。為了使開發者透明地使用底層的離線緩存空間,使用者不用自己去測探瀏覽器究竟支持哪種或者哪 幾種標準,現在作者開發了一個HTML5離線緩存管理庫,用戶便可以像調用localstorage一樣調用相關的接口即可獲取數據,為開發者提供最大的 便利。
三、HTML5離線緩存管理庫的設計
1、接口設計
在web前端開發的過程中,開發者localstorage的接口使用相對熟悉,故HTML5離線緩存管理庫采用類localstorage的接口,異步的調用方式。
設置(key,value)值對
cache.setItem(key, value, suc, err)
key: string類型
value: string類型
suc:設置成功的回調函數
err:設置失敗的回調函數
獲取鍵值為key的值
cache.getItem(key, suc, err)
key: string類型
suc:獲取成功的回調函數
err:獲取失敗的回調函數
刪除鍵值為key的項
cache.removeItem(key, suc, err)
key: string類型
suc:刪除成功的回調函數
err:刪除失敗的回調函數
清除所有記錄
cache.clear(suc, err)
suc:清除所有記錄成功的回調函數
err:清除所有記錄失敗的回調函數
2、總體設計
HTML5離線緩存管理庫采用的優先適配的策略,優先級為Web SQL > File System> indexedDB >localstorage。即js會自動對瀏覽器就行檢測,如果發現支持web SQL,則使用web SQL,如果不支持,則接著檢測File System,如果支持則會使用File System,以此類推。
至于為什么將優先級設置為:web SQL > File System> indexedDB >localstorage,主要是基于以下幾方面做考慮:
雖然Web SQL是個逐漸廢棄的標準,但是目前是瀏覽支持得最為廣泛的技術,而且效率最高,速度最快,穩定性最好,故將其作為首選。
本庫對外提供的接口是key-value對的形式,而File System是以文件的形式存在的,為了達到接口的要求需要封裝和解析,導致效率下降,故將它的優先級位于web SQL之后,但是它可供使用空間的大小最大,所有將它放在indexedDB之前。
indexedDB將取代Web SQL,但是indexedDB的規范在持續更新中,目前并沒有完全形成一個最終的標準,這體現在一些接口的更迭(本緩存庫有做兼容),而且支持 indexedDB的瀏覽器很少,且支持情況不是很好,故將其僅放在localstorage之前。
localstorage存儲空間最小,支持最為廣泛,故作為一個最保險的后備方案。
為了保證對外提供的是統一的接口,接口傳入的數據格式是key-value對的形式,但是由于File System本身是以文件的方式存儲數據,所以不太適合處理key-value這類數據。
本庫采用的數據存儲方式是將key-value保存為JSON格式,通過JSON.stringify將其轉化為字符串,并保存到文件中,讀取的時候,通過JSON.parse將文件中數據解析為JSON格式。
為了提高File System的存取效率,采用了兩種優化策略。首先將數據存于多個文件之中,根據key建立hash映射,每次讀取數據,直接從相應的文件中取,這種方式 相對于存到一個文件的方式優點是,文件小,故每次讀取的數據量小;其次采取緩存的策略,初始化的時候,將文件讀取到內存之中,之后每次讀取數據的時候直接 從內存中取數據即可,這樣相比于每次直接從文件中讀取數據,效率得到了極大的提升,當更改數據的時候會將緩存中的數據flush到文件中。
3、兼容性問題
由于HTML5相關標準在持續更新中,API隨著標準的跟進,也有所變化,如下是一些比較大的改變。
File System
BlobBuilder構造函數被啟用,應該使用Blob構造函數,例如:
舊的調用方式:
var bb = new BlobBuilder();
bb.append(JSON.stringify(t.cache[name]));
write.write(bb.getBlob(‘text/plain‘));
新的調用方式:
var bb = new Blob([JSON.stringify(t.cache[name])], {type: "text/plain"});
write.write(bb);
Web SQL
setVersion()方法被廢棄,這導致我們在創建數據庫和createObjectStore的流程有一些變動,而且多了一些新的回調方法。
//注意區別以前的方法,這里第二個參數不再是description,而是數據庫版本號
var request = indexedDB.open(‘mydb‘,1);
request.onsuccess = function(e) { //數據庫打開成功回調
DB.db = e.target.result; //我們用DB.db來存放indexdb
callback();
};
//第一次打開數據庫或數據庫升級時會觸發,完成后根據情況觸發success或者error
request.onupgradeneeded = function(e){
DB.db = e.target.result;
var db = DB.db;
//createObjectStore,以前需要在setVersion時才能執行。
if(!DB.db.objectStoreNames.contains(‘notes‘)){
// create object store
var store = db.createObjectStore(‘notes‘, {keyPath:‘id‘, autoIncrement:true})
store.createIndex(‘updated‘, ‘updated‘, { unique: false });
}
};
request.onerror = function(e){ //數據庫打開錯誤回調
console.log(e);
}
四、測試
1.測試說明
使用HTML5離線緩存庫的測試頁面如下:
使用方法:
1.測試setItem
主要測試setItem接口,設置key-value。
2.測試getItem
主要測試getItem接口,根據用戶輸入的key,點擊“確定”,查詢對應的記錄,如果查詢不到對應的記錄,value框為空;如果查詢到對應的記錄,value框中顯示查詢的結果。
3.測試removeItem
主要測試removeItem接口,用戶輸入key,點擊“確定”后刪除key對應的記錄。
4.測試clear
主要測試clear接口,點擊“確定”,刪除所有的記錄。
5.自動測試
連續寫入key-value數據,其中key為“1”,“2”,“3”遞增,value為160.6k的固定字符串。點擊“開始”,連續寫入該 key-value數據,直到點擊“結束”或者離線緩存寫滿為止;點擊“結束”,停止自動寫數據。如果重復“開始”操作,需要刷新頁面。
2.測試結果
使用HTML5離線緩存管理庫對部分手機瀏覽器的測試結果如下:
3.源文件
HTML5離線緩存管理庫的測試鏈接:
http://3gimg.qq.com/cube/cache/index-1.0.html
五、同步插件
1.使用說明
鑒于前端開發者比較習慣使用同步API,而Web SQL,indexedDB和File System都提供異步API,為了方便開發者,筆者為“HTML5 離線緩存管理庫”提供了一個同步插件,方便開發者同步調用相關API,供參考。
“HTML5 離線緩存管理庫”的同步插件使用說明:
優點:
(1) 方便開發者使用“HTML5 離線緩存管理庫”進行同步操作,開發者可以像調用localstorage的方式同步調用相關接口。
(2) 調用者只需初始化一次,在初始化成功后便可進行余下操作。
(3) 由于開發者調用的接口其實都是從內存中取得數據,故速度比較快,flush等操作讓后臺處理。
缺點:
(1) 離線緩存方式fileSystem,indexdb和webSQL系統提供的API就是異步的方式,為了封裝接口提供同步的API,必然有效率上的損失。 因為啟動時會一次性加載離線緩沖庫中的所有數據,故獲取數據的時間會相應變長,對于少量數據,可以忽略不計,如果數據量特別大,即該插件會明顯減慢加載速 度。
(2) 數據會全部拷貝到內存中,會占用部分瀏覽器內存。
建議:
該插件式為了方便同步使用離線緩存庫,對于小數據量很方便,對于大數據來說,不推薦使用該插件,建議都采用異步的方式調用離線緩存庫提供的接口API。
注:正常使用該庫的時候必須保證synCache初始化成功。
2.源文件
HTML5離線緩存管理庫的同步插件鏈接:
http://3gimg.qq.com/cube/cache/cache_plugin_sync-1.0.js
目前,“手機酷站”iphone版使用了"HTML5離線緩存管理庫"和“同步插件”,相關鏈接如下:
http://app.html5.qq.com/ip/index
學習軟件行業,選擇就業的機會更多,拿到的薪水也更可觀,Web前端開發隨著互聯網的不斷發展,就業前景更廣泛。千鋒教育重慶Web前端培訓,專業的IT培訓機構,全國15所城市都設有分校,是IT職業教育領先品牌,學員入學就簽訂就業協議,2017年畢業學員首次就業平均月薪10000元,強大的師資力量與完善的就業體系,讓你高薪就業不再是夢想!
、什么是應用程序緩存:
HTML5引入了應用程序緩存,這意味著web應用可進行緩存,并可在沒有因特網
連接時進行訪問
2、應用緩存的優勢:
1): 離線瀏覽-用戶可在應用離線時使用它們
2):速度-已緩存資源加載得更快
3):減少服務器負載-瀏覽器將只從服務器下載更新過或更改過的資源
3、實現緩存:
如需啟用應用程序緩存,請在文檔的<html>標簽中包含manifest屬性
manifest文件的建議的文件擴展名是:’.appcache'"
4、Manifest 文件:
1): CACHE MANIFEST-在此標題下列出的文件將在首次下載后進行緩存
2): NETWORK -在此標題下列出的文件需要與服務器的連接, 且不會被緩存
3): FALLBACK -在此標題下列出的文件規定當頁面無法訪問時的回退頁面(比如
404頁面)
具體使用:1、在html頁面的html標簽里面添加.appcache 的文件
2、創建對應的.appcache文件
3、在緩存文件里面寫上 CACHE MANIFEST 注意是大寫哦
接著寫上CACHE:../db.html
db.js
db.html頁面里面:<html manifest="js/db.appcache">db.appcache文件創建在js文件夾里面,創建的時候,選擇創建文件即可
頁面加上緩存后,本地打開服務器html5頁面速度會變快,或者服務器沒有連接上,本地也可以顯示頁面數據
言
本篇文章主要介紹了前端HTML5幾種存儲方式的總結 ,主要包括本地存儲localstorage,本地存儲sessionstorage,離線緩存(application cache),Web SQL,IndexedDB。有興趣的可以了解一下。
正文開始~
h5之前,存儲主要是用cookies。cookies缺點有在請求頭上帶著數據,大小是4k之內。主Domain污染。
主要應用:購物車、客戶登錄
對于IE瀏覽器有UserData,大小是64k,只有IE瀏覽器支持。
目標
存儲方式:
以鍵值對(Key-Value)的方式存儲,永久存儲,永不失效,除非手動刪除。
大小:
每個域名5M
支持情況:
注意:IE9 localStorage不支持本地文件,需要將項目署到服務器,才可以支持!
if(window.localStorage){ alert('This browser supports localStorage'); }else{ alert('This browser does NOT support localStorage'); }
常用的API:
getItem //取記錄
setIten//設置記錄
removeItem//移除記錄
key//取key所對應的值
clear//清除記錄
存儲的內容:
數組,圖片,json,樣式,腳本。。。(只要是能序列化成字符串的內容都可以存儲)
HTML5 的本地存儲 API 中的 localStorage 與 sessionStorage 在使用方法上是相同的,區別在于 sessionStorage 在關閉頁面后即被清空,而 localStorage 則會一直保存。
本地緩存應用所需的文件
使用方法:
①配置manifest文件
頁面上:
<!DOCTYPE HTML> <html manifest="demo.appcache"> ... </html>
Manifest 文件:
manifest 文件是簡單的文本文件,它告知瀏覽器被緩存的內容(以及不緩存的內容)。
manifest 文件可分為三個部分:
①CACHE MANIFEST - 在此標題下列出的文件將在首次下載后進行緩存
②NETWORK - 在此標題下列出的文件需要與服務器的連接,且不會被緩存
③FALLBACK - 在此標題下列出的文件規定當頁面無法訪問時的回退頁面(比如 404 頁面)
完整demo:
CACHE MANIFEST # 2016-07-24 v1.0.0 /theme.css /main.js NETWORK: login.jsp FALLBACK: /html/ /offline.html
服務器上:manifest文件需要配置正確的MIME-type,即 "text/cache-manifest"。
如Tomcat:
<mime-mapping> <extension>manifest</extension> <mime-type>text/cache-manifest</mime-type> </mime-mapping>
常用API:
核心是applicationCache對象,有個status屬性,表示應用緩存的當前狀態:
0(UNCACHED) : 無緩存, 即沒有與頁面相關的應用緩存
1(IDLE) : 閑置,即應用緩存未得到更新
2 (CHECKING) : 檢查中,即正在下載描述文件并檢查更新
3 (DOWNLOADING) : 下載中,即應用緩存正在下載描述文件中指定的資源
4 (UPDATEREADY) : 更新完成,所有資源都已下載完畢
5 (IDLE) : 廢棄,即應用緩存的描述文件已經不存在了,因此頁面無法再訪問應用緩存
相關的事件:
表示應用緩存狀態的改變:
checking : 在瀏覽器為應用緩存查找更新時觸發
error : 在檢查更新或下載資源期間發送錯誤時觸發
noupdate : 在檢查描述文件發現文件無變化時觸發
downloading : 在開始下載應用緩存資源時觸發
progress:在文件下載應用緩存的過程中持續不斷地下載地觸發
updateready : 在頁面新的應用緩存下載完畢觸發
cached : 在應用緩存完整可用時觸發
Application Cache的三個優勢:
① 離線瀏覽
② 提升頁面載入速度
③ 降低服務器壓力
注意事項:
1. 瀏覽器對緩存數據的容量限制可能不太一樣(某些瀏覽器設置的限制是每個站點 5MB)
2. 如果manifest文件,或者內部列舉的某一個文件不能正常下載,整個更新過程將視為失敗,瀏覽器繼續全部使用老的緩存
3. 引用manifest的html必須與manifest文件同源,在同一個域下
4. 瀏覽器會自動緩存引用manifest文件的HTML文件,這就導致如果改了HTML內容,也需要更新版本才能做到更新。
5. manifest文件中CACHE則與NETWORK,FALLBACK的位置順序沒有關系,如果是隱式聲明需要在最前面
6. FALLBACK中的資源必須和manifest文件同源
7. 更新完版本后,必須刷新一次才會啟動新版本(會出現重刷一次頁面的情況),需要添加監聽版本事件。
8. 站點中的其他頁面即使沒有設置manifest屬性,請求的資源如果在緩存中也從緩存中訪問
9. 當manifest文件發生改變時,資源請求本身也會觸發更新
離線緩存與傳統瀏覽器緩存區別:
1. 離線緩存是針對整個應用,瀏覽器緩存是單個文件
2. 離線緩存斷網了還是可以打開頁面,瀏覽器緩存不行
3. 離線緩存可以主動通知瀏覽器更新資源
關系數據庫,通過SQL語句訪問
Web SQL 數據庫 API 并不是 HTML5 規范的一部分,但是它是一個獨立的規范,引入了一組使用 SQL 操作客戶端數據庫的 APIs。
支持情況:
Web SQL 數據庫可以在最新版的 Safari, Chrome 和 Opera 瀏覽器中工作。
核心方法:
①openDatabase:這個方法使用現有的數據庫或者新建的數據庫創建一個數據庫對象。
②transaction:這個方法讓我們能夠控制一個事務,以及基于這種情況執行提交或者回滾。
③executeSql:這個方法用于執行實際的 SQL 查詢。
打開數據庫:
var db = openDatabase('mydb', '1.0', 'Test DB', 2 * 1024 * 1024,fn); //openDatabase() 方法對應的五個參數分別為:數據庫名稱、版本號、描述文本、數據庫大小、創建回調
執行查詢操作:
var db = openDatabase('mydb', '1.0', 'Test DB', 2 * 1024 * 1024); db.transaction(function (tx) { tx.executeSql('CREATE TABLE IF NOT EXISTS WIN (id unique, name)'); });
插入數據:
var db = openDatabase('mydb', '1.0', 'Test DB', 2 * 1024 * 1024); db.transaction(function (tx) { tx.executeSql('CREATE TABLE IF NOT EXISTS WIN (id unique, name)'); tx.executeSql('INSERT INTO WIN (id, name) VALUES (1, "winty")'); tx.executeSql('INSERT INTO WIN (id, name) VALUES (2, "LuckyWinty")'); });
讀取數據:
db.transaction(function (tx) { tx.executeSql('SELECT * FROM WIN', [], function (tx, results) { var len = results.rows.length, i; msg = "<p>查詢記錄條數: " + len + "</p>"; document.querySelector('#status').innerHTML += msg; for (i = 0; i < len; i++){ alert(results.rows.item(i).name ); } }, null); });
由這些操作可以看出,基本上都是用SQL語句進行數據庫的相關操作,如果你會MySQL的話,這個應該比較容易用。
索引數據庫 (IndexedDB) API(作為 HTML5 的一部分)對創建具有豐富本地存儲數據的數據密集型的離線 HTML5 Web 應用程序很有用。同時它還有助于本地緩存數據,使傳統在線 Web 應用程序(比如移動 Web 應用程序)能夠更快地運行和響應。
異步API:
在IndexedDB大部分操作并不是我們常用的調用方法,返回結果的模式,而是請求——響應的模式,比如打開數據庫的操作
這樣,我們打開數據庫的時候,實質上返回了一個DB對象,而這個對象就在result中。由上圖可以看出,除了result之外。還有幾個重要的屬性就是onerror、onsuccess、onupgradeneeded(我們請求打開的數據庫的版本號和已經存在的數據庫版本號不一致的時候調用)。這就類似于我們的ajax請求那樣。我們發起了這個請求之后并不能確定它什么時候才請求成功,所以需要在回調中處理一些邏輯。
關閉與刪除:
function closeDB(db){ db.close(); } function deleteDB(name){ indexedDB.deleteDatabase(name); }
數據存儲:
indexedDB中沒有表的概念,而是objectStore,一個數據庫中可以包含多個objectStore,objectStore是一個靈活的數據結構,可以存放多種類型數據。也就是說一個objectStore相當于一張表,里面存儲的每條數據和一個鍵相關聯。
我們可以使用每條記錄中的某個指定字段作為鍵值(keyPath),也可以使用自動生成的遞增數字作為鍵值(keyGenerator),也可以不指定。選擇鍵的類型不同,objectStore可以存儲的數據結構也有差異。
學習從來不是一個人的事情,要有個相互監督的伙伴,想要學習或交流前端問題的小伙伴可以私信“學習”小明獲取web前端入門資料,一起學習,一起成長!
*請認真填寫需求信息,我們會在24小時內與您取得聯系。