在项目中使用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的。