使用 Storage 的 3 个理由

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

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

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

原理图

687474703a2f2f67746d7330312e616c6963646e2e636f6d2f7470732f69312f543172327a4f466b6c6458586236335a664d2d3731372d3535302e6a7067

更多技术细节请移步此处

理由 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端和移动端的浏览器上。

收藏 评论

可能感兴趣的话题



直接登录
跳到底部
返回顶部