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

概述

這么多年來，Web開發人員都被告知應優化他們生產環境的代碼。傳統的方法是將應用程序的所有腳步進行壓縮以減少應用程序的大小，以便讓應用程序加載更快。而Sencha Cmd這么多年以來已經將這個過程自動化了。

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

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

為什么要修改默認設置？

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

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

YUI壓縮

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

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

Google Closure編譯器

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

UglifyJS

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

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

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

案例研究：Ext JS 6示例應用程序

最簡單的用來說明這一概念的方式就是使用Sencha Cmd來生產一個示例應用程序：

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

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

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

在運行”sencha app build”將示例應用程序轉為“生產”模式后，網絡統計已經有所改變了：

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

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

    {        //...

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

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

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

如果調整gzip的設置，可能會獲得更好的結果。

注意事項

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

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

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

 sencha -ti app build -c

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

• YUI: 0:00:33

• Closure: 0:00:54

• UglifyJS: 0:15:40

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

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

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

自定義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目前還沒有實現UglifyJS的自定義配置，不過該功能已包含在路線圖中。

小結

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

**作者： 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.**