做系統開發，不僅僅要關注前端的設計，系統或產品的更新更加要跟得上時代的變化。優化的對象不僅僅指產品本身，還有我們日常的開發流程。如果不做優化，那么要么是你的產品過時了，要么是你的開發效率太低，開發的技術也會跟不上時代的節奏。因此，作為系統開發/產品開發的成員，我們必須有敏銳的觸覺和快速的優化變身的能力，不然只會被淘汰在茫茫的互聯網大海之中。
下面我們一起跟著深圳市星翼創想網絡科技有限公司來閱讀以下文章，看看做前端開發優化究竟都經歷了什么吧！
11.0時代
前期模塊化已經做的不錯了，至少不必花大量時間去重構代碼。模塊劃分如下圖，邏輯層次上還是比較清晰。
前端模塊化依賴的主流庫也就數國內的Seajs和國外的requirejs，這里就不陳述。采用了Seajs作為模塊管理器，zepto作為基礎庫文件，lib主要包含了項目中用到的主流第三方庫文件。
我們知道模塊化帶來的最大弊端便是HTTP請求數增加，所以上線的時候必須合并文件。下圖中的package模塊是文件大集合，打包了很多個JS模塊，除去上圖中的基礎庫文件和業務模塊層，在上線的時候大部分文件都被打包在package.js里。
大部分頁面的JS請求是這樣的：
細心點的同學可能注意到兩個問題：文件的大小和加載時間。剛才的截圖還是在PC端截取的，手機和不同網絡環境的表現會更加糟糕。
現在來看下目錄
存在的問題：
- 目錄看起來算規范，但實際上是公共的和業務的混在一塊。
- 大部分文件合并在一個文件，合并策略不合理。
- 由第二點引發的第三個問題，發布上線時，只要兩人發布涉及到package文件，沖突必然發生。
- 發布時需要down下上一次的文件，對照合并的新文件，以免發錯。
- 注意，第四點是人工。一不小心發錯，或者把他人剛發布的文件覆蓋了，這種事情發生10+次。
- 只有一臺測試機器，測試環境經常覆蓋是常事。
- 版本控制問題，不以SVN為版本，而是預發布機器上代碼，管理混亂
不敢想象如果10+人的團隊一起在這種模式下開發，會是怎樣的場面。
22.0時代
由第一個版本引起的問題，著實讓人很蛋疼，每次開發版本就是一次陣痛，尤其是測試、發布環節。所以就開始慢慢著手解決。隨著業務擴展，人員增多，就誕生了下面這個圖。
優化措施：
- 調整模塊，讓共用的模塊更加共用，業務模塊跟隨業務自身。
- 更改模塊合并策略，既然大了，我就分成小，一定程度緩解了沖突。
- 替換原有的同步文件工具，包括測試與正式環境，接入ARS，提測發布流程順暢多了。
- ARS帶有沖突檢測功能，告別人工對照合并，覆蓋不再容易發生。
- 公共JS文件緩存在localstorage中，模擬manifest，帶版本號控制。
- 以SVN為板塊控制工具，不再對照外網代碼。
一些統計
localstorage本地緩存
localstorage緩存命中率
首屏時間
window.onload時間
一切看起來很美好，但是好景不長，因為新的問題又來了。
- 之前拆分package.js文件為多個文件，實際請求的時候則是合并了請求，包括JS文件和CSS文件。combo文件實際上會有延遲問題，在發布的時間節點上存在不同步的問題，直接導致頁面掛了。
- 拋開combo文件不說，由于瀏覽器緩存的問題，每次更新版本的時候要手動加上一個時間戳，來規避緩存造成的錯誤。也是個很蛋疼的點。
- 隨著業務增長，越來越多頁面是放在APP里面訪問。觸屏頁面已經不再是重點，如何更好的利用APP加速頁面才是關注點。很多人想到了手Q的離線包，但聽說實踐起來也不是特別方便，我們就采用了客戶端緩存hash文件的策略，告別304。所以這里又涉及到自動化。
- 雪碧圖基本是手工；
- 代碼混淆沒有壓縮；
CSS合并文件要手寫地址，類似下面：
http://at.qq.com/min/f=cssv4/common/reset.css,cssv4/common/base.css,cssv4/module/btns.css,cssv4/module/tab.css,cssv4/module/app-list.css,cssv4/module/talk-bar.css,cssv4/module/popup.css,cssv4/page/game-detail.css,cssv4/page/talk.css,cssv4/module/comments-bar.css
33.0時代
為了解決上述問題，流程需要進一步優化，簡單點就是讓自動化程度更提高。
3.1 探索期
前期在方案選擇上也做過一些討論，自己完全從底層寫時間上不允許。之前折騰過Grunt發現并不是那么好用，后來發現百度的前端解決方案FIS能夠滿足我們的需求。
- 生成以hash值（后綴）命名的文件，代碼更改，生成新文件，且都會自動更新HTML中的引用（核心訴求），就像下圖：
- 合并雪碧圖
- 壓縮混淆文件
- 文件合并（包括JS文件和CSS文件）
能 做到這幾點基本就滿足了我們的需求。前期的一切都是未知的，不太明白會遇到什么大問題。乍看起來非常好用，如果簡單的頁面，確實會很簡單，只要簡單幾行配 置就可以搞定，但到現在FIS的配置文件200+行。一些特性很難滿足，需要二次開發。上手簡單，要深入難，必須要看源碼改源碼，寫插件，這大概就是用 FIS的心得。
前期想了要怎樣把開發——測試——預發布——發布這個流程依賴工具流暢的跑起來，大概構思如下：
注：
- 調試、發布代碼與源代碼分離
- 本地調試用代理如fiddler，或者上開發機
- deploy是構建工具同步文件的一個功能
- 保證源碼的版本最新，發布代碼走ARS。
工程化進展卻不是想象中的順利，實踐中遇到了一些問題，也只能硬著頭皮咬著牙去解決。
3.2 煎熬期
沖突問題
沖突問題一直存在，在2.0時代不那么明顯罷了。原因是測試環境的JS已經被合并過一次。
時間問題
由于剛開始文件比較少，構建速度基本沒啥問題。后來業務越來越多，參與的開發也越來約多。文件暴增到4000+，構建時間一步步增加。
開發調試耗時 3987ms
發布構建的時候因為要進行md5計算，文件壓縮等，要181745ms！已經無法忍了。
ARS流程
用過ARS的同學肯定明白，流程還是比較蛋疼，要完成提交SVN，點擊同步等等一系列操作，繁瑣。
構建命令
命令比較長，參數多，難以記憶
產出文件多，發布麻煩
每改動一個字母，發布的時候就會生成一個新的文件，發布的時候真是在文件堆里找！！
這一系列的問題如山倒，組內的開發同學已經沒法愉快的開發了。
3.3 深度優化
減少沖突問題
進一步解決的方案還是細分模塊，測試環境不進行文件合并，這樣沖突的概率幾乎很小，因為公共庫經過2.0的調整已經基本穩定。
縮短時間
構建時間這么長，這樣發展下去是不行的。花了一些時間研究FIS源碼，發現FIS監聽的是整個項目文件，每一次構建都要掃描全部文件，這樣時間必然會隨著文件增加而變長。然后進行深度改造，變得不那么像FIS了。 進行一次又一次優化，改變構建策略。
依賴構建：當某個文件依賴另一個文件時，另一個文件才會被構建。假如a.html依賴了b.js ，在構建產出的文件就只有這兩個文件，其他文件不會被構建，文件數也減少，時間大大縮短。
開發構建（單位ms ）
發布構建（單位ms）
構建命令優化
輸入命令麻煩，就用GUI界面，點點按鈕就行。這里要感謝@koppthe@kolawang同學短時間內用node寫的GUI。
產出文件多
依賴構建之后，只會產出相關文件，產出文件大大減少，發布難度減少很多。
ARS流程
修復bug的時候不用ARS同步，監聽文件變化直接同步到測試環境。
只需要8ms！！！。 如果打開了同步按鈕，修改的文件會立馬上傳到測試環境上，會不會有相互覆蓋的問題。組內每個人負責的模塊都不同，而且公共模塊已經基本穩定，很難出現這樣 的問題，在實踐中很少發生這樣的事情，相反小伙伴覺得簡直獲得解脫，相比找文件傳文件這樣繁瑣的流程，這輕松了許多。
發布優化
構建工具會產出文件列表，點擊就能打開文件夾，找到對應文件；列表對應SVN路徑，直接貼到ARS就能提單。
雪碧圖的優化
發布的時候所有引用的CSS文件會合并成一個，然后將引用的圖標合并為雪碧圖，有點粗暴。因為公共的CSS文件的圖片單獨合并為雪碧圖會更加合理，公共的圖片變動頻率不會那么高。開發一插件，在CSS合并前雪碧圖一次，合并后再雪碧圖一次。
統計與優化
用戶網絡類型（粗略）
unknown是無法統計到的，理論上wifi還是占大部分。從其他四種類型看，wifi占據絕大部分，2g用戶非常少。
PC VS Mobile
在JS下載和執行效率上，移動端明顯要低于PC端。
JS優化
之前APP內部的JS文件都是通過seajs來下載文件，后來發覺何不直接干脆點直接寫<script>下載就好了，優化后下載執行時間下降顯著：
注：這里統計的時間，包括了下載JS和執行JS的時間。
JS內嵌與外聯對比
在 考慮優化的時候，我們一種方案便是將外聯的JS代碼（僅業務代碼）通過工具內嵌到頁面。現在來對比下性能：
http://gqq.gtimg.com/static/mobile/js/v3/page/gift/list /inappand.a9a524eb.lc.js文件大小8.7kb，gzip壓縮后3.3kb。
內聯加載時間幾乎為0 0.0015793，外聯的下載時間：
下載時間不到200ms，但相對來說已經是很長了，才8.7kb。
我們知道，DOMContentLoaded事件的觸發基本意味著頁面已經渲染完成，JS已經執行（異步的除外），已經達到可交互的狀態了。下面看下內聯與外聯對DOMContentLoaded的影響：
藍 色線條是外聯的JS，時間明顯要比內聯的高出一些，大概200ms。由此可見，將小量的JS文件內聯到頁面，能夠提高速度。但大的JS文件適不適合內聯， 目前還沒有實驗。這里需要在減少HTTP請求和利用緩存之間把握一個平衡，很多時候優化準則是并不是那么容易實施，因為可能自相矛盾，也可能和工程本身相 矛盾。優化不是按照準則照本宣科的做，需要靈活變通。
優化措施
按照雅虎優化的14條準則，把還沒做到的都處理了。
- 腳本域名切換，去cookie。
- 文件合并
- 利用瀏覽器緩存，無限增大緩存期max-age=15552000
- 雪碧圖
- 減少HTTP請求，構建工具內嵌JS到HTML
- 感覺速度還是不夠快，再充分利用本地緩存和APP提供的緩存能力
- 瀏覽器使用localstorage緩存腳本
- APP緩存hash文件名腳本
- 緩存HTML片段
調試、測試、體驗流程
反向代理+白名單控制策略，域名對外訪問是403，公司內網可訪問。不用代理，手機直接連接wifi訪問。環境分為開發——測試——預發布——正式（每個環境對應一個獨立域名），任何角色（開發、測試、設計、產品）都可隨時訪問。
APP的debug包，可任意切換上面四種環境進行調試、測試、體驗。
總結
這是過去一年工作的總結，一直都沒靜下來梳理。回過頭想，自己是不是把這個流程變得更加復雜了。可能都有一個從簡單到復雜再到簡單的過程，堅持優化一直沒有停下來，只要能夠變得更好一點點，都會去嘗試，所謂生命不息，折騰不止。
文章轉載請保留網址：http://aberdeenanguscattle.com/news/industry/1525.html
