一、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',);
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
六、链接
所有相关链接如下:
"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