由于 iOS 上的内存不足，我的网站在浏览器中崩溃。我正在重复一些消耗内存的操作。多次尝试后，浏览器崩溃。但是，当我使用开发工具中的 timelime 在我的桌面上使用 Chrome 测试同一站点时：
如果没有内存泄漏，为什么浏览器会崩溃？有没有办法强制垃圾回收？
【问题讨论】：
标签： javascript html ios google-chrome memory-leaks
您的网页在桌面上表现良好并不能保证它在 iOS 上表现良好。
1.记住iOS使用
- EDGE（更低的带宽，更高的延迟）
- 3G（更高的带宽，更高的延迟）
- Wi-Fi（更高带宽、更低延迟）
连接到互联网。
2.您需要最小化您的网页大小。 包括
- 未使用或不必要的图像
- CSS
- JavaScript
这会对您的网站在 iOS 上的性能产生不利影响。
3.由于iOS上的可用内存，它可以处理的资源数量有限制：
解码后的 GIF、PNG 和 TIFF 图像的最大尺寸
- 3 兆像素 适用于小于 256 MB RAM 的设备
- 5 兆像素 适用于大于或等于 256 MB RAM 的设备
对于小于 256 MB RAM
的设备，确保宽度 * 高度 ≤ 3 * 1024 * 1024注意：图像的解码尺寸远大于编码尺寸。
JPEG 的最大解码图像大小为 32 兆像素 二次抽样。由于以下原因，JPEG 图像最高可达 32 兆像素 二次采样，它允许 JPEG 图像解码为具有 one 的大小 第十六像素数。 JPEG 图像大于 2 兆像素 被二次采样——也就是说，被解码为一个减小的大小。 JPEG 二次采样 允许用户查看来自最新数码相机的图像。
4.画布元素的最大尺寸是
- 3 兆像素 适用于 RAM 小于 256 MB 的设备
- 5 兆像素 适用于 RAM 大于或等于 256 MB 的设备。 如果未指定，画布对象的高度和宽度为 150 x 300 像素。
5.JavaScript 执行时间
每个顶级入口点限制为 10 秒。如果你的脚本 执行超过 10 秒，iOS 上的 Safari 停止执行 脚本在您的代码中的随机位置，所以意想不到的后果 可能会导致。
6.一次可以打开的最大文档数是
八个在 iPhone 上
九在 iPad 上。
更多信息请参考Developing Web Content for Safari-Apple Documentation。
移动 safari javascript 实现没有任何类似 Internet Explorer 中的 CollectGarbage() 的命令 用于垃圾收集。
有三个事件会触发垃圾回收 移动狩猎(Reference)。
- 专用垃圾收集计时器到期
- 当所有堆的 CollectorBlock 都已满时，就会发生分配。
- 已分配具有足够大关联存储的对象。
触发垃圾回收确实是一种不好的做法。我们应该做的是编写不泄漏内存的代码。
【讨论】：
以下是我遇到过的最好的资源（带有基准），它解释了它： http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/
几周前我遇到了这些性能障碍，请注意 iOS 没有任何默认的垃圾收集（文章解释了原因）。这是应用程序（在本例中为浏览器应用程序）的责任。您不能通过您的网络应用程序收集垃圾。为 iOS 优化您的网站时的一个小技巧（以防止崩溃）：避免 CSS 转换。
虽然我建议您喝杯咖啡并阅读完整的文章，但我将在下面粘贴摘要：
- 对于 2013 年的移动应用（例如，用于照片编辑等）而言，Javascript 太慢了。
- 比原生代码慢 5 左右
- 媲美IE8
- 它比 x86 C/C++ 慢了大约 50
- 如果您的程序适合 35MB，它比服务器端 Java/Ruby/Python/C# 慢大约 10 倍，并且从那里呈指数级下降
- 让它变得更快的最可行途径是将硬件提升到桌面级性能。这可能是长期可行的，但看起来需要等待很长时间。
- 如今，语言本身似乎并没有变得越来越快，而正在研究它的人说，使用当前的语言和 API，它永远不会像原生代码那样快
- 垃圾收集在内存受限的环境中呈指数级恶化。这比在桌面级或服务器级环境中要糟糕得多。
- 每个称职的移动开发人员，无论他们是否使用 GCed 环境，都会花费大量时间考虑目标设备的内存性能
- 目前存在的 JavaScript 从根本上反对甚至允许开发人员考虑目标设备的内存性能
- 如果他们确实改变主意并允许开发人员考虑内存，经验表明这是一个技术难题。
【讨论】：