【翻譯】Sencha Cmd中腳本壓縮方法之比較

概述

這么多年來，Web開發(fā)人員都被告知應(yīng)優(yōu)化他們生產(chǎn)環(huán)境的代碼。傳統(tǒng)的方法是將應(yīng)用程序的所有腳步進行壓縮以減少應(yīng)用程序的大小，以便讓應(yīng)用程序加載更快。而Sencha Cmd這么多年以來已經(jīng)將這個過程自動化了。

然而，許多客戶，還不知道可通過調(diào)整Sencha Cmd的壓縮代碼來進行一些額外的處理。盡管Sencha Cmd默認是適應(yīng)YUI壓縮來進行壓縮的，但還可以通過配置使用Google Closure或UglifyJS來進行壓縮。下面將會介紹這些，并去測試哪一個壓縮工具提供了最大的壓縮效果。

要注意的是，本文的本意并不是讓你使用某個特定的工具，至于選擇哪一種，不選擇哪一種，是有許多的因素決定的，本文只是嘗試提供一些參考意見。

為什么要修改默認設(shè)置？

雖然腳本壓縮的處理機制相當(dāng)復(fù)雜，但總的來說還是相當(dāng)簡單的：代碼會被標(biāo)記后解析為一個抽象語法樹（abstract syntax tree，AST），然后通過腳本程序進行修改并壓縮后輸出。

雖然這些獨立的工具是如何工作的(如使用什么算法等)已經(jīng)超出了本文的范圍，但還是讓我們在更高的層級上來快速體驗一下YUI壓縮、Closure和UglifyJS。

YUI壓縮

YUI壓縮是一個使用JAVA編寫的命令行工具，它既可以處理Javascript，也可以處理CSS壓縮，對于大多數(shù)項目來說，它是一個理想的工具。YUI壓縮雖然很受歡迎，但已經(jīng)不再更新了。

如前文所述，Sencha Cmd默認是使用YUI壓縮來處理應(yīng)用程序的生成過程的。

Google Closure編譯器

Google Closure編譯器也是使用JAVA創(chuàng)建的，不過它只能處理javascript壓縮（不包含CSS）。Closure可以直接從命令行運行，它還包含其他的一些服務(wù)（UI和API），并通過代碼注釋和編譯標(biāo)志為壓縮處理提供了更多的控制權(quán)。

UglifyJS

UglifyJS是這些工具中唯一使用javascript編寫的工具，因此非常適合應(yīng)用于Node.js環(huán)境中。如Closure一 樣，UglifyJS只提供javascript壓縮（不包括CSS）。UglifyJS是以命令行工具方式運行的，并允許通過大量的編譯標(biāo)志來精細的控 制壓縮過程。

注意：Sencha Cmd是使用JAVA創(chuàng)建的，而UglifyJS的運行需要使用到Rhino，而不是Node.js。

要記住的是，因為每一個工具會產(chǎn)生不同的壓縮輸出，因而很難預(yù)測哪一個是最理想的結(jié)果。為了說明這一點，下面將通過一個示例應(yīng)用程序來測試這些壓縮工具如何去處理這些代碼。

案例研究：Ext JS 6示例應(yīng)用程序

最簡單的用來說明這一概念的方式就是使用Sencha Cmd來生產(chǎn)一個示例應(yīng)用程序：

sencha -sdk ~/path/to/ext generate app Foo ./foo

因為Sencha Cmd自身能搭建一個完整的示例應(yīng)用程序，因而我們不需要做任何事情。在Firefox打開應(yīng)用程序，在“開發(fā)”模式中應(yīng)用程序的加載數(shù)據(jù)統(tǒng)計如下：

這里沒有太多驚喜，在“開發(fā)”模式中的Ext JS 應(yīng)用程序依賴于Ext.Loader來同步加載每一個Javascript依賴，雖然只花費了0.29秒來等待24個HTTP請求，但可以想象得出一個企業(yè)應(yīng)用程序可能需要花費更多的時間。

在運行”sencha app build”將示例應(yīng)用程序轉(zhuǎn)為“生產(chǎn)”模式后，網(wǎng)絡(luò)統(tǒng)計已經(jīng)有所改變了：

