为什么简单的网站会在移动设备上崩溃(至少是 iOS Safari 和 Chrome)? [英] Why does simple website crash on mobile (iOS Safari and Chrome, at least)?

问题描述

我有一个非常简单但很长的网站——有很多可以滚动浏览的文本.这是一个文档站点，考虑到内容的性质(很多类似的简短条目)，我决定一次显示所有内容，以便用户可以从一个条目滚动到另一个条目，或者通过侧边栏索引导航.这是我喜欢的常见文档模型(例如 Underscore、Backbone 和 LoDash).

网站在这里:http://davidtheclark.github.io/scut/.您可以在此处查看预生产代码:https://github.com/davidtheclark/scut/tree/master/docs/dev.

这就是问题所在:对于一些用户来说，这个网站总是让他们的 iOS 浏览器崩溃.不是所有用户(不是我)；但对于那些确实经历过崩溃的人来说，它似乎一直在重复发生.(该网站也可能会导致某些人的 Android 手机崩溃，我不知道:没有收到任何 Android 用户的消息.)我希望有人可以帮助我诊断并可能解决这个问题.p>

我遇到的部分困难是我自己无法重现崩溃——不是在我自己的 iOS 设备上，也不是在 Xcode 模拟器上.因为该站点根本不占用大量资源(大约 70KB 负载)并且涉及的 JavaScript 很少，并且由于之前尝试解决此问题的一些影响，我猜测问题涉及内存使用em> -- iOS 浏览器正在崩溃，因为该站点需要太多内存.但我不确定确定这是问题所在，如果是，我不确定如何解决.

我不确定接下来要尝试什么，我希望一些精明的 StackOverflow 高手能给点建议.这个网站在我看来如此简单和基本，是什么让它如此需要内存以致浏览器崩溃?

是不是太长了?是否存在难以渲染的 CSS?是否存在 JavaScript 内存泄漏?

我感兴趣既是为了这个特定的网站，也是为了学习在未来预测和预防和/或诊断和修复其他网站上的类似问题.

欢迎查看或参与 [Github 问题](在此 Github 问题中).

附录

以下是有关该网站的一些相关信息:

• HTML 文档相对于其他网站的 HTML 文档大.未缩小的它看起来约为 225KB.(我注意到 LoDash 文档更大——该网站会导致人们的手机崩溃吗?)
• 提供的 HTML 文档已缩小.
• 提供的 CSS 和 JS 也被缩小.
• 该网站使用 Prism.js 进行语法高亮显示.
• 该网站使用 Overthrow 使 2-scrolling-columns 布局在平板电脑上工作.
• <aside id="help-content"> 已修复并在屏幕外翻译；当您单击 [?] 时，它会滑入，例如任何实用程序的使用名".

iOS 崩溃日志

在我看来，这些可能是来自运行 Chrome 并在网站上崩溃的 iPhone 的崩溃报告的潜在相关行(我不确定它们是否真的相关，因为我还没有开发 iOS 应用程序并且不知道'不知道这些报告的来龙去脉):

免费页面:5674活动页面:117674非活动页面:55121投机页面:3429限制页面:0可清除页面:0有线网页:60906文件支持的页面:23821匿名页面:152403压缩:356216减压:121241压缩机尺寸:16403Compressor 中的未压缩页面:49228最大的进程:铬[...]铬<2a759438c2253e3baededaa0d13feb56>166479 166479 200 [per-process-limit](最前面)(简历)

解决方案

我想我修好了！

怀疑是由 CSS 布局引起的渲染/绘画问题.在手机大小的情况下，我一直隐藏每个条目的内容，直到它被选中；以及我一直用来隐藏它们并从布局中删除它们的任何痕迹的方法，包括 position: absolute.我最初并没有使用 display: none ，因为出于各种读者和原因，我通常担心不想看到内容但将其保留在那里.我把这些顾虑放在一边，改变了布局，以便用 display: none 隐藏条目并用 display: block 显示——这似乎已经修复了崩溃.

我认为绝对定位是在屏幕一角堆积了大量的内容，虽然看不到，但对内存的要求很高.

让我尝试这个是另一个相关问题的答案，由@tea_totaler 链接到上面:https://stackoverflow.com/a/14866503/2284669.它说:

<块引用>

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

我认为我的另一种隐藏方法是不释放内存，尽管它有其他优点(无论如何可能与这个特定站点无关).我敢肯定，这只是因为网站太长了.

不过，当您想要隐藏元素时，需要考虑以下几点:渲染/内存需求.

I have a website that is very simple, but very long -- a lot of text that could be scrolled through. It's a documentation site, and considering the nature of the content (a lot of short similar entries) I decided to show everything at once, so the user could either scroll from entry to entry or navigate via a sidebar index. It's a common documentation model that I like (e.g. Underscore, Backbone, and LoDash).

The site is here: http://davidtheclark.github.io/scut/. You could look at the pre-production code here: https://github.com/davidtheclark/scut/tree/master/docs/dev.

And here's the problem: For a number of users this site consistently crashes their iOS browsers. Not all users (not me); but for those that do experience the crash, it seems to recur consistently. (The site may also crash some people's Android phones, I don't know: haven't heard from any Android users.) I am hoping someone can help me diagnose and possibly fix this problem.

