HTML5 離線緩存管理庫

本文轉載自查看原文 2015-05-10 22:26 2274 js高級群的日常

一、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初始化成功。