标签:
1.浏览器缓存机制
2.Dom Storage(local storage 和 session storage)
3.Web SQL Database,不推荐使用。
根据官方的标准文档,Web SQL Database存储机制不再推荐使用,将来也不再维护,而是推荐使用AppCache和IndexedDB。
4.Application Cache(manifest)
AppCache的缓存文件,与浏览器的缓存文件分开存储的,还是一份?应该是分开的。因为AppCache在本地也有5MB(分HOST)的空间限制。
AppCache在首次加载生成后,也有更新机制。被缓存的文件如果要更新,需要更新manifest文件。因为浏览器在下次加载时,除了会默认使用缓存外,还会在后台检查manifest文件有没有修改(byte by byte)。发现有修改,就会重新获取manifest文件,对Section:CACHE MANIFEST下文件列表检查更新。manifest文件与缓存文件的检查更新也遵守浏览器缓存机制。
如用用户手动清了AppCache缓存,下次加载时,浏览器会重新生成缓存,也可算是一种缓存的更新。另外, Web App也可用代码实现缓存更新。
分析:AppCache看起来是一种比较好的缓存方法,除了缓存静态资源文件外,也适合构建Web离线App。在实际使用中有些需要注意的地方,有一些可以说是”坑“。
要更新缓存的文件,需要更新包含它的manifest文件,那怕只加一个空格。常用的方法,是修改manifest文件注释中的版本号。如:# 2012-02-21 v1.0.0
被缓存的文件,浏览器是先使用,再通过检查manifest文件是否有更新来更新缓存文件。这样缓存文件可能用的不是最新的版本。
在更新缓存过程中,如果有一个文件更新失败,则整个更新会失败。
manifest和引用它的HTML要在相同HOST。
manifest文件中的文件列表,如果是相对路径,则是相对manifest文件的相对路径。
manifest也有可能更新出错,导致缓存文件更新失败。
没有缓存的资源在已经缓存的HTML中不能加载,即使有网络。例如:http://appcache-demo.s3-website-us-east-1.amazonaws.com/without-network/
manifest文件本身不能被缓存,且manifest文件的更新使用的是浏览器缓存机制。所以manifest文件的Cache-Control缓存时间不能设置太长。
另外,根据官方文档,AppCache已经不推荐使用了,标准也不会再支持。现在主流的浏览器都是还支持AppCache的,以后就不太确定了。
在Android内嵌Webview中,需要通过Webview设置接口启用AppCache,同时还要设置缓存文件的存储路径,另外还可以设置缓存的空间大小。
5.Indexed Database
6.File System API
标签:
原文地址:http://www.cnblogs.com/zhutianpeng/p/5463373.html