UglifyJS有个不错的JavaScript解析器

2021年1月11日   |   by tgcode

  我一直在为Jscex寻找好用的JavaScript解析器,之前我用的是Narcissus,也写过相关文章。不过可惜的是,Narcissus使用了SpiderMonkey的扩展,因此它并不是用ECMAScript 3实现的,无法在IE 8等浏览器中使用。目前Jscex使用的是NarrativeJS中旧版的Narcissus,但是我并不喜欢它输出的AST结构,使用中也发现高级功能里的一些bug,有些食之无味弃之可惜的感觉,而改写新版Narcissus又必须大动干戈。最近我接触到了UglifyJS,发现它的解析器相当不错,性能也比Narcissus高出许多,在此介绍给大家。

  介绍

  UglifyJS是个JavaScript压缩器,效果和Google Closure Compiler相比有过之而无不及。对于现代化的JavaScript压缩器来说,简单的去除空白和压缩局部变量是远远不够的,同时需要理解代码的语义,将其替换成提及更小的形式(Uglify的说明页上有许多描述)。这显然需要一个JavaScript解析器。UglifyJS基于NodeJS开发,不过可以在各种支持CommonJS模块系统的JavaScript引擎/平台上运行。如果没有CommonJS,也只需将exports相关的代码去掉即可。

  JavaScript解析器的作用自然是将JavaScript代码分解成AST,然后根据AST便可以做到许多有趣的事情。相同的AST可以在内存中有不同的表现形式,例如之前提到我不太喜欢Jscex目前使用的旧版Narcissus,一个重要的原因便是它的AST结构不够友好(最新的Narcissus倒不错)。此外,虽然它提供了一些高级功能,例如标注了每个元素在源代码中的位置,这样使用者就可以直接根据getSource方法获得它对应的源代码——只可惜经试验这个功能有bug,这迫使我还得遍历完整的AST。

  UglifyJS的JavaScrtgcodeipt分词器和解析器存放在源代码的parse-js.js文件中,移植于parse-js项目,后者是一个用Common Lisp实现的类库。现在您应该可以猜到它输出的AST是什么表现形式了吧。没错,就是个“表”,用JavaScript来表示,就是个数组套数组。我写了点简单的代码对其进行格式化输出,您可以在这里简单尝试一下UglifyJS的解析器。这个输出虽然简单,但对于Jscex来说也已经完全够用了。

  使用

  打开parse-js.js文件,您会看到这样一些代码:

/* -----[ Tokenizer (constants) ]----- */var KEYWORDS = array_to_hash([
...
]);

var RESERVED_WORDS = array_to_hash([
...
]);

...

function parse($TEXT, exigent_mode, embed_tokens) {
...
}

/* -----[ Exports ]----- */

exports.tokenizer
= tokenizer;
exports.parse
= parse;
exports.slice
= slice;
exports.curry
= curry;
exports.member
= member;
exports.array_to_hash
= array_to_hash;
exports.PRECEDENCE
= PRECEDENCE;
exports.KEYWORDS_ATOM
= KEYWORDS_ATOM;
exports.RESERVED_WORDS
= RESERVED_WORDS;
exports.KEYWORDS
= KEYWORDS;
exports.ATOMIC_START_TOKEN
= ATOMIC_START_TOKEN;
exports.OPERATORS
= OPERATORS;
exports.is_alphanumeric_char
= is_alphanumeric_char;
exports.set_logger
= function(logger) {
warn
= logger;
};

  UglifyJS是基于CommonJS模块机制编写的,这一个文件其实就是个模块,它对外的方法通过exports暴露出来。如果我们将其作为普通的JavaScript文件引入到浏览器中,显然会报“export未定义”异常。理论上说,如果定义一个exports对象,甚至去除和exports有关的代码就能正常使用parse方法了。不过这么tgcode做也有个严重的问题,那就是对根对象的“污染”实在是太严重了,例如在浏览器中所有的函数,定义都出现在window上,再引入一些其他类库,造成冲突的可能性相当高。

  因此,我们必须对代码进行一些修改。幸运的是,在JavaScript中解决这类“作用域”问题十分容易,例如我这样将parse-js.js的代码包围了起来:

