使用 Storage 的 3 个理由

[luics]

阿里的 Kissy 组件大赛进行得火热，笔者耐不住寂寞携 Storage 投身其中，斩获了第四周「本周之星」。借着获奖的余温，把 Storage 介绍给所有人，如觉得不错请 Star it！

Storage 是一个跨终端、跨域的存储组件：

1. 十亿级日调用次数的考验，稳定可靠
2. 兼容 IE 6+，Chrome、Firefox、Safari
3. 不使用 Flash 方案，完美支持移动浏览器
4. 跨子域、主域的数据存取，且不改写 document.domain
5. 支持 Object、Array 等复杂对象存取

原理图

更多技术细节请移步此处。

理由 1：状态保存向前端迁移

随着页面复杂性急剧增加，以及页面间关联性不断提高，原来看似无关联的多个页面间某些状态同步的需求在不断增多。

状态数据存放于后端带来的直接问题是，海量的状态信息给服务器无论是存储容量还是网络 IO 都带来了更大的挑战；前端存储状态的天然优势在于利用亿级客户端设备存储状态信息，几乎无网络开销（可能会有同步）。简单计算下，10 亿个客户端按照每个 2MB 来算就是约 2000T。以天猫最近的某项目为例，状态存储在前端直接节约了200台缓存服务器；另一个例子是，百度、google 的搜索历史保存在前端，用户输入时可以快速地从本地存储中提供搜索建议。

使用 cookie 存储标记状态的行为由来已久，可以看做是前端保存状态最简单的形态。受限 cookie 的长度（4KB）以及 cookie 对网络请求造成的额外负担，通常我们只用 cookie 保存那些开关量；Storage 使用 localStorage（IE6/7使用 userData）存储数据，存储容量远超 cookie，也不会加重网络开销。

理由 2：跨域存储

cookie 实际能存储的数据很少（4KB），并且考虑 到 cookie 数据会存在于 http 请求和响应 header 中加重了网络开销；flash storage 和 userData 都属于「外挂」资源，对于前端而言是个黑箱，随着移动端的兴起，这些技术也将退出历史舞台；localStorage 是 HTML5标准的一部分，无论在存储上限还是对网络的影响上都是更佳的选择，目前几乎支持所有的浏览器（IE6、7除外）。

可是出于安全考虑，localStorage 存储的数据不能跨子域访问（即使修改 document.domain），userData 也有着类似的问题；Storage 将数据存储在代理页（b.com）所在域，宿主页（a.com）通过与代理页的跨域通信存储数据，跨域通信使用 postMessage（IE6/7使用window.name）不会改写 document.domain。前端可能会用 document.domain 进行环境判断，而改写 document.domain 在复杂系统中很容易产生隐患，这种隐患都是开关级别的通常比较严重；即使没有这种隐患， document.domain 改写也只能在同一个主域下进行，对于不同主域（如 a.com和b.com）的情况就无能为力了。

理由 3：跨终端

iOS 平台不支持 Flash，随着 Adobe 宣告不再支持 Flash 移动端，localStorage (及 DB 类存储) 实际成了移动端上唯一可用的存储介质。 Storage 不使用 Flash 方案，一份代码可运行在 PC端和移动端的浏览器上。

转载请标明来自：https://github.com/luics/luics.github.com/issues