性能是個特別有意思的話題,在我之前的工作中,從入門的初級工程師到高級別的技術(shù)專家,大家都很喜歡談性能,我以前參與晉升評審,每年總能聽到很多關于性能的晉升述職
那么，今天我就來談談我眼中的性能。
性能總論
while 循環(huán)快還是 for 循環(huán)快？
|0 是不是比 Math.floor 性能好？
網(wǎng)上隨處可以見到一類對性能的討論。一些新人也非常熱衷此類討論。但是實際上，它們除了讓你寫代碼的時候糾結(jié)之外，毫無意義。
為什么這樣講呢？我想講一個小故事。
從前有個工程師，特別注重代碼細節(jié)，有一天他發(fā)現(xiàn)系統(tǒng)中的一段代碼寫的性能很差，因此，他用匯編重寫了整段代碼，執(zhí)行效率足足提升了三倍。但是最后，大家發(fā)現(xiàn)，用戶反饋性能絲毫沒有提高，因為他優(yōu)化的那個進程名字叫“System Idle”。
所以你看，性能優(yōu)化不能只著眼于局部的代碼。這里，我要提出一個我的觀點：一切沒有 profiling 的性能都是耍流氓。凡是真正有價值的性能優(yōu)化，必定是從端到端的業(yè)務場景建立體系來考慮的。
在我的認識中，性能體系的建立可以分成以下幾部分：
現(xiàn)狀評估和建立指標；
技術(shù)方案；
執(zhí)行；
結(jié)果評估和監(jiān)控。
下面，我就來為你一一講解。
現(xiàn)狀評估和建立指標
要想做好性能優(yōu)化，正確地評估現(xiàn)狀和建立指標是最關鍵的一步，它又往往是會被輕視的一步。
作為一個工程師，指標又要考慮兩個因素。一方面，對用戶來說，什么樣的性能指標能更好地評估它的體驗？另一方面，對公司來說，什么樣的指標會影響業(yè)務價值呢？
在我公布答案之前，我希望你能思考一下，你所負責的業(yè)務，是否有前端性能指標？它是否能夠滿足我上面提到的兩個要求？
在我之前的工作中，整個用了長達一年的時間來探索，才找到了合適的指標，并且回答好了兩個問題。
性能問題可以分成很多方面，最重要的幾個點是：
頁面加載性能；
動畫與操作性能；
內(nèi)存、電量消耗。
注意，這里我們僅僅是對“性能”兩個字的分析和解讀，在對大量的用戶數(shù)據(jù)分析后，我們發(fā)現(xiàn)，其實這三部分中，“頁面加載性能”跟用戶的流失率有非常強的關聯(lián)性，而用戶流失率，正是公司業(yè)務非?？粗氐闹笜?。
因此，在開始階段，我們決定把性能優(yōu)化的重點放在頁面加載性能上。
那么，用什么指標來衡量頁面加載性能呢？最容易想到的方案是“用戶平均加載時間”，事實上，我們在相當長的一段時間，也都是在使用用戶平均加載時間作為性能指標。
但是，很快我們發(fā)現(xiàn)，這個指標有嚴重的問題：
當加載時間低于一定數(shù)字，用戶體感差別不大了，我們經(jīng)過一定的研究，認為這個數(shù)字大約是 1 秒；
少數(shù)超長時間加載的用戶（如 2G），會極大影響整個指標，即指標不能反映大多數(shù)用戶的體驗。
于是，基于以上分析，我們設計了一個新的指標——秒開率，即一秒之內(nèi)打開的用戶占用戶總量的百分比。這個指標后來逐漸推廣到整個公司，甚至影響到了一些業(yè)內(nèi)的其它企業(yè)，現(xiàn)在，談秒開率已經(jīng)是個非常自然的事情了，但是當初的設計確實走了不少彎路。
技術(shù)方案
有了指標，我們就有了優(yōu)化的目標，接下來，就到了技術(shù)出場的環(huán)節(jié)了。
我們這里還是以加載過程為例，來講解一下。
首先我們要簡單分析一下，從輸入 URL 后按下回車，到底發(fā)生了什么。
我們在瀏覽器的原理課程中，已經(jīng)講解了瀏覽器大致的工作過程，但是，我們必須理解幾件事：
從域名到 IP 地址，需要用 DNS 協(xié)議查詢；
HTTP 協(xié)議是用 TCP 傳輸?shù)模詴?TCP 建立連接過程；
如果使用 HTTPS，還有有 HTTPS 交換證書；
每個網(wǎng)頁還有圖片等請求。
從這個分析和實際試驗的結(jié)果看，網(wǎng)頁的加載時間，不但跟體積有關系，還跟請求數(shù)有很大關系，因此，我們最終設計的技術(shù)方案大約可以這樣劃分：
這里僅僅列出了性能優(yōu)化的一部分技術(shù)方案，是我認為比較重要的部分，可以看到，這里涉及的并不僅僅是前端技術(shù)，有服務端、客戶端、設計師團隊，所以要想做好性能優(yōu)化，絕對不能把自己限制在局部的視角，必須是整個業(yè)務一起考慮，才能有良好的收效。
執(zhí)行
技術(shù)方案設計好了，它是不會自己變成線上頁面的，所以，有了技術(shù)方案，我們只完成了一半的工作，接下來我們還需要一個執(zhí)行過程。
執(zhí)行也不簡單，如果說方案主要靠技術(shù)，那么執(zhí)行就是靠工程實施了。
根據(jù)公司的實際情況，工程實施可能有不同的程度，我把工程水平從低到高分成三個階段：
純管理；
制度化；
自動化。
純行政管理，是由經(jīng)理用純粹的管理手段來執(zhí)行方案，比如說，作為前端團隊的 Leader，我可以組織會議，要求整個團隊使用我們前面談的技術(shù)方案。
但是純行政管理有一些問題，一方面，需要的行政資源不一定有，比如我沒法強制讓后端團隊配合我，另一方面，純粹的管理方式，團隊本身的體驗并不好，也不利于團隊成長，最重要的是，純粹管理方式容易造成執(zhí)行不到位。這樣的執(zhí)行方式多數(shù)出現(xiàn)在非技術(shù)崗位。
制度化執(zhí)行方式是用規(guī)則代替人的命令，指定責任人，通過培訓、checklist、定期 review 等具體措施來保證實施。制度化執(zhí)行可以極大地減輕管理工作量，一般現(xiàn)代互聯(lián)網(wǎng)公司都會采用類似的方式。但是制度化執(zhí)行方式還有很大成分是依靠人的主動性的，對程序員來說，還有更好的方式：自動化。
自動化的方式是在一些重要的操作路徑上設置規(guī)則，針對我們的性能優(yōu)化，有兩個點適合做這件事：一個是把開發(fā)好的頁面發(fā)布上線，另一個是開發(fā)好的頁面 URL 投放到首頁等處的鏈接。
在我之前的工作中，我們跟測試團隊配合，開發(fā)了一套頁面性能打分系統(tǒng)，它會自動掃面頁面上的可優(yōu)化點，并且跟發(fā)布平臺和投放平臺合作，把它加入日常機制中?，F(xiàn)在多數(shù)公司都會采用制度化和自動化結(jié)合的執(zhí)行方案。
結(jié)果評估和監(jiān)控
執(zhí)行完了之后，就要向老板匯報爭取升職加薪了，還要有一定的結(jié)果總結(jié)，才是一個完整的工程實施，而且，凡是工程實施，肯定要有一定長效機制，不能優(yōu)化完了退化，這些都要求有線上監(jiān)控機制。
要想做線上監(jiān)控，分兩個部分：
數(shù)據(jù)采集；
數(shù)據(jù)展現(xiàn)。
數(shù)據(jù)采集部分，同樣需要發(fā)布平臺或者開發(fā)工具來配合，對性能數(shù)據(jù)來說，Performance API 非常好用，它是瀏覽器記錄的性能數(shù)據(jù)，一般來說，我們用統(tǒng)一的代碼把它上傳到服務器端就夠用了。
數(shù)據(jù)的展現(xiàn)部分就比較自由了，可以用不同的數(shù)據(jù)可視化方案來展現(xiàn)性能數(shù)據(jù)，沒有一定之規(guī)。一般的數(shù)據(jù)監(jiān)控平臺，會提供報警機制，對性能來說，報警需求不是特別強烈，但是也可以設置一些條件，針對秒開率特別低的網(wǎng)頁報警。
有了監(jiān)控，再配合一定制度，就可以保障整個團隊產(chǎn)出的性能了，要注意，性能不是一個靜態(tài)的事情，指標需要不斷優(yōu)化，技術(shù)方案還需要不斷隨著技術(shù)發(fā)展迭代，制度、自動化工具也需要不斷改進，最終的監(jiān)控平臺產(chǎn)品也不能不做新需求，所以性能應該成為一個團隊的日常工作的一部分，持續(xù)進行。
摘自--極客時間《重學前端》
