HTML5 离线缓存管理库

一、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，主要是基于以下几方面做考虑：

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到文件中。

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

六、链接

所有相关链接如下：

"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