虽然在某些浏览器上可能可行,但正确的方法应该是确定典型客户可接受的限制,并可选择提供 UI 来定义其限制。
大多数重型 Web 应用程序的 JavaScript 堆大小约为 10MB。似乎没有指南。但我认为在桌面上消耗超过 100MB,在移动设备上消耗超过 20MB 并不是很好。对于此后的所有内容,请查看本地存储,例如文件系统API http://www.html5rocks.com/en/tutorials/file/filesystem/(你完全可以让它持久)
UPDATE
这个答案背后的原因如下。几乎没有用户只运行一个应用程序。更重要的是指望浏览器只打开一个选项卡。最终,消耗所有可用内存从来都不是一个好的选择。因此没有必要确定上限。
用户想要分配给网络应用程序的合理内存量是一个猜测工作。例如。高度交互的数据分析工具在 JS 中是完全可能的,并且可能需要数百万个数据点。一种选择是默认使用较低的分辨率(例如,每天而不是每秒测量)或较小的窗口(一天与十年的秒)。但随着用户不断探索数据集,将需要越来越多的数据,这可能会削弱代理端的底层操作系统。
好的解决方案是采用一些合理的初始假设。我们打开一些流行的Web应用程序,进入开发工具-配置文件-堆快照看一下:
- 脸书:18.2 MB
- G 邮件:33 MB
- 谷歌+:53.4 MB
- YouTube:54 MB
- 必应地图:55 MB
注意:这些数字包括堆上的 DOM 节点和 JS 对象。
似乎从那时起,人们开始接受 50MB RAM 来构建一个有用的网站。(2022 年更新:现在平均接近 100MB。)构建 DOM 树后,用测试数据填充数据结构,并查看 RAM 中可以保留多少数据。
顺便说一句,在 Chrome 中启用设备模拟时使用类似的测量方法,可以看到平板电脑和手机上相同网站的使用情况。
这就是我在桌面上获得 100 MB 以及在移动设备上获得 20 MB 的方法。似乎也有道理。当然,对于偶尔的重度用户来说,如果能够选择将最大堆增加到 2 GB,那就太好了。
现在,如果每次从服务器提取所有这些数据成本太高,您该怎么办?
一件事是使用应用程序缓存。它确实会造成轻微的版本管理麻烦,但允许您存储大约 5 MB 的数据。不过,将应用程序代码和资源保存在其中比存储数据更有用。
除此之外,我们还有三个选择:
-
SQLite https://caniuse.com/sql-storage -
support was limited and it seems to be abandoned
- IndexDB - better option
but support is not universal yet (can I use it?) http://caniuse.com/indexeddb
- 文件系统API http://www.html5rocks.com/en/tutorials/file/filesystem/
Of them, FileSystem is most supported and can use sizable chunk of storage http://www.html5rocks.com/en/tutorials/offline/quota-research/.