Javascript iOS 上的移动 Safari 在大页面上崩溃

Mobile Safari on iOS crashes on big pages

提问by Johan Nordberg

I have a problem where Mobile Safari crashes when loading and manipulating the DOM with jQuery when the pages get too big.

我有一个问题，当页面变得太大时，Mobile Safari 在使用 jQuery 加载和操作 DOM 时崩溃。

I get the same problem on both iPhone and iPad.

我在 iPhone 和 iPad 上都遇到了同样的问题。

What are the best way to troubleshoot mobile pages to find the error? Are there any known problems that might crash Mobile Safari?

排除移动页面故障以查找错误的最佳方法是什么？是否存在任何可能导致 Mobile Safari 崩溃的已知问题？

采纳答案by Johan Nordberg

I actually found the problem. It wasn't with JS as I thought, but with the CSS. I added class to make a CSS transition to fade in some elements. For anonymous users these elements had display: none;and probably never ran the opacity transition.

我确实发现了问题。不是像我想的那样使用 JS，而是使用 CSS。我添加了类来使 CSS 过渡淡入某些元素。对于匿名用户，这些元素曾经display: none;并且可能从未运行过不透明度转换。

The strange thing is that the transitions was on exactly two elements. So why would this only crash on long threads with 100+ comments?

奇怪的是，过渡恰好在两个元素上。那么为什么这只会在有 100 多条评论的长线程上崩溃？

So the bottom line is: -webkit-transition crashed the page on mobile safari.

所以底线是：-webkit-transition 使移动 safari 上的页面崩溃。

回答by IndrekV

Had the same issue, for me it was -webkit-transform: translateZ(0);that caused the crash of Safari.

有同样的问题，对我来说是-webkit-transform: translateZ(0);导致 Safari 崩溃的原因。

回答by Mathias

I know this question has been successfully answered but I just wanted to put my five cents in too as I have been banging my head against the wall over this one quite a few times:

我知道这个问题已经被成功回答了，但我也想把我的五分钱放进去，因为我已经多次用头撞墙了：

As most answers have pointed out already it usually comes down to memory issues. Almost anything can be the last bit that finally tips over the "memory pile" much like a translateZor anything else.

正如大多数答案已经指出的那样，它通常归结为内存问题。几乎任何东西都可能是最后一点，就像 atranslateZ或其他任何东西一样，最终翻过“记忆堆” 。

However in my experience it has nothing to do with the actual CSS (or JS) command in specific. It just happens to be that the last transition was one too much.

但是，根据我的经验，它与具体的实际 CSS（或 JS）命令无关。碰巧的是，最后一次过渡太过分了。

What tends to help me a lot is to keep anything that is not visible at this time under display: none. This might sound primitive but actually does the trick. It's a simple way to tell the renderer of the browser that you don't need this element at this time and therefore releases memory. This allows you to create mile long vertical scrollers with all sorts of 3d effects as long as you hide elements that you are not using at this time.

对我有很大帮助的是将此时不可见的任何内容保留在display: none. 这听起来可能很原始，但实际上确实有效。这是告诉浏览器的渲染器您此时不需要此元素并因此释放内存的简单方法。这允许您创建具有各种 3d 效果的一英里长的垂直滚动条，只要您隐藏此时不使用的元素即可。

回答by sergio

The main issue with any iOS app is memory usage. So, it is likely that your pages are using too much memory.

任何 iOS 应用程序的主要问题是内存使用。因此，您的页面很可能使用了过多的内存。

Mobile Safari use some clever technique so that not the whole page has to reside in memory at any given time, only a portion of it. Maybe you could check if anything in your page defeats this mechanism or makes it less effective.

Mobile Safari 使用了一些巧妙的技术，因此在任何给定时间不必将整个页面都驻留在内存中，而只需将其中的一部分驻留在内存中。也许您可以检查页面中是否有任何内容破坏了此机制或使其效率降低。

In any case, to give more up to the point suggestions, more information about your page would be really great.

无论如何，要提供更多切合实际的建议，有关您的页面的更多信息将非常棒。

By the way, you could have some hints from the crash log that the device store. Check to see if you can find it under Settings:

顺便说一下，您可以从设备存储的崩溃日志中获得一些提示。检查是否可以在“设置”下找到它：

1. General
2. About
3. Diagnostics & Usage
4. Diagnostics & Usage Data

1. 一般的
2. 关于
3. 诊断和使用
4. 诊断和使用数据

If it's a memory problem, you should find something like "signal (0)"; not sure if this can only mean "killed due to memory usage", but I usually take this for granted when I found a signal (0).

如果是内存问题，你应该找到类似“信号（0）”之类的东西；不确定这是否只能意味着“由于内存使用而被杀死”，但是当我发现信号（0）时，我通常认为这是理所当然的。

Otherwise, it might tell you what is wrong...

否则，它可能会告诉你哪里出了问题......

Hope this helps.

希望这可以帮助。

回答by Joshua

There are both memory limits and Javascript execution time limits, though it's a little fuzzy as to how you may actually hit those. Common reports come in that a page with a size greater than 10MB will have issues, and Javascript execution is limited to 10 seconds.

有内存限制和 Javascript 执行时间限制，尽管您实际上如何达到这些限制有点模糊。常见的报告是大小大于 10MB 的页面会出现问题，并且 Javascript 执行时间限制为 10 秒。

See Apple's documentationfor more info.

有关更多信息，请参阅Apple 的文档。

回答by Florian

I recently had an issue with mobile safari crashing on web-app pages containing a lot of images (30+ were enough) and a few transformations for the menu. After a lot of trial and error, I settled with a solution similar to what LinkedIndoes, but for infinite scrolling using angularjs. I used requestAnimFrameand two expanding/shrinking divs(with js style attributes) on the top and bottom of the list to remove all image containers (with other stuff overlayed on top) except for a few ones which are close to the viewport. Scrolling performance (native, no js) is fine and memory consumption is in check.

我最近遇到了移动 safari 在包含大量图像（30 多个就足够了）和一些菜单转换的 Web 应用程序页面上崩溃的问题。经过大量的反复试验，我找到了一个类似于LinkedIn的解决方案，但使用 angularjs 进行无限滚动。我在列表的顶部和底部使用requestAnimFrame和两个扩展/收缩 div（具有 js 样式属性）来删除所有图像容器（顶部覆盖其他内容），除了一些靠近视口的图像容器。滚动性能（原生，无 js）很好，内存消耗得到控制。

回答by Matteo Conta

I had a similar problem, the web page worked like a charm on android devices and crashed on IOS (iphone and simulator).

我遇到了类似的问题，该网页在 android 设备上运行良好，但在 IOS（iphone 和模拟器）上崩溃了。

After a lot of research (using also the ios_webkit_debug_proxy) I found that the problem was connected to the jQuery ready event.

经过大量研究（也使用 ios_webkit_debug_proxy），我发现问题与 jQuery 就绪事件有关。

Adding a little timeout solved the problem. My application was also using iframes.

添加一点超时解决了问题。我的应用程序也在使用 iframe。

$(document).ready(function () {
    window.setTimeout(function () { ready(); }, 10);
});