localStorage 存满了怎么办?

阅读 1176
收藏 32
2018-06-11
原文链接:www.cnblogs.com

先来几道面试题

1、a.meituan.com 和 b.meituan.com 这两个域能够共享同一个 localStorage 吗?

2、在 webview 中打开一个页面:i.meituan.com/home.html,点击一个按钮,调用 js 桥打开一个新的 webview:i.meituan.com/list.html,这两个分属不同 webview 的页面能共享同一个 localStorage 吗?

3、如果 localStorage 存满了,再往里存东西,或者要存的东西超过了剩余容量,会发生什么?

答案

1、同一个域名(document.domain)共享同一个 localStorage,a.meituan.com 和 b.meituan.com 是两个域名,所以不能共享

2、能。相当于同一个浏览器的不同标签页

3、存不进去并报错(QuotaExceededError)

 

技术很简单,业务很麻烦

在大公司,同一个域名下可能存在几十上百条业务线,每条业务线都可能因为各种理由往 localStorage 里塞东西,跨页面传数据啦、缓存啦、离线化啦、性能优化啦...,5M 看起来很多,其实很快就用完了。而开发时基本无感知,是因为大家都只访问自己的业务,但用户会访问各种业务,时间一久,很容易就存满了,凡是严重依赖 localStorage 的业务流程都存在风险,写可能出问题,读自然也就不可信。

一种容易想到的方案是,当 localStorage 存满后降级到 sessionStorage 里。看上去没啥问题,但实际业务中 app 内 h5 页面跳转常常采用新打开 webview 的方式,这么做的好处是关闭一个 webview 可以直接回到上一个页面,而不用重新加载页面,对于订单填写这类带有状态的页面就很需要这么做。新打开 webview 等于新打开一个会话,而 sessionStorage 只能存在于同一个会话中,因此 sessionStorage 无法跨页面共享。

那降级到 cookie 里呢?cookie 一共才 50 个,总大小不超过 4k,作为 backup 过于脆弱,而且还会影响请求的效率。

那降级到 url 上呢?很麻烦。比如有一个交互流程是这样的:页面 A => 页面 B => 页面 C,如果页面 A 的数据要传到页面 C,就得通过页面 B 做一层中转。而且 url 长度也是有限制的。

单页应用解决跨页面传数据就很简单,改造成单页应用呢?这个就得估算成本,看老板们认不认可了,而且原有应用积累了大量的业务逻辑,没有注释,没有测试用例,需求文档散落在不知名的角落,你真能保证重新做的和原来的功能一模一样吗。

我们还可以求助客户端同学,通过 js bridge 提供一个仿 localStorage 的东西,不过要考虑版本的问题,新版 app 里使用了客户端提供的 store,怎么兼顾老版 app,而且还要考虑兼容浏览器、微信。所以这种方案也只能解决一部分问题。

我们还可以求助后端同学,多加几个字段甚至多加几个接口,不过这涉及到核心业务流程的改造,风险不小,而且不见得能完全解决问题。

我们还可以来一招互相伤害大法,那就是把别人存的东西都删掉。。。

localStorage 是个好东西,不用,这是因噎废食,用,又很难统一和约束各业务线的用法,跟你在同一个域名下做开发的人可能跟你不在同一栋楼,甚至可能不在同一个城市。一旦放开用,就总会面临存满的风险。

 

问题的根源

同一个域名共享同一个 localStorage,而同一个域名下存在过多独立的业务线,业务线之间各自为政,毫无节制的攫取公共资源,这就是 localStorage 溢出问题的根源。

就我观察的情况来看,很多公司都喜欢把 h5 页面挂在 i.xxx.com 或 m.xxx.com 下,然后通过路径划分业务,比如 i.xxx.com/project-a, i.xxx.com/project-b...,随着业务发展,越来越多的业务都加到 i.xxx.com 中,“公地悲剧”就无可奈何的产生了,而且积重难返。我以前在的团队也是如此,用 h5、js、css 这样的类型名称来划分目录,初期东西少,自然没问题,但后来所有应用都把资源塞到 js 文件夹、css 文件夹下,一个文件夹包含了来自五湖四海的上百个文件,维护起来十分难受。

通过应用类型划分,而不是通过业务类型划分,这是最初架构策略的问题。如果 a 业务挂在 a.xxx.com 下,b 业务挂在 b.xxx.com 下,每个业务有独立的团队维护,localStorage 从公共资源变成团队的私有财产,或许这样才能从根源上解决 localStorage 无限膨胀的问题。

 

互相伤害其实是个好办法

约束每条业务线怎么用 localStorage 很难,不过如果大家都认可:任何业务线都可以清空 localStorage,任何业务线出了问题自己负责,那么就会倒逼各业务线增强代码健壮性。这一招狠,但管用。

 

如果我是架构师

我们在工作中肯定会遇到前人留下的各种坑、早期技术方案问题积累下的各种技术债、各种团队间合作问题、各种环境问题...,吐槽不会产生任何价值,能够产生价值的是这样一个问题:如果当初我是架构师,我怎么做技术方案来避免这一切问题?好的架构师总是能让技术方案提前一点等候着业务,而不是让业务追着、拖着、逼着走。这就是经验的价值。

 

 

评论
说说你的看法