Question

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模式。

Answer 1

编译器假定文件在提供给用户时会被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 字节gzip压缩）。

版本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压缩得更小因为变量声明消失了，gzip将重复部分压缩到大致相同的空间，而不管重复文本的长度。< / p>

以下是FAQ：

的条目

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

大多数人通过查看两个未压缩的JavaScript文件来比较代码大小。但这是一种误导性的查看代码大小的方法，因为您的JavaScript文件不应该是未压缩的。应该使用gzip压缩服务。

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

Answer 2

各种编译器（gcc，g ++，jdk等）总是面临这些问题： “争取速度或争取规模”

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

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

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

是。任何优化编译器都需要权衡。某些大小优化确实会引入较小的速度开销。但是，Closure Compiler的开发人员一直小心不要引入显着的额外运行时。一些编译器的优化甚至会降低运行时间（参见下一个问题）。

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

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

Google Closure中的变量

2 个答案: