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

iOS: Browser crashes due to low memory

提问by Marat Faskhiev

My site crashes in the browser due to low memory on iOS. I'm repeating some action which consumes memory. After several attempts, the browser crashes. However, when I tested the same site on my desktop using Chrome by using timelime from dev tools:

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

1. Perform the same action
2. Collect garbage
3. All additionally allocated memory is collected.

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

Why does the browser crash if there are no memory leaks? Is there a way to force garbage collection?

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

回答by Durai Amuthan.H

Know iOS Resource Limits

了解 iOS 资源限制

Your webpage performing well on the desktop is no guarantee that it will perform well on iOS.

您的网页在桌面上运行良好并不能保证它在 iOS 上运行良好。

1.Keep in mind that iOS uses

1.记住iOS使用

• EDGE (lower bandwidth, higher latency)
• 3G (higher bandwidth, higher latency)
• Wi-Fi (higher bandwidth, lower latency)

• EDGE（更低的带宽，更高的延迟）
• 3G（更高的带宽，更高的延迟）
• Wi-Fi（更高的带宽，更低的延迟）

to connect to the Internet.

连接到互联网。

2.You need to minimize the size of your webpage. Including

2.您需要最小化网页的大小。包括

• unused or unnecessary images
• CSS
• JavaScript

• 未使用或不必要的图像
• CSS
• JavaScript

which adversely affects your site's performance on iOS.

这会对您网站在 iOS 上的性能产生不利影响。

3.Because of the memory available on iOS, there are limits on the number of resources it can process:

3.由于iOS上可用的内存，它可以处理的资源数量有限制：

The maximum size for decoded GIF, PNG, and TIFFimages

• 3 megapixelsfor devices with less than 256 MB RAM
• 5 megapixelsfor devices with greater or equal than 256 MB RAM

That is ensure width * height ≤ 3 * 1024 * 1024 for devices with less than 256 MB RAM

Note:that the decoded size is far larger than the encoded size of an image.

The maximum decoded imagesize for JPEG is 32 megapixelsusing subsampling. JPEG images can be up to 32 megapixelsdue to subsampling, which allows JPEG images to decode to a size that has one sixteenth the number of pixels. JPEG images larger than 2 megapixelsare subsampled—that is, decoded to a reduced size. JPEG subsampling allows the user to view images from the latest digital cameras.

解码的GIF、PNG 和 TIFF图像的最大尺寸

• RAM小于256 MB 的设备为3 兆像素
• RAM大于或等于256 MB 的设备为5 兆像素

也就是说，对于小于256 MB RAM 的设备，确保宽度 * 高度 ≤ 3 * 1024 * 1024

注意：解码后的尺寸远大于图像的编码尺寸。

JPEG的最大解码图像大小为 使用二次采样的32 兆像素。由于二次采样，JPEG 图像最高可达32 兆像素，这允许 JPEG 图像解码为像素数的十六分之一的大小。大于 2 兆像素的JPEG 图像 被二次采样，即解码为缩小的尺寸。JPEG 二次采样允许用户查看来自最新数码相机的图像。

4.The maximum size for a canvaselement is

4.canvas元素的最大尺寸是

• 3 megapixelsfor devices with less than 256 MB RAM
• 5 megapixelsfor devices with greater or equal than 256 MB RAM. The height and width of a canvas object is 150 x 300 pixels if not specified.

• RAM 小于 256 MB 的设备为3 兆像素
• 大于或等于 256 MB RAM 的设备为5 兆像素。如果未指定，画布对象的高度和宽度为 150 x 300 像素。

5.JavaScript execution time

5. JavaScript 执行时间

limited to 10 secondsfor each top-level entry point. If your script executes for more than 10 seconds, Safari on iOS stops executing the scriptat a random place in your code, so unintended consequences may result.

每个顶级入口点限制为10 秒。如果您的脚本执行时间超过 10 秒，iOS 上的 Safari 会在您代码中的随机位置停止执行脚本，因此可能会导致意想不到的后果。

6.The maximum number of documentsthat can be open at once is

6.一次可以打开的最大文档数是

• eighton iPhone

• nineon iPad.

• iPhone 上的八

• 九个在 iPad 上。

Please refer Developing Web Content for Safari-Apple Documentationfor more info.

