为什么简单的网站在移动设备（至少是 iOS Safari 和 Chrome）上会崩溃？

我有一个非常简单但又很长的网站——有很多可以滚动浏览的文本。这是一个文档网站，考虑到内容的性质（很多简短的相似条目），我决定立即显示所有内容，因此用户可以从一个条目滚动到另一个条目，也可以通过侧边栏索引进行导航。这是我喜欢的常见文档模型（例如下划线 http://underscorejs.org/, Backbone http://backbonejs.org/, and LoDash http://lodash.com/docs).

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

问题是这样的：对于许多用户来说，该网站经常导致他们的 iOS 浏览器崩溃。不是所有用户（不是我）；但对于那些do经历过崩溃，它似乎不断重复发生。 （该网站也可能会导致某些人的 Android 手机崩溃，我不知道：没有收到任何 Android 用户的消息。）我希望有人可以帮助我诊断并可能解决这个问题。

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

我不确定接下来要尝试什么，我希望一些精明的 StackOverflow 高手能提供建议。这个在我看来如此简单和基本的网站到底是怎么回事，却使它如此占用内存以至于导致浏览器崩溃？

是不是太长了？是否存在 CSS 太难渲染的情况？ JavaScript 是否存在内存泄漏？

我对这个特定的网站很感兴趣，这样我就可以学习预测和预防和/或诊断和修复未来其他网站上的类似问题。

欢迎查看或贡献[Github问题](在这个 Github 问题中 https://github.com/davidtheclark/scut/issues/110，还有。

Addendum

以下是有关该网站可能相关的一些信息：

• HTML 文档是large相对于其他网站的 HTML 文档。未缩小时看起来约为 225KB。 （我注意到 LoDash 文档更大——该网站会让人们的手机崩溃吗？）
• 所提供的 HTML 文档已缩小。
• 服务的 CSS 和 JS 也被缩小。
• 该网站使用Prism.js http://prismjs.com/用于语法突出显示。
• 该网站使用推翻 https://github.com/filamentgroup/Overthrow使 2 滚动列布局适用于平板电脑。
• <aside id="help-content">在屏幕外进行固定和翻译；当您单击 [?] 时，它会滑入，就像任何实用程序的“使用名称”一样。

iOS 崩溃日志

在我看来，这些是来自运行 Chrome 并在网站上崩溃的 iPhone 的崩溃报告的潜在相关行（我不确定它们是否真正相关，因为我还没有开发过 iOS 应用程序，也不知道这些报告的细节）：

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)

我想我修好了！

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

我认为绝对定位在屏幕的一角堆积了大量的内容，虽然不可见，但它对内存的要求很高。

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

对我有很大帮助的是，将此时不可见的任何内容保留在显示状态下：无。这听起来可能很原始，但确实有效。这是一种简单的方法，可以告诉浏览器的渲染器您此时不需要该元素，从而释放内存。只要隐藏当前不使用的元素，您就可以创建具有各种 3D 效果的一英里长的垂直滚动条。

我认为我的另一种隐藏方法是not释放内存，尽管它有其他优点（无论如何可能与这个特定站点无关）。我确信这只是因为该网站太长而成为一个问题。

不过，当您想隐藏某个元素时，需要考虑这一点：渲染/内存需求.