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