代码改变世界

在项目中使用Google Closure Compiler

2009-12-09 09:13  Jeffrey Zhao  阅读(30908)  评论(42编辑  收藏  举报

现在的Web项目总是离不开大量JavaScript,而JS文件的体积也越来越大,也越来越影响页面的感知性能(Perceived Performance)。因此,我们会对JS文件进行压缩,一方面是使用Gzip,而另一方面则是去除JS文件里的注释、空白,并且压缩局部变量长度等等。对于一些成熟的类库来说,它们本身都会提供“完整注释”以及“强烈压缩”两个版本。但是,有时候我们需要自己修复类库里的bug,这只能在注释版中修改,对于压缩版自然就无能为力了。此外,自定义的脚本文件一般也值得一压。因此我在项目中时常会备一个脚本压缩工具。

压缩脚本的工具有很多,例如老牌的JSMin,或是YUI Compressor(下称YC),它们都可以用来压缩脚本文件(后者还可以处理CSS)。不过在新项目中,我使用了新的工具:Google Closure Compiler(下称GC)。GC有多种用法,例如网页版网络API版,还有独立应用程序版。GC与YC不同的是,YC是一个压缩器(Compressor),而GC更是一个编译器(Compiler),也就是说GC的压缩并不仅仅是去除注释和空白,还可以在保证代码正确性的情况下进一步地改写成更省空间的做法,一个字节算一个字节,例如:

a = new Object    => a = {}
a = new Array     => a = []
if (a) b()        => a && b()
return 2 * 3;     => return 6;

GC还提供了一些更危险的压缩方式,虽然有神奇效果,但个人不建议使用。关于YC和GC更详细的对比及注意事项,可以参考淘宝UED部门lifesinger所制作的无比精彩的幻灯片:

GC使用Java编写(YC也一样,不过它有.NET移植版),它的独立应用程序版是一个jar包。如果您不想装一个Java Runtime的话,则可以使用它的网络API版。但是,我在项目中却使用了另一种方式:即不需要安装JRE,也不需要依赖于网络。这个方式便是借助IKVM.NET将GC转化为.NET使用——还记得上次的Lucene 2.9吗

我的项目组织结构大致是:

\src\Web.UI\Scripts\                   <- 存放JS脚本的目录
\tools\IKVM.NET\                       <- 存放IKVM.NET相关文件
\tools\closure-compiler\compiler.jar   <- GC的jar包
\tools\closure-compiler\build.bat      <- 将jar转化为exe的脚本
\tools\closure-compiler\compress.ps    <- 压缩JS的PowerShell命令

以上便是所有放入SVN中的文件,每个开发人员在使用GC之前,首先需要调用build.bat进行“重新编译”:

..\ikvm.net\ikvmc.exe compiler.jar -out:compiler.exe -target:exe
xcopy ..\ikvm.net\*.dll . /y /q

这两行脚本会将compiler.jar包编译为compiler.exe文件,并将IKVM.NET中需要的文件复制到closure-compiler目录下。于是,借助PowerShell的管道,便可以压缩Scripts目录下所有的JS文件:

dir -path ..\..\src\Web.UI\Scripts -filter *.js | % { .\compiler.exe --js $_.FullName --js_output_file ($_.FullName -replace ".js", ".min.js") }

这样,xxx.js便会被压缩为xxx.min.js。于是再配合项目中的扩展方法:

public static string Script(this HtmlHelper helper, string path)
{
    return "<script language=\"javascript\" type=\"text/javascript\" src=\"" + path +
        (helper.ViewContext.HttpContext.IsDebuggingEnabled ? ".min.js" : ".js") +
        "\"></script>";
}

万事俱备。

有些朋友时不时会羡慕其他平台上项目丰富,而在.NET平台上做一些事情感觉捉襟见肘的。我以前经常说,又何必把平台划分的那么细,大家既然都在为技术社区作贡献,那么思想或是做法都是可以借鉴的,所以也已经有了那么多移植过来的项目。而现在,可以“借鉴”的已经不只是“思想”,而是真正实际的项目!我相信在不久的将来,随着IronPython和IronRuby等项目愈发成熟,可以在.NET上运行的东西会越来越多(事实上,如IronPython其实已经很成熟了)。

嗯,到时候,Python的就是.NET的,Ruby的也是.NET的,而Java的——它还是.NET的。