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