UglifyJS有個超贊的JavaScript解析器
我一直在為Jscex尋找好用的JavaScript解析器，之前我用的是Narcissus，也寫過相關(guān)文章。不過可惜的是，Narcissus使用了SpiderMonkey的擴(kuò)展，因此它并不是用ECMAScript 3實(shí)現(xiàn)的，無法在IE 8等瀏覽器中使用。目前Jscex使用的是NarrativeJS中舊版的Narcissus，但是我并不喜歡它輸出的AST結(jié)構(gòu)，使用中也發(fā)現(xiàn)高級功能里的一些bug，有些食之無味棄之可惜的感覺，而改寫新版Narcissus又必須大動干戈。最近我接觸到了UglifyJS，發(fā)現(xiàn)它的解析器相當(dāng)不錯，性能也比Narcissus高出許多，在此介紹給大家。
UglifyJS是個JavaScript壓縮器，效果和Google Closure Compiler相比有過之而無不及。對于現(xiàn)代化的JavaScript壓縮器來說，簡單的去除空白和壓縮局部變量是遠(yuǎn)遠(yuǎn)不夠的，同時需要理解代碼的語義，將其替換成提及更小的形式(Uglify的說明頁上有許多描述)。這顯然需要一個JavaScript解析器。UglifyJS基于NodeJS開發(fā)，不過可以在各種支持CommonJS模塊系統(tǒng)的JavaScript引擎/平臺上運(yùn)行。如果沒有CommonJS，也只需將exports相關(guān)的代碼去掉即可。
JavaScript解析器的作用自然是將JavaScript代碼分解成AST，然后根據(jù)AST便可以做到許多有趣的事情。相同的AST可以在內(nèi)存中有不同的表現(xiàn)形式，例如之前提到我不太喜歡Jscex目前使用的舊版Narcissus，一個重要的原因便是它的AST結(jié)構(gòu)不夠友好(***的Narcissus倒不錯)。此外，雖然它提供了一些高級功能，例如標(biāo)注了每個元素在源代碼中的位置，這樣使用者就可以直接根據(jù)getSource方法獲得它對應(yīng)的源代碼——只可惜經(jīng)試驗(yàn)這個功能有bug，這迫使我還得遍歷完整的AST。
UglifyJS的JavaScript分詞器和解析器存放在源代碼的parse-js.js文件中，移植于parse-js項(xiàng)目，后者是一個用Common Lisp實(shí)現(xiàn)的類庫。現(xiàn)在您應(yīng)該可以猜到它輸出的AST是什么表現(xiàn)形式了吧。沒錯，就是個“表”，用JavaScript來表示，就是個數(shù)組套數(shù)組。我寫了點(diǎn)簡單的代碼對其進(jìn)行格式化輸出，您可以在這里簡單嘗試一下UglifyJS的解析器。這個輸出雖然簡單，但對于Jscex來說也已經(jīng)完全夠用了。
使用
打開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模塊機(jī)制編寫的，這一個文件其實(shí)就是個模塊，它對外的方法通過exports暴露出來。如果我們將其作為普通的JavaScript文件引入到瀏覽器中，顯然會報(bào)“export未定義”異常。理論上說，如果定義一個exports對象，甚至去除和exports有關(guān)的代碼就能正常使用parse方法了。不過這么做也有個嚴(yán)重的問題，那就是對根對象的“污染”實(shí)在是太嚴(yán)重了，例如在瀏覽器中所有的函數(shù)，定義都出現(xiàn)在window上，再引入一些其他類庫，造成沖突的可能性相當(dāng)高。
因此，我們必須對代碼進(jìn)行一些修改。幸運(yùn)的是，在JavaScript中解決這類“作用域”問題十分容易，例如我這樣將parse-js.js的代碼包圍了起來：
- var UglifyJS = {};
- (function (exports) {
- /* original code here */
- })(UglifyJS);
這樣就解決了作用域問題，如今我們就能訪問UglifyJS對象上的KEYWORDS集合以及parse等成員了。
性能
然后再說說性能。JavaScript一直被認(rèn)為是一門執(zhí)行效率低下的語言——這其實(shí)是個錯誤的觀點(diǎn)。其實(shí)從語言設(shè)計(jì)上說，JavaScript比Python和Ruby都要快，只不過由于歷史原因各大瀏覽器對它都不太重視而已。不過如今情況早就有所改變，在V8的帶領(lǐng)下，現(xiàn)代的JavaScript引擎執(zhí)行速度都已經(jīng)超過了目前最快的Python和Ruby實(shí)現(xiàn)。話不多說，現(xiàn)在我們就來比較一下UglifyJS的解析器與Narcissus在各瀏覽器下的表現(xiàn)吧。
測試頁面在此（http://files.zhaojie.me/demos/js-parsers/benchmark.html），您也可以自行嘗試，測試場景是使用兩者分別解析十次Narcissus的實(shí)現(xiàn)——大約1500行未壓縮的JavaScript代碼(值得一提的是，我試了許多壓縮后的代碼，如jquery-min.js，它們用UgilifyJS可以正常解析，而Narcissus卻解析失敗)。我使用兩臺公司配置的標(biāo)準(zhǔn)工作機(jī)，測試了IE、Chrome和Firefox各兩個版本共6種瀏覽器。每個瀏覽器我都會運(yùn)行多遍測試，去處偏差大的結(jié)果，取中游數(shù)值。遺憾的是，由于條件所限，兩臺機(jī)器的操作系統(tǒng)有所不同，雖然我認(rèn)為并不會對結(jié)果有什么影響，但如果您足夠頂真，也不妨再自行評測一把。
首先我在Win 7下測試了Chrome 10、FireFox 3和IE9，結(jié)果如下：
對于UglifyJS來說，Chrome 10的表現(xiàn)***，IE 9相比略慢少許，而Firefox 3耗時則是前兩者的數(shù)倍。對于Narcissus來說，則是IE 9表現(xiàn)***，僅為Chrome 10的五分之一，和Firefox 3相比更是數(shù)量級上的領(lǐng)先。有趣的是，Chrome 10和Firefox 3下兩個解析器的耗時都是一比十左右，而IE 9下則相差無幾。
然后是Win XP下Chromium 12、Firefox 4及IE 8，結(jié)果如下：
對于UglifyJS來說，Chromium 12的表現(xiàn)依舊搶眼，勝過Firefox 4不少，不過使用Narcissus的情況則正好相反。同樣可以看出，IE 8在JavaScript引擎的性能方面已經(jīng)落后于這個時代了，不過它和IE 9、Firefox 4(以及后文的Safari)的情況類似，即UglifyJS和Narcissus的耗時并沒有太大差別。
為了便于觀察，我將兩次測試的結(jié)果放在一起(除了非正式版本的Chromium 12)：
總體而言，Chrome 10、IE 9和Firefox 4為***軍團(tuán)。IE 9在UglifyJS上小負(fù)于Chrome 10，但在Narcissus上優(yōu)勢明顯;Chrome 10在UglifyJS上表現(xiàn)***，但在Narcissus卻落后較多;Firefox 4雖然都不是“***”，但差距也并不太大。至于IE 8和Firefox 3，在JavaScript的執(zhí)行效率方面的確已經(jīng)落后于這個時代了。必須承認(rèn)，如今的瀏覽器大戰(zhàn)的確大大提高了各方的質(zhì)量。
此外我還測試了公司iMac上的Chrome 10、Firefox 3以及Safari 5，在此列出結(jié)果：
雖然瀏覽器的表現(xiàn)各有高低，差距也有所不同，但可以確定的是，UglifyJS解析器的性能的確比Narcissus要高。因此，我打算在接下來幾天里用UglifyJS替換掉目前Jscex里使用的Narcissus。
總結(jié)
由于前端開發(fā)和JavaScirpt的流行，越來越多的人開始用JavaScript做一些有趣的事情。我很不喜歡如今許多所謂的前端實(shí)踐，糾纏于大量的hack以及各種瀏覽器的表現(xiàn)，甚至是JavaScript里某種特定寫法的性能更高——例如，居然有消息稱，對于字符串連接操作來說，a += b的性能比a = a + b要高(或反之)。在我看來這些東西是最無用的，知道了又如何?隨著瀏覽器更新?lián)Q代，這些“經(jīng)驗(yàn)”瞬間就毫無作用了。
這也是我為什么喜歡玩JavaScript，卻死也不愿去做前端開發(fā)，尤其是HTML、CSS。同樣，如IE 6這種瀏覽器在我眼中也是必須消滅的東西。
原文鏈接：http://blog.zhaojie.me/2011/04/uglifyjs-has-a-good-javascript-parser.html
【編輯推薦】
