2

http://closure-compiler.appspot.com/home

(function(){

var somevar = 'somevar';

this.each(function(){
var minify_var = {
  method1: somevar + '1', 
  method2: somevar + '2',
  method3: somevar + '3',
  method4: somevar + '4',
  method5: somevar + '5'
};

alert(minify_var);
});

})();

像这样的代码被缩小为：

(function(){this.each(function(){alert({method1:"somevar1",method2:"somevar2",method3:"somevar3",method4:"somevar4",method5:"somevar5"})})})();

长度（+11 个符号）肯定大于：

(function(){var a="somevar";this.each(function(){alert({method1:a+"1",method2:a+"2",method3:a+"3",method4:a+"4",method5:a+"5"})})})();

问题是，我们有两个变量，但取而代之的是一个。

实际上，对于小脚本来说这还不错，但对大脚本来说可能会受到伤害。

添加了第一个变量以使缩小的代码更小，但谷歌忽略了它。

它也忽略了大多数像这样的其他尺寸优化技巧。

可以修复吗？

这个问题是关于 Google Closure，而不是 JavaScript 模式。

4

2 回答 2

7

编译器假定文件在提供给用户时会被 gzip 压缩，因此它会针对压缩文件大小而不是未压缩大小进行优化。

我测试了两个版本的代码。

版本 A（将a其视为全局变量可防止以后自动连接）：

(function () {
    a = 'somevar';

    this.each(function () {
        var minify_var = {
            method1: a + '1',
            method2: a + '2',
            method3: a + '3',
            method4: a + '4',
            method5: a + '5'
        };

        alert(minify_var);
    });
})();

生成的缩小代码：

(function(){a="somevar";this.a(function(){alert({b:a+"1",c:a+"2",d:a+"3",e:a+"4",f:a+"5"})})})();

大小：97 字节（压缩后95字节）。

版本 B（与上面相同，但是a是一个局部变量，因此编译器会进行优化）：

(function () {
    var a = 'somevar';

    this.each(function () {
        var minify_var = {
            method1: a + '1',
            method2: a + '2',
            method3: a + '3',
            method4: a + '4',
            method5: a + '5'
        };

        alert(minify_var);
    });
})();

生成的缩小代码：

(function(){this.a(function(){alert({b:"somevar1",c:"somevar2",d:"somevar3",e:"somevar4",f:"somevar5"})})})();

大小：110 字节（压缩后89字节）。

所以第二个版本在未压缩时更大，但是当它被 gzip 压缩时它更小，因为变量声明消失了，gzip 将重复部分压缩到大致相同的空间，无论重复文本有多长。

这是常见问题解答中的一个条目：

Closure Compiler 内联了我所有的字符串，这使我的代码变得更大。为什么这样做？

大多数人通过查看两个未压缩的 JavaScript 文件来比较代码大小。但这是查看代码大小的一种误导方式，因为您的 JavaScript 文件不应该以未压缩的形式提供。它应该与 gzip 压缩一起使用。

Closure Compiler 假定您正在使用 gzip 压缩。如果你不这样做，你应该这样做。配置你的服务器以压缩你的代码是你可以做的最有效和最简单的优化之一。gzip 算法通过尝试以最佳方式对字节序列进行别名来工作。手动给字符串起别名几乎总是会使压缩后的代码变大，因为它颠覆了 gzip 自己的别名算法。因此，闭包编译器（几乎）总是尽可能内联您的字符串，因为这会使您的压缩代码更小。

于 2013-04-06T07:51:58.687 回答
-1

各种编译器（gcc、g++、jdk 等）总是面临这些问题：“追求速度或追求大小”

在这种情况下，关闭采取了速度的方法。它认识到您在许多地方都有一个常量变量，并直接重写了该值。以下是关闭团队对此事的看法：

https://developers.google.com/closure/compiler/faq#tradeoffs

编译器是否在我的应用程序的执行速度和下载代码大小之间进行权衡？

是的。任何优化编译器都会做出权衡。一些尺寸优化确实会引入小的速度开销。但是，闭包编译器的开发人员一直小心翼翼地不引入大量额外的运行时。一些编译器的优化甚至减少了运行时间（见下一个问题）。

编译器是否针对速度进行了优化？

在大多数情况下，较小的代码是更快的代码，因为下载时间通常是 Web 应用程序中最重要的速度因素。减少冗余的优化也加快了代码的运行时间。

于 2013-04-06T08:08:25.370 回答