由于iOS内存不足，我的网站在浏览器中崩溃。我正在重复一些消耗内存的操作。经过多次尝试后，浏览器崩溃了。然而，当我使用Chrome在台式机上使用dev工具的timeline测试同样的网站时:
- 执行相同的操作
- 收集垃圾
- 所有额外分配的内存都已被回收。
如果没有内存泄漏，为什么浏览器会崩溃？有没有办法强制进行垃圾回收？
iOS：浏览器由于内存不足而崩溃
17
- Marat Faskhiev
2个回答
29
了解 iOS 资源限制
你的网页在桌面上表现良好并不意味着它在 iOS 上也会表现良好。
1.请记住，iOS 使用以下方式连接到互联网：
- EDGE（较低带宽、较高延迟）
- 3G（较高带宽、较高延迟）
- Wi-Fi（较高带宽、较低延迟）
2.你需要尽量减小网页的大小，包括：
- 未使用或不必要的图片
- CSS
- JavaScript
这些都会对 iOS 上的网站性能产生负面影响。
3.由于 iOS 可用的内存有限，因此它可以处理的资源数量也有限：
解码后的 GIF、PNG 和 TIFF 图像的最大尺寸：
- 对于内存小于 256 MB 的设备，最大尺寸为 3 百万像素
- 对于内存大于等于 256 MB 的设备，最大尺寸为 5 百万像素
因此，对于内存小于 256 MB 的设备，确保宽度*高度 ≤ 3 * 1024 * 1024
注意：解码后的图像尺寸远大于编码后的图像尺寸。
使用子采样，JPEG 的 最大解码图像尺寸 为 32 百万像素。JPEG 图像可以达到 32 百万像素，因为子采样允许 JPEG 图像解码为具有 1/16 像素数的尺寸。大于 2 百万像素 的 JPEG 图像会被进行子采样处理，即解码为缩小的尺寸。JPEG 子采样使用户能够查看来自最新数码相机的图像。
4. 画布元素的最大尺寸 为
- 对于少于256 MB RAM的设备，分辨率为3百万像素
- 对于等于或大于256 MB RAM的设备，分辨率为5百万像素。 如果没有指定，canvas对象的高度和宽度为150 x 300像素。
5. JavaScript执行时间
每个顶级入口点的执行时间限制为10秒。如果您的脚本执行时间超过10秒，则iOS上的Safari会在您的代码中随机停止执行脚本，因此可能会导致意外后果。
6. 可同时打开的最大文档数为
请参考为Safari开发Web内容-苹果文档以获取更多信息。
iPhone上为8个
iPad上为9个
垃圾回收
移动版Safari的JavaScript实现没有类似于Internet Explorer中的CollectGarbage()命令进行垃圾回收。
以下是翻译内容：移动版Safari浏览器中有三个事件会触发垃圾回收（参考）。
- 专门的垃圾回收计时器到期
- 当堆的所有CollectorBlock都已满时分配内存
- 分配具有足够大关联存储空间的对象。
触发垃圾回收实际上是一种不好的做法。我们应该编写不会泄漏内存的代码。
请参考JavaScript中的内存管理。- Durai Amuthan.H
2
谢谢您的回答。我想提一下，根据Chrome Dev Tools，没有内存泄漏。 - Marat Faskhiev
使用此链接在移动Safari上进行调试：http://www.spiraltrack.com/blog/how-debug-iphone-and-ipad-web-applications-using-safari，它将为您提供实时结果。 - Durai Amuthan.H
5
以下是我曾经遇到的最好的资源（带有基准测试），它解释了为什么移动Web应用程序很慢：http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/
我在几周前遇到了这些性能障碍，请注意iOS没有任何默认的垃圾收集器（文章解释了原因）。这是应用程序（在本例中是浏览器应用程序）的责任。您无法通过Web应用程序收集垃圾。一个小提示：在优化iOS网站时（以防止崩溃），请避免使用CSS转换。
虽然我建议您喝杯咖啡并阅读完整的文章，但我将在下面粘贴摘要：
JavaScript在2013年的移动应用程序使用中太慢了（例如，用于照片编辑等）。比本地代码慢约5倍，与IE8相当，比x86 C / C ++慢约50倍，如果您的程序适合35MB，则比服务器端Java / Ruby / Python / C＃慢10倍，并且从那里呈指数级下降。
让它变得更快的最可行的方法是将硬件推向桌面级别的性能。这可能是长期可行的，但看起来需要很长时间。
语言本身似乎在这些日子里没有变得更快，而且正在处理它的人们正在说，在当前的语言和API方面，它永远不会像本地代码一样快。
在内存受限制的环境中，垃圾收集呈指数级恶化。它比桌面级或服务器级环境中的情况要糟糕得多。
每个称职的移动开发人员，无论他们是否使用GCed环境，都会花费大量时间思考目标设备的内存性能。
JavaScript，如其当前存在，从根本上反对甚至允许开发人员考虑目标设备的内存性能。
如果他们改变主意并允许开发人员考虑内存，则经验表明这是一个技术难题。
虽然我建议您喝杯咖啡并阅读完整的文章，但我将在下面粘贴摘要：
JavaScript在2013年的移动应用程序使用中太慢了（例如，用于照片编辑等）。比本地代码慢约5倍，与IE8相当，比x86 C / C ++慢约50倍，如果您的程序适合35MB，则比服务器端Java / Ruby / Python / C＃慢10倍，并且从那里呈指数级下降。
让它变得更快的最可行的方法是将硬件推向桌面级别的性能。这可能是长期可行的，但看起来需要很长时间。
语言本身似乎在这些日子里没有变得更快，而且正在处理它的人们正在说，在当前的语言和API方面，它永远不会像本地代码一样快。
在内存受限制的环境中，垃圾收集呈指数级恶化。它比桌面级或服务器级环境中的情况要糟糕得多。
每个称职的移动开发人员，无论他们是否使用GCed环境，都会花费大量时间思考目标设备的内存性能。
JavaScript，如其当前存在，从根本上反对甚至允许开发人员考虑目标设备的内存性能。
如果他们改变主意并允许开发人员考虑内存，则经验表明这是一个技术难题。
- amit_saxena
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接