如何使用localstorage代替cookie实现跨域共享数据问题(5)

5，set方法中，如果储存的ls个数超过了最大限制，这个时候需要进行删除操作， LRU是Least Recently Used的缩写，即最近最少使用。我们通过遍历所有的key值，对key值做一个排序，通过lasttime，然后进行keys数组的pop操作，拿到堆栈尾部的需要被清除的key，然后逐个删除。

6，get方法中，我们通过遍历所有的key值，匹配到我们需要拿到的domain的域的key，然后把返回值中的key进行拆解（我们储存时是 key,domain的格式），因为api要求返回多个符合的值，我们对过期的数据最后再做一个filter，然后使用lz解压缩val值，保证用户拿到的是正确结果。

以上就是我们的一个整体实现编码过程和review，下面说一说遇到的坑。

五，一些遇到的坑

因为上面只给了主代码，并不是完整代码，因为本身逻辑比较清晰，花一点时间都可以写出来的。下面说说有什么坑的地方。

1，计算localstorage的储存值。

因为我们都知道有5MB的限制，所以每一条数据最大要求不能超过20*1024 字节，对于字节的计算，localstorage要使用utf16的编码进行转换，参考这篇文章： JS计算字符串所占字节数

2，兼容性

ie8下postMessage最好都传字符串，事件需要抹平处理，JSON需要抹平处理。

3，创建iframe时的异步处理

这里之前做了个一个setTimeout的递归等待，后来更改成了上面的实现方法，通过onload后统一处理promise的reslove，保证promise api的统一。

4，数据保存时，空间复杂度 vs 时间复杂度。

第一个版本并不是上面的实现，我实现了3个版本：

第一个版本是保存了一个LRU的数组，为了减少时间复杂度，但是浪费了空间复杂度，而且经过测试，store的get方法耗时比较大，主要是parse的耗时。

第二个版本，为了能让lz-string压缩率最大化，我把所有的数据包括LRU数组保存到了一个key值上，导致数据多的时候lz-string和getItem，parse时间消耗非常大，虽然计算的时间复杂度是最低。

最后一个版本，就是上面的，我牺牲了一些时间复杂度和空间复杂度，但是因为瓶颈在于set和get的读写速度，单个的保存读写速度极快，获取keys的方法因为底层是用的for in localstorage实现的，性能还是很不错的，20kb存满100条，读写也在1s左右，性能非常不错。

六，总结和对比

模块写完了，我才知道原来还有这么一个库： zendesk/cross-storage

但是我查看了他的api和源代码，对比了一下实现方法，我觉得还是我这个版本考虑的比较多。

1，我的版本对域名和数据的管理有控制。

2，我的版本promise api更简化，比它少一个onConnect，可以参考他的实现，比我写的多多了，也没解决这个iframe等待异步的问题。

3，不支持lz压缩数据。

4，不支持LRU的储存池管理，所以可能存多了造成写不进的问题。

5，他貌似每次交互都搞一个iframe，太浪费dom操作和广播了，我觉得一直开着并没有什么问题，当然他可能有需求连接多个client才这么处理的。

总结

以上所述是小编给大家介绍的使用localstorage代替cookie实现跨域共享数据问题，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对脚本之家网站的支持！

（编辑：ASP站长网）