为什么移动设备上的简单网站崩溃（至少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问题中。

附录

以下是关于该网站的一些可能相关的知识： b
$ b

• HTML文档很大相对于其他网站的HTML文档而言，它的非流行性似乎是〜225KB（我注意到LoDash文档更大 - 该网站是否会让人们的手机崩溃？） 提供的HTML文档已被缩小。


• 服务的CSS和JS也被缩小。


• 该网站使用 Prism.js 用于语法突出显示。


• 该网站使用 Overthrow ，以便在平板电脑上使用双滚动列布局。 < aside id =help-content> 是固定的并在屏幕外翻译;当您点击任何实用程序的use-name的[？]时，它会滑入。
  

iOS崩溃日志

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

 免费pages：5674 
活动页面：117674 
非活动页面：55121 
推测页面：3429 
遏制页面：0 
可清除页面：0 
有线页面： 60906 
文件支持页面：23821 
匿名页面：152403 
压缩：356216 
解压缩： 121241 
 Compressor大小：16403 
压缩器中的未压缩页面：49228 
最大进程：Chrome 
 
 [...] 
 
 Chrome& amp ; LT; 2a759438c2253e3baededaa0d13feb56&安培; GT; 166479 166479 200 [per-process-limit]（frontmost）（resume）
  

解决方案<我认为我解决了这个问题！

怀疑问题在于由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屋！