分析：SQL Database 的主要优势在于能够存储结构复杂的数据，能充分利用数据库的优势，可方便对数据进行增加、删除、修改、查询。由于 SQL 语法的复杂性，使用起来麻烦一些。SQL Database 也不太适合做静态文件的缓存。
在 Android 内嵌 Webview 中，需要通过 Webview 设置接口启用 SQL Database，同时还要设置数据库文件的存储路径。
WebView myWebView = (WebView) findViewById(R.id.webview);
WebSettings webSettings = myWebView.getSettings();
webSettings.setDatabaseEnabled(true);
final String dbPath = getApplicationContext().getDir("db", Context.MODE_PRIVATE).getPath();
webSettings.setDatabasePath(dbPath);
Android 系统也使用了大量的数据库用来存储数据，比如联系人、短消息等；数据库的格式也 SQLite。Android 也提供了 API 来操作 SQLite。Web SQL Database 存储机制就是通过提供一组 API，借助浏览器的实现，将这种 Native 的功能提供给了 Web App。
2.4 Application Cache 机制
Application Cache（简称 AppCache)似乎是为支持 Web App 离线使用而开发的缓存机制。它的缓存机制类似于浏览器的缓存（Cache-Control 和 Last-Modified）机制，都是以文件为单位进行缓存，且文件有一定更新机制。但 AppCache 是对浏览器缓存机制的补充，不是替代。
先拿 W3C 官方的一个例子，说下 AppCache 机制的用法与功能。
Get Date and TimeTry opening this page, then go offline, and reload the page. The script and the image should still work.
上面 HTML 文档，引用外部一个 JS 文件和一个 GIF 图片文件，在其 HTML 头中通过 manifest 属性引用了一个 appcache 结尾的文件。
我们在 Google Chrome 浏览器中打开这个 HTML 链接，JS 功能正常，图片也显示正常。禁用网络，关闭浏览器重新打开这个链接，发现 JS 工作正常，图片也显示正常。当然也有可能是浏览缓存起的作用，我们可以在文件的浏览器缓存过期后，禁用网络再试，发现 HTML 页面也是正常的。
通过 Google Chrome 浏览器自带的工具，我们可以查看已经缓存的 AppCache（分 HOST)。
上面截图中的缓存，就是我们刚才打开 HTML 的页面 AppCache。从截图中看，HTML 页面及 HTML 引用的 JS、GIF 图像文件都被缓存了；另外 HTML 头中 manifest 属性引用的 appcache 文件也缓存了。
AppCache 的原理有两个关键点：manifest 属性和 manifest 文件。
HTML 在头中通过 manifest 属性引用 manifest 文件。manifest 文件，就是上面以 appcache 结尾的文件，是一个普通文件文件，列出了需要缓存的文件。
上面截图中的 manifest 文件，就 HTML 代码引用的 manifest 文件。文件比较简单，第一行是关键字，第二、三行就是要缓存的文件路径（相对路径）。这只是最简单的 manifest 文件，完整的还包括其他关键字与内容。引用 manifest 文件的 HTML 和 manifest 文件中列出的要缓存的文件最终都会被浏览器缓存。
完整的 manifest 文件，包括三个 Section，类型 Windows 中 ini 配置文件的 Section，不过不要中括号。
-
CACHE MANIFEST - Files listed under this header will be cached after they are downloaded for the first time
-
NETWORK - Files listed under this header require a connection to the server, and will never be cached
-
FALLBACK - Files listed under this header specifies fallback pages if a page is inaccessible
完整的 manifest 文件，如：
CACHE MANIFEST
# 2012-02-21 v1.0.0
/theme.css
/logo.gif
/main.js
NETWORK:
login.asp
FALLBACK:
/html/ /offline.html
总的来说，浏览器在首次加载 HTML 文件时，会解析 manifest 属性，并读取 manifest 文件，获取 Section：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 中不能加载，即使有网络。例如：
-
manifest 文件本身不能被缓存，且 manifest 文件的更新使用的是浏览器缓存机制。所以 manifest 文件的 Cache-Control 缓存时间不能设置太长。
另外，根据官方文档，AppCache 已经不推荐使用了，标准也不会再支持。现在主流的浏览器都是还支持 AppCache的，以后就不太确定了。
在Android 内嵌 Webview中，需要通过 Webview 设置接口启用 AppCache，同时还要设置缓存文件的存储路径，另外还可以设置缓存的空间大小。
WebView myWebView = (WebView) findViewById(R.id.webview);
WebSettings webSettings = myWebView.getSettings();
webSettings.setAppCacheEnabled(true);
final String cachePath = getApplicationContext().getDir("cache", Context.MODE_PRIVATE).getPath();
webSettings.setAppCachePath(cachePath);
webSettings.setAppCacheMaxSize(5*1024*1024);
2.5 Indexed Database
相关文章
精彩导读
热门资讯
关注我们
