Greasy Fork

关于新功能【压缩缓存】解决的问题以及相关的注意事项

在release log里写了这个问题但可能用户不太理解为什么需要这个功能，因此在这里讲解一下。

背景：

近期有用户反馈特定站点翻译忽然全部错误，无法翻译，但其他站点正常，要求截图控制台后发现有以下报错

DOMException: Failed to execute 'setItem' on 'Storage': Setting the value of '谷歌翻译mobile-Solid updates as always Jave ' exceeded the quota.

因此确认这个问题是写入缓存失败，缓存大小达到上限。

修复方式：重启浏览器后反馈正常

第一次碰到这个问题，查询后才了解sessionStorage本身是有存储上限的，在2.5-10m左右，那么考虑2.5m的话也仅能存储约87.4w的中文字符，在某些特定场景下会达到上限，例如：一次性在同一站点查看大量文章,长期不关浏览器(sessionStorage在关闭浏览器后自动清空)。以上情况就会导致缓存写满。

考虑这个情况因此做了压缩缓存的功能，使用lz-string压缩打包到同一个object的缓存，简单测试下可以压缩50%以上的空间，同时随着总缓存越来越大，压缩比例也会越来越高。但同时也会带来的负面作用是会带来潜在的性能损耗，这里我没有进行仔细的测试，感兴趣的朋友可以测试下并把结果也分享下，不过想来频繁对几m大小的json进行stringify应该会有一些用户体验的影响。当然这里后续加个小小的优化，改为异步操作。

综上所述，添加了这个功能来缓解这个问题，是的，只能缓解，只是上限应该能翻好几倍，根治的方法还得是清理缓存，也就是重启下浏览器就ok。

Q: 为什么不使用indexedDB

A: indexedDB固然好用，但是没有比较好的方式确定什么时候进行清理，如果不清理必然会达到写满的状态，所以使用浏览器来控制清理策略的sessionStorage更好。