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

原文地址：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编码压缩，下面简单介绍一下：

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

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

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

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