谈前端代码的精简、混淆、压缩和编译

原文地址：http://www.vinqon.com/codeblog/?detail/11106

前几天突然想写一个css的js压缩工具，于是这两天研究了一下几个js、css的压缩工具并且理清楚了一些概念和原理，下面总结一下。

几个基本概念

在网站部署前，我们往往要对前端的代码进行发布，我这里说的“发布”，指的就是精简、混淆、压缩、编译或者还有其他的操作，有些操作很相似，但每个操作的都有其中的意义。

精简(minify)

对前端代码精简的目的很明显，就是减少代码体积，减小网络传输时间，提高页面响应。

而具体到如何精简，其实也很简单，下面是其中的一些办法：

1.删除代码注释

2.删除无意义或者多余的空白（如空格，制表符，回车，换行）

3.删除可以省略的符号（如css最后一条规则后面的分号，js块内最后的一条语句的分号）

4.缩短语句（如果css的简写，html中disabled='disabled' 改成disabled , js中缩短局部变量）

对于精简这个功能，大部分工具都基本实现了上面的方法，包括有yuicompresser,closure complie,jsmin,packer.

混淆(obfuscation)

混淆这个功能主要针对Javascript代码，它的目的是减低代码的可读性，防止被追踪出程序逻辑。

事实上，对代码精简，压缩，编码都有混淆的效果。

首先，上面提到精简的办法中，删除注释，删除缩进（空格，制表符，换行），缩短局部变量都可以有效减低程序可读性。除了删除缩进可以用过js格式化/美化工具还原，其它两个步骤都是不可逆的。

其次，通过编码混淆代码，这篇文章《javascript常用混淆方法》里面介绍了很多牛X的编码加密方法。但是这些方法有个明显缺点，增加代码体积，而且编码加密都是可逆的。

最后，通过压缩的办法，当然，也是可逆的，下面我们详细探讨一下。

压缩(compress)

压缩这一个说法很常被用来概括前面这三种操作，其实上，真正实现压缩的我目前只看到一种方案: packer的base64编码压缩.

这里可以先看一个简单的例子:

压缩前代码：

 
       1 
       document.getElemntById("header").innerHTML="This is the header";

压缩后代码：

 
       1 
       eval(function(p,a,c,k,e,r){e=String;if(!''.replace(/^/,String)){while(c--)r[c]=k[c]||c;k=[function(e){returnr[e]}];e=function(){return'\\w+'};c=1};while(c--)if(k[c])p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c]);returnp}('1.2("0").3="4 5 6 0";',7,7,'header|document|getElemntById|innerHTML|This|is|the'.split('|'),0,{}))

压缩后的代码很恶心，但是认真研究可以发现里面只有三个东西：压缩后原文，字符表，解压器。

packer的base64编码的压缩率很高，精简后代码依然可以减少50%体积以上，因为带有解压器，和字符表，上面的例子没有体现压缩效果，一般来说，越长的代码压缩率更高。

如果对里面构造有兴趣的可以直接研究packer的源代码，算法都是用js写的，另外，还可以看看这篇文章《Packer，你对我的JS做了什么！》.

很多地方都把packer这个功能称为混淆，当然，这的确有混淆的效果，上面也提到。但是，从算法上看，packer base64 encode是一个字典压缩算法，故这里归类为压缩。

另外，需要提醒的是，虽然压缩有混淆效果，但是过程依然可逆，而且解压器和字符表明摆在那里，只要把eval四个字母改成alert就可以看到压缩前的代码。

因为用了邪恶的eval，packer后的代码性能会减低...很多，另外，解压的过程也会消耗一点时间。

特别要注意的是，如果服务器有gzip功能，就不必也不应用packer base64 encode来压缩。因为packer base64 encode压缩加gzip压缩后的体积比源代码只用gzip压缩还要大。

原因也可想而知，我们用js进行了一次低效压缩，gzip压缩的空间就大大减低了。

编译(compile)

说到编译，不得不先提到 google closure compile，它和其他工具不同的是，除了精简功能，它还可以对Javascript代码进行优化。

gcc的高级模式会对Javascript进行语义分析，然后会进行删除无用代码，删除没有使用的变量，优化逻辑关系等比较激进的优化。

虽然编译前后都是Javascript代码，但是这个过程已经算得上实际意义上的编译了。

另外，除了gcc，还要说的是最近很流行的一些新语言： coffeescript, less, sass，这里先简单扫盲一下：

coffeescript是一个类ruby的语言，书写起来更加简洁和优美，coffeescript可以完全编译成同效的Javascript。

而less和sass是在css上进行语法扩展，在css上实现了变量，作用域，函数之类的功能。

现在，类似这样的语言，工具，框架越来越多，好像老赵的 jscex可以对线性代码编译，不用我们写一堆回调。玉伯的seajs可以“预编译”模块，找出模块依赖关系来异步load顺序执行模块。

github上有一份 list记录了所有的这类东东，有兴趣可以去研究一下。

谈到这些，我们仿佛感觉到了前端发展的一个趋势，我们原来写的html，css，Javascript已经开始变成了一个“中间语言”，而且越来越多的团队也有了自己的一套前端编译系统更加彰显了这个趋势。

李松峰老师博客里面有两篇文章也对这个话题进行了讨论：《JavaScript是Web的汇编语言（一）：语义Web已死！》《JavaScript是Web的汇编语言（二）：疯狂，亦或只是精神错乱？》

这是一个有趣的话题，上面很多内容只能贴个链接了，也许下次应该单独做一篇文章来慢慢讨论一下。

CSSPacker

这是我研究几个压缩工具后，自己突发奇想写的一个小玩具。

简单介绍一下，上面提过packer，这是一个真正意义上用Javascript实现的压缩解压方案（当然，相对于客户端的一些压缩软件还差很远），它本来是用来压缩Javascript的，我把它移植一下，折腾出这个csspacker支持压缩css。

packer本来有三个功能：精简代码，缩短局部变量，base64编码压缩，下面简单介绍一下：

packer原本精简代码是根据Javascript语法精简的，我把精简代码部分重写了，以适应css语言；
缩短局部变量没用，直接删掉这个操作；
base64编码压缩适用于任何文本，可以直接保留。但是解压的操作要修改一下，原来Javascript直接把解压后的字符串eval一下就好了，css比比较蛋疼，要新建一个style节点，把解压后css文本插进去。

另外一个比较重大的问题是，图片路径问题。css文件上使用的相对路径是相对于css的位置的，但是js是相对于页面的位置的，所以，如果css含有相对路径，要输入css所在网络位置，它会自动把里面的相对路径转换为URL。

路径问题让这个packer不那么方便了，我还考虑其他方案。目前的另外一个想法是，fork一个分支，把csspacker功能弄进去。

好吧，有兴趣的欢迎去调戏调戏一下 csspacker。