iOS：浏览器因内存不足而崩溃

Posted 2023-02-25

【中文标题】iOS：浏览器因内存不足而崩溃

【英文标题】：iOS: Browser crashes due to low memory

【发布时间】：2014-03-29 04:07:11

【问题描述】：

由于 ios 上的内存不足，我的网站在浏览器中崩溃。我正在重复一些消耗内存的操作。多次尝试后，浏览器崩溃。但是，当我使用开发工具中的 timelime 在我的桌面上使用 Chrome 测试同一站点时：

执行相同的操作 收集垃圾 收集所有额外分配的内存。

如果没有内存泄漏，为什么浏览器会崩溃？有没有办法强制垃圾回收？

【参考方案1】：

了解 iOS 资源限制

您的网页在桌面上表现良好并不能保证它在 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 都已满时，就会发生分配。 已分配具有足够大关联存储的对象。

触发垃圾回收确实是一种不好的做法。我们应该做的是编写不泄漏内存的代码。

请参考Memory management in Javascript

【讨论】：

感谢您的回答。我想提一下，根据 Chrome 开发工具，没有内存泄漏。

使用此链接在移动 safari 上进行调试 spiraltrack.com/blog/… 它将为您提供实时结果。

【参考方案2】：

以下是我遇到过的最好的资源（带有基准），它解释了它： 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 从根本上反对甚至允许开发人员考虑目标设备的内存性能 如果他们确实改变主意并允许开发人员考虑内存，经验表明这是一个技术难题。