很顯然，現(xiàn)在只加載了很小的腳本資源，而整體的加載時間已經(jīng)降至0.02秒了。這一切都得感謝javascript壓縮的魔力。

顯然，使用javascript壓縮是很重要的，不過，通過調(diào)整Sencha Cmd的設(shè)置可以獲得更好的結(jié)果嗎？如果要修改Sencha Cmd所使用的壓縮工具，可編輯app.json文件：

    {        //...

        /**
         * override objects for setting build environment specific
         * settings.
         */
        "production": {            "compressor" : {                //"type" : "yui"    //the default...
                //"type" : "uglify" //or...
                "type" : "closure"
            }
        },        //...
    }1234567891011121314151617

現(xiàn)在運行“sencha app build”，將會使用配置的壓縮工具。接下來，讓我們來看看使用不同壓縮工具后的示例應(yīng)用程序是如何的：

在以上表格中，可以看到壓縮文件的大小，另外一部分是使用gzip壓縮后的輸出文件（通過gzip終端命令使用默認設(shè)置的運行結(jié)果）。從結(jié)果可以看到，使用UglifyJS可以輸出最小的文件，而如果考慮gzip壓縮，則Closure更佳。

如果調(diào)整gzip的設(shè)置，可能會獲得更好的結(jié)果。

注意事項

由于Closure贏了，我們是否只是有Closure呢？可悲的是，其實并不是那么明確的。

如果采用額外的步驟來衡量所生產(chǎn)應(yīng)用程序過程的總時間（包括生產(chǎn)CSS主題和其他步驟），就會注意到一些重要的事情。

示例應(yīng)用程序使用的是Ext JS 5.0.1.1255，是在MacBook Pro（2011年初，OSX 10.10.1, 2GHz Intel i7, 8GB RAM）上使用Sencha Cmd 5.1.0.26進行壓縮的。如果在你的機器上可能會有不同的結(jié)果。要注意的是，我修改過生成設(shè)置，以避免主題為舊的瀏覽器進行切片.

 sencha -ti app build -c

以上命令會為我們提供執(zhí)行的總時間（-ti 標(biāo)志）,b并會刪除之前生成的輸出（-c 標(biāo)志）以保證壓縮是一個干凈壓縮。為每一個壓縮工具運行一次生產(chǎn)，就可以看到為什么YUI壓縮是默認選擇了：

• YUI: 0:00:33

• Closure: 0:00:54

• UglifyJS: 0:15:40

Closure花費了近兩倍的時間去壓縮生成的輸出，而UglifyJS則需要31x這么長的時間！這里要點就是，是否值得為幾千字節(jié)的問題而花費大量增加的生產(chǎn)時間。

歸根結(jié)底，一些公司的首要目標(biāo)只是減少javascript的大小，而并注重哪幾千字節(jié)。不過，對于高流量應(yīng)用程序，則會讓他們更關(guān)注這些微小的細節(jié)，因為頁面的速度和總體帶寬可能會大大影響利潤。

最后，你可能會問任何壓縮過的javascript代碼執(zhí)行上是否會更快。這幾乎是不可能的事，現(xiàn)有的JSPerf測試表明，執(zhí)行速度幾乎是沒有任何差別的。

自定義JS壓縮

Sencha Cmd目前還不允許去配置YUI壓縮的配置，不過YUI本身也沒有提供更多的配置。Sencha Cmd目前允許用戶配置Closure去如何壓縮代碼。

再次打開app.json，在文件中科直接通過“compressor”對象來配置Closure的壓縮選項：

{    //...

    "production": {        "compressor" : {            "type" : "closure",            //all other keys are passed as options
            "ambiguateProperties" : true,            "foldConstants"       : true
        }
    },    //...}123456789101112131415

Sencha Cmd目前還沒有實現(xiàn)UglifyJS的自定義配置，不過該功能已包含在路線圖中。

小結(jié)

壓縮javascript是既定的提高Web應(yīng)用程序性能的最佳做法。Sencha Cmd默認情況下會自動進行處理，不過，使用更先進的設(shè)置來對生成的產(chǎn)品進行額外的優(yōu)化，是值得的。

**作者： Arthur Kay
Arthur Kay is a Senior Software Engineer at Sencha. He studied Music and Computer Science at Loyola University Chicago and has been involved with the Web since the late 1990s.**