本篇文章给大家分享的是有关如何使用JavaScript解析器UglifyJS,小编觉得挺实用的,因此分享给大家学习,希望大家阅读完这篇文章后可以有所收获,话不多说,跟着小编一起来看看吧。
我一直在为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的JavaScript分词器和解析器存放在源代码的parse-js.js文件中,移植于parse-js项目,后者是一个用Common Lisp实现的类库。现在您应该可以猜到它输出的AST是什么表现形式了吧。没错,就是个“表”,用JavaScript来表示,就是个数组套数组。我写了点简单的代码对其进行格式化输出,您可以在这里简单尝试一下UglifyJS的解析器。这个输出虽然简单,但对于Jscex来说也已经完全够用了。
使用
打开parse-js.js文件,您会看到这样一些代码:
var KEYWORDS = array_to_hash([ ... ]); var RESERVED_WORDS = array_to_hash([ ... ]); ... function parse($TEXT, exigent_mode, embed_tokens) { ... } 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方法了。不过这么做也有个严重的问题,那就是对根对象的“污染”实在是太严重了,例如在浏览器中所有的函数,定义都出现在window上,再引入一些其他类库,造成冲突的可能性相当高。
因此,我们必须对代码进行一些修改。幸运的是,在JavaScript中解决这类“作用域”问题十分容易,例如我这样将parse-js.js的代码包围了起来:
var UglifyJS = {}; (function (exports) { })(UglifyJS);
这样就解决了作用域问题,如今我们就能访问UglifyJS对象上的KEYWORDS集合以及parse等成员了。
性能
然后再说说性能。JavaScript一直被认为是一门执行效率低下的语言——这其实是个错误的观点。其实从语言设计上说,JavaScript比Python和Ruby都要快,只不过由于历史原因各大浏览器对它都不太重视而已。不过如今情况早就有所改变,在V8的带领下,现代的JavaScript引擎执行速度都已经超过了目前最快的Python和Ruby实现。话不多说,现在我们就来比较一下UglifyJS的解析器与Narcissus在各浏览器下的表现吧。
测试页面在此(http://files.zhaojie.me/demos/js-parsers/benchmark.html),您也可以自行尝试,测试场景是使用两者分别解析十次Narcissus的实现——大约1500行未压缩的JavaScript代码(值得一提的是,我试了许多压缩后的代码,如jquery-min.js,它们用UgilifyJS可以正常解析,而Narcissus却解析失败)。我使用两台公司配置的标准工作机,测试了IE、Chrome和Firefox各两个版本共6种浏览器。每个浏览器我都会运行多遍测试,去处偏差大的结果,取中游数值。遗憾的是,由于条件所限,两台机器的操作系统有所不同,虽然我认为并不会对结果有什么影响,但如果您足够顶真,也不妨再自行评测一把。
首先我在Win 7下测试了Chrome 10、FireFox 3和IE9,结果如下:
对于UglifyJS来说,Chrome 10的表现***,IE 9相比略慢少许,而Firefox 3耗时则是前两者的数倍。对于Narcissus来说,则是IE 9表现***,仅为Chrome 10的五分之一,和Firefox 3相比更是数量级上的领先。有趣的是,Chrome 10和Firefox 3下两个解析器的耗时都是一比十左右,而IE 9下则相差无几。
然后是Win XP下Chromium 12、Firefox 4及IE 8,结果如下:
对于UglifyJS来说,Chromium 12的表现依旧抢眼,胜过Firefox 4不少,不过使用Narcissus的情况则正好相反。同样可以看出,IE 8在JavaScript引擎的性能方面已经落后于这个时代了,不过它和IE 9、Firefox 4(以及后文的Safari)的情况类似,即UglifyJS和Narcissus的耗时并没有太大差别。
为了便于观察,我将两次测试的结果放在一起(除了非正式版本的Chromium 12):
总体而言,Chrome 10、IE 9和Firefox 4为***军团。IE 9在UglifyJS上小负于Chrome 10,但在Narcissus上优势明显;Chrome 10在UglifyJS上表现***,但在Narcissus却落后较多;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这种浏览器在我眼中也是必须消灭的东西。
以上就是如何使用JavaScript解析器UglifyJS,小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注编程网行业资讯频道。