jQuery 代码组织和性能

Question

在对这个主题做了一些研究之后，我尝试了很多模式来组织我的 jQuery 代码（Rebecca Murphy 做了一个 ）。

昨天我检查了（揭示的）模块模式。结果看起来有点让人想起我认为的 YUI 语法：

//global namespace MyNameSpace
if(typeof MNS=="undefined"||!MNS){var MNS={};}

//obfuscate module, just serving as a very simple example
MNS.obfuscate = function(){
    //function to create an email address from obfuscated '@'
    var email = function(){
        $('span.email').each(function(){
            var emailAddress = $(this).html().replace(' [ @ ] ','@');
            $(this).html('<a href="mailto:' + emailAddress + '">' + emailAddress + '</a>');

        });
    };    
    return {
        email: email
    };    
}();

//using the module when the dom's ready
jQuery(document).ready(function($){
    MNS.obfuscate.email();
});

最后我有几个模块。有些自然地包含“私有成员”，在这种情况下意味着仅对该模块内的其他函数重要的变量和/或函数，因此不会出现在 return 语句中。

我认为将我的代码的连接部分（例如与搜索有关的所有内容）组合在一个模块中是有意义的，给出了整个事物的结构。

但写完这篇文章后，我读了 John (Resig) 的文章，其中他还写了关于模块模式的性能：

“用一堆原型属性实例化一个函数非常非常快。它完全击败了模块模式，类似的，出水了。因此，如果你经常-你希望人们与之交互的访问函数（返回一个对象），那么将对象属性放在原型链中并实例化它对你有利：（

// Very fast
function User(){}
    User.prototype = { /* Lots of properties ... */ };

// Very slow
function User(){
    return { /* Lots of properties */ };
}

约翰提到他并不反对该模块。模式“本身”，只是为了让你知道:)然后

我不确定我的代码是否朝着正确的方向发展：我真的不需要需要。任何私人成员，我也认为暂时不需要继承。 我现在想要的只是一个可读/可维护的模式。我想这在一定程度上归结为个人偏好，但我不想最终得到具有（相当严重的）性能问题的可读代码。

我不是 JavaScript 专家，因此在性能测试方面更不是专家。所以首先，我真的不知道约翰提到的事情（“你希望人们与之交互的经常访问的函数（返回一个对象）”，很多属性等）在多大程度上适用于我的代码。我的代码与之交互的文档并不大，只有数百或数千个元素。所以也许这根本不是问题。

但我想到的一件事是，

$('span.email').each(function(){
    var emailAddress = $(this).html().replace(' [ @ ] ','@');
    $(this).html('<a href="mailto:' + emailAddress + '">' + emailAddress + '</a>');
});

由于使用了模块模式，我不只是拥有（在 domready 函数内），而是创建了两个“额外”函数：混淆和电子邮件。创建附加功能需要花费一些时间。问题是：在我的情况下它是可以衡量的吗？

我不确定上面的示例中是否创建了一个闭包（在 jQuery 论坛上的一篇有趣的帖子中，我读到了以下内容：“对于内部函数是否不引用任何内容，是否会创建一个闭包，存在一个哲学争论。外部函数的变量对象...”），但我的真实代码中确实有闭包。即使我不认为其中有任何循环引用，我也不知道这会在多大程度上导致高（呃）内存消耗/垃圾收集问题。

我真的很想听听您对此的意见，也许还可以看看您的代码的一些示例。另外，您更喜欢使用哪些工具来获取有关执行时间、内存和 CPU 使用情况的信息？

Answer 1

我也觉得暂时不需要继承

确实。这并不真正适用于使用模块作为命名空间。这是关于类实例的类似物。

通过从全新的 {name: member} 对象创建每个实例来创建的对象，其效率低于使用 new Class 和 Class.prototype.name 创建的对象= 成员。在原型情况下，member 值是共享的，从而产生更轻量级的实例。

在您的示例中，MNS 是一个单例，因此通过原型共享成员没有任何好处。

我不确定上面的示例中是否创建了闭包

是的，是的。即使外部函数中没有定义变量，仍然会为外部函数创建一个 LexicalEnvironment 和作用域对象，并在其中绑定 this 和 arguments 。一个聪明的 JS 引擎也许能够优化它，因为每个内部函数都必须用自己的副本隐藏 this 和 arguments ，但我不确定其中的任何一个当前的 JS 实现实际上就是这样做的。

无论如何，性能差异应该是无法检测到的，因为您没有在参数中添加任何重要的内容。对于简单的模块模式，我认为没有任何坏处。

此外，您更喜欢使用哪些工具来获取有关执行时间、内存和 CPU 使用情况的信息？

开始的地方只是在 for 循环中执行代码 10000 次，看看 new Date().getTime() 已经有多大，在尽可能多的不同浏览器上执行多次可以抓住。

$(this).html().replace('[@]','@');

（这是做什么的？此时它会将跨度的 HTML 读取到新的 String 中，仅将 [ @ ] 的第一个实例替换为 @，并返回一个新的 String 值，它不会更改 DOM 中的现有内容。）

Answer 2

你有多少 JavaScript？根据我的经验，在页面上有大量 Javascript 代码的网站上，性能问题通常来自于实际做事情的代码。一般来说，问题源于试图做太多事情，或者试图把某件事做得非常糟糕。一个例子是尝试将处理程序绑定到表行（大表）中的元素，而不是使用“live”之类的东西。

我的观点是，诸如模块或功能或其他内容的组织方式之类的事情几乎肯定不会在您的页面上造成任何真正的性能问题。是什么促使你经历这些麻烦？