概述：
-
案例：Cesium打包流程，相關技術點和大概流程
-
原理：代碼優化的意義：壓縮 優化 混淆
-
優化：如何完善Cesium打包流程
關鍵字：Cesium gulp uglifyjs
字數：2330 | 閱讀時間：7min+
1 Cesium打包流程
如果沒有記錯，Cesium從2016年初對代碼構建工具做了一次調整，從grunt改為gulp。作為一名業余選手，就不揣測兩者的差別了。個人而言，gulp和Ant的思路很相似，通過管道連接，都是基於流的構建風格，而且gulp更像是JS的編碼風格，自帶一種親切感。
gulp.task('task1',['task0'], function() {
return fun_task1();
});
Task語句是gulp中最常見的，懂了這句話，就等於你看懂腳本了。這句話的意思是，要執行task1，需要先執行task0，而task1的具體工作都在fun_task1方法中。這就是之前說的基於流的構建風格。有了這句話，在命令行中鍵入：gulp task1，回車執行該指令即可。
先安裝Node，環境變量等，並安裝npm包后，即可使用gulp打包工具，這里推薦cnpm。環境搭建好后，命令行中鍵入gulp minify開始打包。完整的過程是build->generateStubs->minify。
Cesium打包流程
build：准備工作，創建Build文件夾；將glsl文件轉為js形式；最主要的是createCesiumJs方法，遍歷Source中所有js腳本，將所有Object記錄到Source/Cesium.js；其他的是范例，單元測試相關模塊。
generateStubs：用於單元測試，略。
minify; 首先combineJavaScript主要做了兩件事情，打包Cesium和Workers腳本，這是打包的最終結果。Gulp根據指令的不同，比如minify下采用uglify2優化，而combine對應的參數為none，生成路徑為CesiumUnminified。
另外，細心的人會發現，combineCesium的實現中有這樣一句話path.relative('Source',require.resolve('almond'))，這是一個小優化，almond是requirejs的精簡包，因此，最終的Cesium.js中包含'almond腳本，內置了requirejs的主要方法。
如上是Cesium打包的主要流程，簡單說主要有3+1類個指令：
-
Clean
-
清空文件
-
-
minify
-
打包&壓縮
-
-
combine
-
只打包，不壓縮
-
-
JScoverage
-
單元測試覆蓋率，不了解
-
2 代碼優化
對流程有了一個大概了解，下面，我們詳細了解一下uglify2過程都做了哪些代碼優化，一言以蔽之，壓縮，優化，混淆。
uglify2主要有三個參數：-o，-c，-m，-o參數必選，指定輸出文件，-c壓縮，-m混淆變量名。如下分別為combine、(uglifyjs -o)、(uglifyjs –c -m -o)的文件對比，單位是k：
uglify2的壓縮對比
都在一個屋檐下，差距怎么就這么大呢？我們簡單說一下從1~2，2~3之間青取之於藍而勝於藍的過程。
1~2的過程其實很簡單，就是干了三件事，去掉注釋， 去掉多余的空格(換行符)，去掉不必要的分號(;)。就這三件事情，文件一下子小了一半多，換句話就是平時你寫的代碼有一大半都是廢話，此時你旁邊的AI程序員可能會喃喃道來“你們人類好愚蠢~”。
2~3則是很多小細節的綜合應用：
-
去掉一些實際沒有調用的函數（Dead code）；
-
將零散的變量聲明合並，比如 var a; var b;變為var a,b;
-
邏輯函數的精簡，比如if(a) b(); else c()變為a ? b() : c();
-
變量名的簡化，比如var strObject;變為var s;
-
……
這些小技巧有很多，具體要看不同的壓縮工具的考慮優劣，但有些壓縮高效的工具並不穩定，可能會破壞語法規范或語意，所以沒必要為了幾個kb承擔過多的風險，目前比較成熟的工具主要有三個uglify2，google closure以及yuicompressor，具體優劣得自己來體會了，我是按照自己的理解給出的先后順序。最終的效果如下：
Cesium腳本效果
這樣的代碼只能用單位“坨”來形容了，人類是無法直接讀懂的，那瀏覽器能讀懂嗎？這是一個好問題！如下是V8引擎對JS語法解析的大概流程：
V8引擎解析JS腳本
下面是在我本機Chrome解析Cesium.js腳本花費時間（腳本從下載完到瀏覽器解析完的時間差），單位毫秒，因為只測試了一次，可能會有誤差，但基本吻合期望值：
JS腳本解析時間對比
首先因為是本機測試，腳本無論是最大的8M還是最小的2.4M，下載速度都很快，因此我們不討論（但實際應用中要考慮）腳本下載所需時間。
其次，如上圖，多了一個source，這是源碼情況下，這個時間水分比較大，因為是零散的文件，可以做到按需下載，但因為文件比較瑣碎，性能也不高。
結論是，這種JS腳本優化策略對瀏覽器的影響不大，瀏覽器看到優化后的代碼，可能會愣一會神，但很快就克服了。
3實戰
知道了代碼優化的大概原理，回顧一下代碼優化的目的（壓縮，優化，混淆），匹配一下結果是否符合期望值。嗯，其一，腳本的大小小了，其二，代碼效率也優化了，其三，別人也看不懂了。似乎該做的都已經做了，這個腳本已經很完美了。
Format后的效果
毛爺爺說，與人斗其樂無窮。確實，前兩點的目的達到了，但第三點，還差很多。如上，和剛才的腳本是同一個文件，我只是用Chrome的調試工具format而已。這就是理想和現實之間的差距。
可見，Cesium默認打包工具在壓縮和優化上都沒有問題，但在混淆上並不充分，當然Cesium本身是開源的，也沒必要搞這些。客觀說，JS腳本是明碼的，所以反編譯只是時間和能力的問題，所以不妨換個態度來看待這個問題，增加反編譯的成本，當該成本大於購買成本即可。
抱歉，下面的內容因為外在因素，不方便在這說，我寫完之后又刪除了，深表歉意。如果感興趣，不妨在微信公眾號留言，當然如果你認可超圖的技術，歡迎加入超圖研發WebGL團隊。
Beneath this mask, there is more than flesh. Beneath this mask, there is an idea. And ideas are bulletproof.