Part of the difficulty I have is that I cannot reproduce the crash myself -- not on my own iOS devices, not on the Xcode simulators. Because the site is not at all resource-heavy (~70KB load) and involves very little JavaScript, and because of the effects of a few prior attempts to fix this, I'm guessing that the problem involves memory usage -- that iOS browsers are crashing because the site is demanding too much memory. But I'm not sure that's the issue, and if it is I'm not sure how I can fix it.

I'm not sure what to try next, and I'm hoping some savvy StackOverflow whizzes have advice. What is it about this site, which seems so simple and basic to my eyes, that is making it so memory-demanding that it is crashing browsers?

Is it just too long? Is there CSS that is too difficult to render? Are there JavaScript memory leaks?

I'm interested both for the sake of this particular site and so that I can learn to anticipate-and-prevent and/or diagnose-and-fix similar problems on other sites in the future.

Feel free to look at or contribute to [the Github issue](in this Github issue, as well.

Addendum

Here are some things to know about the site that might be relevant:

• The HTML doc is large relative to other sites' HTML docs. Unminified it looks to be ~225KB. (I notice that LoDash docs are even bigger -- does that site crash people's phones?)
• The served HTML doc is minified.
• Served CSS and JS are also minified.
• The site uses Prism.js for syntax highlighting.
• The site uses Overthrow to make the 2-scrolling-columns layout work on tablets.
• <aside id="help-content"> is fixed and translated off-screen; it slides in when you click a [?] like the one by any utility's "use-name".

An iOS Crash Log

These look to me to be the potentially relevant lines of a crash report from an iPhone running Chrome and crashing on the site (I'm not sure whether they are actually relevant or not because I haven't developed iOS apps and don't know the ins-and-outs of these reports):

Free pages:                              5674
Active pages:                            117674
Inactive pages:                          55121
Speculative pages:                       3429
Throttled pages:                         0
Purgeable pages:                         0
Wired pages:                             60906
File-backed pages:                       23821
Anonymous pages:                         152403
Compressions:                            356216
Decompressions:                          121241
Compressor Size:                         16403
Uncompressed Pages in Compressor:        49228
Largest process:   Chrome

[...]

Chrome <2a759438c2253e3baededaa0d13feb56>       166479           166479  200  [per-process-limit] (frontmost) (resume)

解决方案

I think I fixed it!

The problem, as suspected, was rendering/painting caused by CSS layout. At phone-size, I had been hiding the content of each entry until it was selected; and the method I had been using to hide them, and remove any trace of them from the layout, included position: absolute. I didn't initially use display: none because of typical concerns about wanting to not see content but keep it there, for various readers and reasons. I threw those concerns aside and changed the layout so that the entries were hidden with display: none and shown with display: block -- and that seems to have fixed the crashing.

I think the absolute positioning was stacking a huge amount of content in the corner of the screen, and although it wasn't visible, it was demanding memory.

What clued me in to trying this was an answer to another related question, linked to above by @tea_totaler: https://stackoverflow.com/a/14866503/2284669. It says:

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.

I think that my other hiding method was not releasing memory, despite its other advantages (which were possibly irrelevant to this particular site anyway). I'm sure it became a problem only because the site was so long.

That's something to consider, though, when you want to hide an element: rendering/memory demands.

这篇关于为什么简单的网站会在移动设备上崩溃(至少是 iOS Safari 和 Chrome)?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！