新设计发布后，最令人沮丧的事情之一是，公告博客文章会导致某些移动设备上的 Safari 崩溃。 它会使我的 iPhone 4S 崩溃，我听说有报告称它使其他 Android 设备崩溃，但它不会使我的 iPad 2 崩溃。 在移动设备上进行调试已经很难，但调试导致整个应用程序崩溃的页面则更加困难。
当然，我创建了 简化测试用例！
我的过程是复制导致崩溃的页面，然后逐步删除内容，直到找到不再崩溃的位置。 我最终删除了评论线程中的一个注释，它就不再崩溃了。 这两个文档代表着我所能得到的临界点。 它们都已删除所有 JavaScript。 它们都使用完全相同的 CSS。
以下是关于这两个文档的一些详细信息。
| 会崩溃 | 不会崩溃 | |
|---|---|---|
| 文档大小（未解压缩） | 131K | 123K |
| 文档大小（压缩） | 20.21K | 19.55K |
| 请求数量 | 98 | 92 |
| 总页面大小 | 1.42MB | 1.40MB |
另一个重要细节：如果您隐藏其中任何一个的评论部分，它就不会崩溃。
这就是我在实时网站上采取的权宜之计。 您可以点击“查看评论”按钮来显示评论线程。 如果您点击此处这篇文章，它就会崩溃。
仅仅因为元素被隐藏并不意味着它们不在 DOM 中，所以我们可能可以排除 DOM 大小作为崩溃因素。
让所有评论都可见，确实会使用更多内存（可能多很多），而且还会使页面高度变得非常高。
另一个相关事实：删除 CSS 会停止崩溃。 CSS 未压缩时只有 37K，压缩后只有 7.32K。 不过，它确实包含一些 CSS3 内容，如渐变和盒阴影。
为什么我要发布这个？
科学！ 我想让更多人看到这些简化的测试用例，看看我们是否可以进一步简化它们，并发现这个问题的根本原因。 用一些非常简单的 HTML 和 CSS 就可以让移动 WebKit 崩溃，这真是令人沮丧。 也许问题非常简单，然后我们可以广而告之。 出于我自己的目的，我可以修复这个该死的崩溃问题，而不必诉诸诸如分页评论之类的解决方案，我真的希望避免这种情况。
Chris，只是想告诉你，在 iOS 6（测试版）Safari 和/或 Chrome 中，加载评论时不会崩溃。
不过有一点需要注意，如果评论者姓名太长，会导致页面布局出现变形。 不知道这是否会导致麻烦，因为它实际上是围绕单个评论调整所有内容的大小？
图片：http://d.pr/i/NOLJ
{
word-wrap: break-word;
}
FYI：每个版本之间存在一些差异。 在 Chrome 中加载这两个页面，并留意滚动条。 在它们之间切换标签。 从外观上看，其中一个页面包含一些另一个页面没有的内容。
我想进一步调试，但页面太长，要找出差异，需要滚动太多内容。
是的，这就是差异所在。 在不会崩溃的版本中，我从页面中删除了一个额外的评论。
使用 WinMerge 进行比较更快 - 文件除了 yes-crash 在第 1359-1475 行之间多了一块代码外，其他部分完全相同。 因此，问题很可能出在这 110 行左右的代码中。
它还包括使用 gravatars，就像 andyunleashed 在后面的帖子中提到的那样。
我首先尝试的是完全删除评论部分，然后重新测试看看它是否还会崩溃。 我猜想那里可能存在一些奇怪的东西。
如果您删除评论部分，它就不会崩溃。 这就是问题的核心所在。 一个额外的评论会导致崩溃与不崩溃之间的临界点。
您可能还想尝试对您的 iPhone 进行恢复出厂设置和重新加载。 我几个月前在测试一款产品的 Beta 版本时，它经常会在我的 iPad 上意外崩溃。 经过一番排查，我发现移动 Safari 也会这样做，但重置和重新加载应用程序似乎修复了这个问题。 它可能无法解决所有情况，但修复了我的情况。
据我们所知，安装和删除应用程序而没有偶尔进行重置，实际上会导致内存碎片化（就像硬盘驱动器曾经那样），从而导致没有适当的退出和保护措施的情况下出现崩溃。
我完全支持这种解决方案，但在这种情况下，它不仅限于我的手机，还有很多人在各种设备上报告了这个问题。
顺便说一下 - Chris，如果您的 iPhone 上也出现了这种情况，请转到设置 > 关于 > 诊断与用量（底部）> 诊断与用量数据。 在这里查找 Safari 崩溃报告，其中应该包含有关确切原因的详细信息。
非常有趣。
这似乎是相关的崩溃报告：https://gist.github.com/3691938
错误截图：http://cl.ly/JLo2
崩溃报告中的“抛弃”表示它被 iOS 终止 - 基本上，最有可能的原因是为了释放内存。
“计数”是内存页数，因此在本例中，12131*4(kb)/1024 = 47.38MB 的内存正在使用。
现在，为什么它要使用 47.38MB 的内存来加载页面 - 我不知道！
刚刚找到了这个，可能相关 - http://stackoverflow.com/questions/11462691/rapidly-setting-image-srcs-with-dataurl-causes-memory-leak
您是否在评论中使用数据 URL 加载图像？
您是否尝试过禁用 gravatar，看看是否有影响？
它在 Android 版 Chrome 18 和 Android 原生浏览器（在 Galaxy Note，4.0.4 上）中运行良好。
页面很长，可能超出了移动浏览标准，但它加载正常。
（另外，在 Windows XP 上的 Chrome 23 开发版中，“提交评论”按钮的文本看起来很糟糕。）
嗨，Chris，
如果让我猜，我会同意 @andyunleash 的观点。 当我第一次从 iPhone 4S 上访问重新设计的网站时，它确实使我的浏览器崩溃。 您是否可以尝试通过向工作版本添加元素（最好不要添加到评论部分，因为您已经将其隔离为导致问题的部分）来强制浏览器崩溃。 现在，如果它是一个内存问题，增加文档大小肯定会导致它崩溃吗？ 如果在评论部分之外增加 DOM 大小不会导致浏览器崩溃，那么您的问题就出在评论中了。
您网站的缓存方式是否会影响移动浏览器？ 我知道它们处理这些事情的方式不同。
只是想说一下，菜单在 Windows（我的 Mac 在家）Safari 5.1.7 中也会出现问题（当你缩小时，最后两个菜单项会被切断）。
我知道这与这个问题毫无关系，但我只是想告诉你，因为你正在尝试调试…
在 Windows 7 机器上，Chrome 21 在拖动和调整窗口大小时也会崩溃。 只是想让你知道。
奇怪的是，我无法在我的 Win7 机器上的 Chrome 21 中重现这个问题？
Chrome 21.0.1180.89 m 在快速/剧烈调整大小的情况下会挂起标签，尽管它可以关闭。
我也不敢说我很喜欢调整浏览器窗口时整个页面会调整大小/缩放。
嗨，Chris,
在我的 Samsung Galaxy S 2 上的移动 Chrome 上，页面不会崩溃。
在我的 iPhone 4s 上使用 iOS5.1 浏览网站，没有任何问题，目前仍然有 120mb/s 的内存可用。
哦！在我的运行 Android Jelly Beam 的 Nexus 7 上，它在使用 Chrome 时不会崩溃。但是，在键入此评论时，它会突然运行得非常非常慢！可能是某个脚本搞砸了？我认为是评论预览。
您是否尝试过 *减少* 您的 CSS，而不是完全移除它？例如，从移除过渡开始，然后移除渐变，然后移除媒体查询，然后移除一半的样式表，然后移除另一半，等等。好吧，您应该知道这一点。 ;-)
我注意到在我的 17 英寸 Macbook Pro 上，移除 .page-wrap::before、.page-wrap::after 上的阴影，性能有相当大的提升。
我之前看到滚动卡顿，打字延迟，当你移除它后，这些问题都消失了。
过度使用阴影会导致渲染问题。特别是当与过渡和动画绑定时。
实际上我刚刚发现了这个：cubiq，上面说阴影会对视网膜显示屏产生特别糟糕的影响。
在不查看页面，而且坦白地说，只是粗略地浏览了这篇文章，我敢打赌 1 美元，这是一个内阴影问题。您在任何地方使用内阴影吗？
在我的 Windows Phone 7.5/IE9 上，它没有崩溃。但是评论部分加载有点慢。向下滚动时，广告的部分会短暂地与评论重叠，持续 1-2 秒，然后调整好。在大约 20-30 秒后，这种情况会停止发生（一旦所有内容都加载到内存中，我怀疑）。
无关观察：导航的图标字体没有加载。我在图标位置看到的是大写字母（几乎触及按钮的顶部和底部），用 Segoe UI Light 设置，符号是：k、9、Q、p、q、ó、w、6。另外偶尔，点击“导航和搜索”会直接跳到某个链接（两次到图库，一次到论坛）。也许我只是无意中点了两次，无法可靠地重现。
我在 iPad 和长论坛主题上遇到了类似的问题。仍然存在一些问题，但没有那么严重。但我确实发现使用 -webkit-transform 淡入单个按钮会导致网站崩溃。
我仍然不知道为什么这只会在我有 100 多条评论时导致浏览器崩溃。
如果有一个解决方案，最好在 Twitter 上发布，或者写一篇新的博文。
该网站在我的 iPhone 4S（Safari）上运行良好，我还检查了 iOS Chrome，它在那里也运行良好！
您是否尝试过使用 backface-visibility？
只需阅读并遵循文章 :)
我今天也遇到了我的移动 Safari（iPhone 4s/iPad3 最新 iOS）在使用长页面时崩溃的问题，该页面在一个元素上使用了 border-radius。移除该 CSS 定义后，一切都正常工作。
我从我的 iPhone 4 上运行 iOS 6 发布了这条评论，唯一的问题是，其中一名评论者的电子邮件作为名称，它太长了，导致主列缩小到大约 2/3 的宽度，最右侧的 1/3 是深灰色。