前言

  《Javascript是如何工作的》系列之十六，本系列值得收藏。今日前端早读课文章由@Troland翻译授权分享。

  @Troland，自号姑射子，嗜静，工书法，流连山水，游走于市井与田园之间。

  正文从这开始~~

  概述

  每当设计网页程序的时候，为本地设备选择合适的存储机制尤为重要。一个好的存储引擎可以帮助开发人员有效地存储数据js清除浏览器缓存，减少传输带宽及提高程序的响应速度。正确的存储缓存策略是构建移动端离线网页体验的核心组成部分，越来越多的用户默认以为可以离线使用移动端网页程序。

  本章，我们将讨论各种可用的存储 API 和服务，并提供一些在构建网页程序时如何正确地选择存储引擎的建议。

  数据模型

  数据存储模型决定了其内部是如何组织存储数据的。这会影响到整个网页程序的设计，并计算出为获取高性能网页程序及解决其所遇到的问题所需要的开销。没有所谓更好的技术和一刀切的解决方案，因为所有的问题都是工程学相关的问题。那么，让我们来瞧瞧可供选择的数据模型吧：

  持久性

  网页程序的数据存储方法可以以数据的存储时长来进行分析：

  客户端数据持久性

  现如今，有相当多的浏览器 API 可供选择用于存储数据。这里将详细讨论这些方法，然后对其进行比较以便让开发者轻松地选择正确的数据存储方案。

  然而，首先在选择如何存储数据之前，开发者需要考虑几件事情 。当然了，第一件事即必须想清楚打算如何使用网页程序及之后的维护和性能优化。即使胸有成竹，可代选择的方案可能只有几个。以下为开发者需要考虑的问题：

  对比

  这里，让我们浏览一下网页开发者当前可用的 API 并使用上述的几个维度来进行比较。

  文件系统 API

  有了 FileSystem API，网页程序就可以在用户本地文件系统的沙箱中进行新建js清除浏览器缓存，读取，操作和写文件。

  该接口包含如下几个部分：

  文件系统 API 并不是标准的 API.因其兼容性不太好，所以切记不要在生产环境中使用。各种浏览器厂商的实现会有很大的不同且该 API 以后可能会变更。

  文件和目录条目 API 接口文件系统用来表示一个文件系统。可从任意文件系统条目的 filesystem 属性中获取这些对象。少数浏览器提供了额外的 API 来创建和操作文件系统。

  该接口不会允许开发者访问用户的文件系统。相反，开发者会在浏览器沙箱内获得一个虚拟磁盘。若想要访问用户的文件系统，可以采取安装 Chrome 插件的方法。

  获得文件系统

  网页程序可调用 window.requestFileSystem() 来访问沙箱文件系统。：

  <pre style="box-sizing: border-box;overflow: auto;font-family: Consolas, "Liberation Mono", Menlo, Courier, monospace;font-size: 13.6px;margin-bottom: 16px;font-stretch: normal;line-height: 1.45;padding: 16px;background-color: rgb(247, 247, 247);border-radius: 3px;overflow-wrap: normal;caret-color: rgb(51, 51, 51);text-align: start;text-size-adjust: auto;">// 注意: 该文件系统以 Google Chrome 12 为前缀The file system has been prefixed as of Google Chrome 12: window.requestFileSystem = window.requestFileSystem || window.webkitRequestFileSystem; window.requestFileSystem(type, size, successCallback, opt_errorCallback) </pre>

  第一次调用 requestFileSystem() 方法的时候会新建一个本地存储。需要注意的是该文件系统是沙箱型的，意即网页程序不可以访问其它程序的文件。

  在获得访问文件系统的权限后，开发者可以对文件和目录进行大部分标准文件系统操作。

  和其它存储策略相比，FileSystem 大有不同，它旨在满足数据库不能很好地解决客户端存储的情况。一般来说，程序用来处理大型二进制 blobs 文件或者和浏览器上下文之外的程序分享数据。

  以下为使用 FileSystem 的好范例：

  以下为该 API 的当前浏览器支持情况：

  Local storage

  localStorage API 允许开发者访问 文档 源的 Storage 对象。存储的数据在多个浏览器会话之间仍然有效。localStorage 和 sessionStorage 类似，只不过存储在 localStorage 中的数据没有过期时间，而存储在 sessionStorage 中的数据会在页面会话结束时丢失-意即当关闭页面时即丢失。

  无论是 localStorage 还是 sessionStorage 其数据只存储在特定的页面源中，页面源包含协议，主机名和端口。

  以下为该 API 的当前浏览器支持情况：

  Session storage

  sessionStorage 属性允许开发者访问当前源的会话 Storage 对象。前面简述过，sessionStorage 和 localStorage 类似。唯一的区别即，存储在 localStorage 中的数据没有过期时间而 sessionStorage 中的数据会在页面会话结束时丢失。页面会话的时效为浏览器打开时且在页面重载和恢复时。在新的选项卡中打开新页面或者窗口会导致重新初始化一个新的会话，这与会话 cookies 的工作机制是不一样的。

  请注意无论数据存储于 sessionStorage 还是 localStorage 都仅只在指定的页面源中有效。

  以下为该 API 的当前浏览器支持情况：

  Cookies

  所谓 cookie(网页 cookie，浏览器 cookie) 指的是由用户的服务器发送到客户端的一小段数据。浏览器将其存储下来然后在下一次请求的时候捎带上发往同一服务器。一般而言，它被用来告知两个请求是否来自于同一个客户端-比如保持用户登录状态。它为 无状态 HTTP 协议记录有状态信息。

  Cookies 有以下三个主要用途：

  Cookies 曾经是通用的客户端存储方案。当它是客户端存储的唯一方案的时候，这是不二选择，现如今推荐选择使用现代存储 API 来存储客户端数据。每次发送请求都会捎带上 Cookies，所以会影响性能(特别是当在一个移动端请求数据的时候)。

  有两种类型的 cookies：

  请注意不要在 cookie 中存储凭据或者敏感信息，因其固有的不安全缺陷机制。

  然而，不肖说，cookie 是兼容性最好的方案。

  Cache

  Cache 接口是缓存请求/响应对象的存储机制。请注意和 workers 一样可在窗口作用域内使用 Cache 接口。虽然 Cache 是在服务工作线程规范中定义的，但这并不表示一定要和服务工作线程一起使用。

  一个源可以拥有多个命名的缓存对象。开发者只需要在脚本(比如在服务工作线程中)中实现如何处理更新缓存即可。除非显式请求否则不会更新缓存中的对象，只能通过删除缓存对象，否则不会过期。使用 CacheStorage.open() 来打开指定名称的缓存对象，然后调用任意的缓存方法来维护缓存。

  开发者需要定时清除缓存条目。每个源在浏览器端都有限额的缓存数据。使用 StorageEstimate 来估算缓存配额使用率。浏览器尽力管理硬盘空间，但它有可能会删除指定源的缓存数据。浏览器可能会删除指定源的所有数据抑或不会。切记使用名称来对脚本进行版本管理且只操作可以安全操作的脚本版本。查看 Deleting old caches 以获取更多信息。

  CacheStorage 接口表示 Cache 对象存储。

  接口：

  使用 CacheStorage.open() 来获取 Cache 实例。

  使用 CacheStorage.match() 来检查指定的 Request 是否是 CacheStorage 对象追踪的 Cache 对象的键。

  使用通过全局 caches 属性来访问 CacheStorage。

  IndexedDB

  IndexedDB 是一种客户端持久性数据存储方案。因其允许开发者创建拥有富查询能力的网页程序而不用关心网络情况，这些网页程序可以线上或者离线运行。

  IndexedDB 适用于大量的数据存储(比如，外借图书馆 DVD 目录)和不需要保持网络连通的网页程序(比如，邮件客户端，待办事项及便笺)。

  因大家都比较熟悉其它存储 API ，本文将对 IndexedDB 多唠会嗑。另外，如今随着网页程序越来越复杂 IndexedDB 也正变得越来越流行。

  IndexedDB 原理

  IndexedDB 允许开发者使用键来存储和获取一个对象。所有对数据库的操作均发生于事务之中。和其它网页存储方案一样，IndexedDB 遵循同源策略。因此，不能够跨域访问数据，只能访问同一个域名下的存储数据。

  可以在包括 网页服务线程 的大多数上下文上使用该异步 API。IndexedDB 曾经也有 synchronous 版本，应用于网页线程中，但是由于社区对此并不感冒所以被从规范中删除了。

  IndexedDB 曾经也有一个被称为 WebSQL 数据库的竞品规范，但是已经被 W3C 所弃用。虽然 IndexedDB 和 WebSQL 均是存储方案，但是它们功能并不一样。WebSQL 数据库是一个关系型数据库访问系统，而 IndexedDB 只是一个索引表系统。

  不要以其它类型数据库为蓝本，想当然地使用 IndexedDB。相反，需要仔细阅读文档。以下为开发者所需要了解的核心概念：

  IndexedDB 局限性

  IndexedDB 被设计用来满足大多数的客户端存储情况的。然而，它并没有被设计用来处理如下情况：

  另外，需要注意的是浏览器会在以下情况清除数据库：

  虽然现实情况和浏览器能力日新月异，但是浏览器产商都朝着尽一切可能保存数据的方向努力。

  选择合适的存储 API

  正如之前所说的那样，最好尽可能采用兼容性好的 API 且提供异步调用模型来最大限度地提升 UI 响应速度。这些标准自然而然会产生如下技术选择：

  参考

  关于本文

  译者：@Troland

  译文：