var UglifyJS = {};
(
function (exports) {
/* original code here */
})(UglifyJS);

  这样就解决了作用域问题,如今我们就能访问UglifyJS对象上的KEYWORDS集合以及parse等成员了。

  性能

  然后再说说性能。JavaScript一直被认为是一门执行效率低下的语言——这其实是个错误的观点。其实从语言设计上说,JavaScript比Python和Ruby都要快,只不过由于历史原因各大浏览器对它都不太重视而已。不过如今情况早就有所改变,在V8的带领下,现代的JavaScript引擎执行速度都已经超过了目前最快的Python和Ruby实现。话不多说,现在我们就来比较一下UglifyJS的解析器与Narcissus在各浏览器下的表现吧。

  测试页面在此,您也可以自行尝试,测试场景是使用两者分别解析十次Narcissus的源代码——大约1500行未压缩的JavaScript代码(值得一提的是,我试了许多压缩后的代码,如jquery-min.js,它们用UgilifyJS可以正常解析,而Narcissus却解析失败)。我使用两台公司配置的标准工作机,测试了IE、Chrome和Firefox各两个版本共6种浏览器。每个浏览器我都会运行多遍测试,去除偏差大的结果,取中游数值。遗憾的是,由于条件所限,两台机器的操作系统有所不同,虽然我认为并不会对结果有什么影响,但如果您足够顶真,也不妨再自行评测一把。

  首先我在Win 7下测试了Chrome 10、FireFox 3和IE9,结果如下:%title插图%num

  对于UglifyJS来说,Chrome 10的表现最好,IE 9相比略慢少许,而Firefox 3耗时则是前两者的数倍。对于Narcissus来说,则是IE 9表现最好,仅为Chrome 10的五分之一,和Firefox 3相比更是数量级上的领先。有趣的是,Chrome 1tgcode0和Firefox 3下两个解析器的耗时都是一比十左右,而IE 9下则相差无几。

  然后是Win XP下Chromium 12、Firefox 4及IE 8,结果如下:%title插图%num

  对于UglifyJS来说,Chromium 12的表现依旧抢眼,胜过Firefox 4不少,不过使用Narcissus的情况则正好相反。同样可以看出,IE 8的JavaScript引擎性能全面不敌其他浏览器,不过它和IE 9、Firefox 4(以及后面的Safari)的情况类似,即UglifyJS和Narcissus的耗时并没有太大差别。

  为了便于观察,我将两次测试的结果放在一起(除了非正式版本的Chromium 12):%title插图%num

  总体而言,Chrome 10、IE 9和Firefox 4为第一军团。IE 9在UglifyJS上小负于Chrome 10,但在Narcissus上优势明显;Chrome 10在UglifyJS上表现最佳,但在Narcissus却落后IE 9和Firefox 4较多;Firefox 4虽然都不是“最佳”,但差距也并不太大。至于IE 8和Firefox 3,在JavaScript的执行效率方面的确已经落后于这个时代了。必须承认,如今的浏览器大战的确大大提高了各方的质量。

  此外我还测试了公司iMac上的Chrome 10、Firefox 3以及Safari 5,在此列出结果:

  虽然浏览器的表现各有高低,差距也有所不同,但可以确定的是,UglifyJS解析器的性能的确比Narcissus要高。因此,我打算在接下来几天里用UglifyJS替换掉目前Jscex里使用的Narcissus。

  总结

  由于前端开发和JavaScirpt的流行,越来越多的人开始用JavaScript做一些有趣的事情。我很不喜欢如今许多所谓的前端实践,纠缠于大量的hack以及各种浏览器的表现,甚至是JavaScript里某种特定写法的性能更高——例如,居然有消息称,对于字符串连接操作来说,a += b的性能比a = a + b要高(或反之)。在我看来这些东西是最无用的,知道了又如何?随着浏览器更新换代,这些“经验”瞬间就毫无作用了。

  这也是我为什么喜欢玩JavaScript,却死也不愿去做前端开发,尤其是HTML、CSS。同样,如IE 6这种浏览器在我眼中也是必须消灭的东西。

相关推荐: 为什么说DOM操作很慢

  一直都听说DOM很慢,要尽量少的去操作DOM,于是就想进一步去探究下为什么大家都会这样说,在网上学习了一些资料,这边整理出来。   首先,DOM对象本身也是一个js对象,所以严格来说,并不是操作这个对象慢,而是说操作了这个对象后,会触发一些浏览器行为,比如…