有关更多信息，请参阅为 Safari-Apple 文档开发 Web 内容。

Garbage Collection

垃圾收集

Mobile safari javascript implementation doesn't have any command like CollectGarbage() in internet explorerfor garbage collection.

移动 safari javascript 实现没有任何命令，如Internet Explorer 中的 CollectGarbage()用于垃圾收集。

There are three eventsthat will trigger garbage collection in mobile safari(Reference).

• A dedicated garbage collection timer expires
• An allocation occurs when all of a heap's CollectorBlocks are full.
• An object with sufficiently large associated storage is allocated.

在 mobile safari 中有三个事件会触发垃圾回收（参考）。

• 专用垃圾收集计时器到期
• 当堆的所有收集器块都已满时，就会发生分配。
• 分配了具有足够大的关联存储的对象。

Its really a bad practice to trigger garbage collection.What we should be doing is to write codes that doesn't leak memory.

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

Plese refer Memory management in Javascript

请参考Javascript 中的内存管理

回答by amit_saxena

Below is the best resource (with benchmarks) which I have ever come across, that explains it: http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/

下面是我遇到过的最好的资源（带有基准测试），它解释了它：http: //sealedabstract.com/rants/why-mobile-web-apps-are-slow/

I hit those performance hurdles a few weeks back, and please note that iOS does not have any default garbage collection (the article explains why). It is the responsibility of the app (in this case, the browser app). You cannot collect garbage via your web app. A small tip while optimizing your website for iOS (to prevent crashes): avoid CSS transations.

几周前我遇到了这些性能障碍，请注意 iOS 没有任何默认的垃圾回收（文章解释了原因）。这是应用程序（在本例中为浏览器应用程序）的责任。您无法通过网络应用收集垃圾。为 iOS 优化网站时的一个小技巧（防止崩溃）：避免 CSS 转换。

Though I would recommend that you grab a cup of coffee and read the complete article, but I'll paste the summary below:

虽然我建议你喝杯咖啡阅读完整的文章，但我会粘贴下面的摘要：

• Javascript is too slow for mobile app use in 2013 (e.g., for photo editing etc.).
  
  • It's slower than native code by about 5
  • It's comparable to IE8
  • It's slower than x86 C/C++ by about 50
  • It's slower than server-side Java/Ruby/Python/C# by a factor of about 10 if your program fits in 35MB, and it degrades exponentially from there
• The most viable path for it to get faster is by pushing the hardware to desktop-level performance. This might be viable long-term, but it's looking like a pretty long wait.
• The language itself doesn't seem to be getting faster these days, and people who are working on it are saying that with the current language and APIs, it will never be as fast as native code
• Garbage collection is exponentially bad in a memory-constrained environment. It is way, way worse than it is in desktop-class or server-class environments.
• Every competent mobile developer, whether they use a GCed environment or not, spends a great deal of time thinking about the memory performance of the target device
• JavaScript, as it currently exists, is fundamentally opposed to even allowing developers to think about the memory performance of the target device
• If they did change their minds and allowed developers to think about memory, experience suggests this is a technically hard problem.

• Javascript 对于 2013 年的移动应用程序使用来说太慢（例如，用于照片编辑等）。
  
  • 它比本机代码慢约 5
  • 它与IE8相当
  • 它比 x86 C/C++ 慢约 50
  • 如果您的程序适合 35MB，它比服务器端 Java/Ruby/Python/C# 慢大约 10 倍，并且它从那里呈指数降级
• 让它变得更快的最可行途径是将硬件推向桌面级性能。从长远来看，这可能是可行的，但看起来需要等待很长时间。
• 这些天语言本身似乎并没有变得更快，并且正在研究它的人说，使用当前的语言和 API，它永远不会像本机代码一样快
• 在内存受限的环境中，垃圾收集呈指数级恶化。这比在桌面级或服务器级环境中要糟糕得多。
• 每个有能力的移动开发人员，无论他们是否使用 GCed 环境，都会花费大量时间考虑目标设备的内存性能
• 目前存在的 JavaScript 从根本上反对甚至允许开发人员考虑目标设备的内存性能
• 如果他们真的改变主意并允许开发人员考虑内存，经验表明这是一个技术难题。