HTML5 離線緩存管理庫

1、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可用的空間很是大。

2、手機瀏覽器支持離線緩存的狀況

測試採用的寫數據的方式是key-value對，其中value的值150k左右。

因爲Web SQL,indexedDB和File System的可用空間容量與手機Temporary storage有關，故測試數據與手機機型和瀏覽器自己的狀態有關，故上述數據僅供參考。測試的過程當中還發現有些瀏覽器HTML5跑分，分數雖然拿到了， 可是實際並無徹底實現相關標準。

測試結果顯示，手機瀏覽器對Web SQL,indexedDB和File System支持狀況良莠不齊，除了chrome支持全部的三種標準以外，其它的手機瀏覽器支持都不全，對於開發者來講，若是想要用到這些技術，必須先探 測瀏覽器是否支持該標準，只有支持了纔可使用相關的API。爲了使開發者透明地使用底層的離線緩存空間，使用者不用本身去測探瀏覽器究竟支持哪一種或者哪 幾種標準，如今做者開發了一個HTML5離線緩存管理庫，用戶即可以像調用localstorage同樣調用相關的接口便可獲取數據，爲開發者提供最大的 便利。

3、HTML5離線緩存管理庫的設計

一、接口設計

在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：清除全部記錄失敗的回調函數

 

二、整體設計

HTML5離線緩存管理庫採用的優先適配的策略，優先級爲Web SQL > File System> indexedDB >localstorage。即js會自動對瀏覽器就行檢測，若是發現支持web SQL，則使用web SQL，若是不支持，則接着檢測File System，若是支持則會使用File System，以此類推。

至於爲何將優先級設置爲：web SQL > File System> indexedDB >localstorage，主要是基於如下幾方面作考慮：

1. 雖然Web SQL是個逐漸廢棄的標準，可是目前是瀏覽支持得最爲普遍的技術，並且效率最高，速度最快，穩定性最好，故將其做爲首選。
2. 本庫對外提供的接口是key-value對的形式，而File System是以文件的形式存在的，爲了達到接口的要求須要封裝和解析，致使效率降低，故將它的優先級位於web SQL以後，可是它可供使用空間的大小最大，全部將它放在indexedDB以前。
3. indexedDB將取代Web SQL，可是indexedDB的規範在持續更新中，目前並無徹底造成一個最終的標準，這體如今一些接口的更迭（本緩存庫有作兼容），並且支持 indexedDB的瀏覽器不多，且支持狀況不是很好，故將其僅放在localstorage以前。
4. localstorage存儲空間最小，支持最爲普遍，故做爲一個最保險的後備方案。

爲了保證對外提供的是統一的接口，接口傳入的數據格式是key-value對的形式，可是因爲File System自己是以文件的方式存儲數據，因此不太適合處理key-value這類數據。

本庫採用的數據存儲方式是將key-value保存爲JSON格式，經過JSON.stringify將其轉化爲字符串，並保存到文件中，讀取的時候，經過JSON.parse將文件中數據解析爲JSON格式。

爲了提升File System的存取效率，採用了兩種優化策略。首先將數據存於多個文件之中，根據key創建hash映射，每次讀取數據，直接從相應的文件中取，這種方式 相對於存到一個文件的方式優勢是，文件小，故每次讀取的數據量小；其次採起緩存的策略，初始化的時候，將文件讀取到內存之中，以後每次讀取數據的時候直接 從內存中取數據便可，這樣相比於每次直接從文件中讀取數據，效率獲得了極大的提高，當更改數據的時候會將緩存中的數據flush到文件中。

三、兼容性問題

因爲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);
}

 

 

4、測試

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

5、同步插件

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

 

6、連接

全部相關連接以下：

"HTML5離線緩存管理庫"：

http://3gimg.qq.com/cube/cache/cache-1.0.js

http://3gimg.qq.com/cube/cache/cache-1.0.min.js

「同步插件」：

http://3gimg.qq.com/cube/cache/cache_plugin_sync-1.0.js

http://3gimg.qq.com/cube/cache/cache_plugin_sync-1.0.min.js

demo頁面：

http://3gimg.qq.com/cube/cache/index-1.0.html

線上應用/「手機酷站」iphone版：

http://app.html5.qq.com/ip/index

 

 

原文地址：http://cube.qq.com/?p=779