在项目中使用Google Closure Compiler

现在的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所制作的无比精彩的幻灯片：

Closure Compiler vs YUICompressor

View more documents from 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的。