0

因此，我们的移动 Web 应用程序中存在内存泄漏。它在桌面上看不到，但它会使移动 Safari 浏览器（iOS 4、5、6）崩溃，并使整个 Android 操作系统崩溃（在 2.2.x 版本上检查）。

当网站长时间打开时，通常会发生崩溃。

我们用：

  1. headjs（用于js加载）
  2. yepnope（用于 CSS 加载）
  3. 套接字.io
  4. jQuery手机

所以我有以下问题：

  1. 以下哪个库会导致内存泄漏？
  2. 我们应该审查使用 jquery 选择器的代码，还是应该仔细使用 socket.io？
  3. 如果我们在其中加载 20 多个短脚本，脚本加载器（headjs，yepnope）可能会导致内存泄漏吗？
4

2 回答 2

1

众所周知，如果您不小心， jQ mobile 会导致泄漏。总而言之，我认为您列出的所有 4 个工具包都可能导致问题，尤其是当您一起使用它们时。
也许您能做的最好的事情就是尽可能地坚持一个库，并专注于以将泄漏保持在最低限度的方式使用它。移动浏览器的问题在于，还有更多的闭包魔法在发生，而且 JS 引擎还没有那么广为人知/理解。如果您曾经涉足为触摸设备编写 JS 事件委托代码，您一定已经注意到，闭包数量惊人，并且 DOM 引用可能无法及时被 GC 处理。您对此无能为力。

一般来说，我倾向于避免使用太多的库（老实说，我是那些会爬起来避免使用任何库的人之一），所以我可能会有偏见。但是无论你怎么写：headjs 和 jQuery 以ready你可以想象的所有方式检查事件的倾向的结合可能会很麻烦：你正在动态加载新元素，你检查过这是否会ready多次触发 jQ 的事件？如果是这样，您几乎肯定会一遍又一遍地绑定相同的处理程序。每个 ajax 请求也可能触发其他工具包做同样的事情，这可能会再次触发 jQuery，进而可能再次触发其他库，这...
你得到了图片。尽管我远非专家，但我的猜测是一个库可能会触发另一个库，反之亦然，从而导致死锁场景。我基于对我不久前遇到的类似问题的模糊回忆，以及您使用各种库动态加载脚本/CSS的事实，以及 jQ 没有ready最后解除绑定其所有侦听器的事实我检查的时间。如果我的预感是正确的，您可以使用一个邪恶的全局变量作为快速修复：

var jQReady = false;
jQuery(document).load(function()
{
    if (jQReady === true)
    {//was loaded
        return;
    }
    jQready = true;//<-- set to true on first invocation of callback
});
于 2012-11-05T11:35:40.373 回答
1

很酷，您发现了问题，但正如 Elias 所说，尝试减少您使用的框架数量。

由于 JQ Mobile 无论如何都依赖 jQuery（所以当你需要它时它就在那里），我强烈建议删除 HeadJS 和 YepNope，并使用 jQuery 的 $.get() 加载你的资源。

无需包含冗余功能。

也就是说，我在最新版本的 head 中添加了 css 加载，但老实说，如果你已经使用 jquery 并且不使用响应式设计部分，那么你并不需要它。

于 2012-11-15T09:16:15.597 回答