一，初探，根據現象發現問題
chrome的performance知道很久了，但總是沒有特別權威且跟上時代的學習資料，這次痛定思痛，直接看英文文件，一點點把這塊啃掉，本筆記基於Chrome 59
step 1: 隱身模式開啟chrome
目的是避免快取以及不必要的問題
step 2: 開啟測試地址
谷歌效能測試地址googlechrome.github.io/devtools-sa…
可以看到如下的頁面：
頁面中有一些藍色小方塊在運動
step 3: 限制cpu速度
由於有些使用者的裝置cpu效能很高，無法很好的分析移動端，或者發現低階裝置的效能問題，所以我們要降速
找到控制檯中的performance項，找到CPU選項，選擇降低4倍效能或6倍效能
step 4：新增運動小塊，找到效能瓶頸
前面限制了cpu的效能，接下來就要找到效能瓶頸了
連續點選Add 10按鈕，向頁面中新增小塊，直到自己都感覺頁面上小塊運動出現明顯示卡頓
類似下面這種情況，就已經明顯示卡頓了
step 5：先看看優化後的效果會怎樣？
點選一下Optimize優化，觀察一下效果
可以看到頁面瞬間變的賊流暢
step 6：體驗過優化，再體驗一次不優化
再點選一次Un-Optimize（不優化）按鈕，可以看到又卡的要死
ok，到這裡，大家已經能夠通過現象發現效能的差異了，接下來就是要分析現象了
二，瞭解performance各模組
如何分析現象，肯定要依賴資料，這裡就要用到chrome的performance功能了
先將頁面切到非優化的狀態，點選“錄製”按鈕
錄製4s-5s即可：
然後就可以看到錄製的效果了：
上面這些資料看不懂沒關係，現在來一步步瞭解各個部分都有哪些內容
step 1：瞭解Fps
fps：是指頁面每秒幀數
fps = 60 效能極佳
fps < 24 會讓使用者感覺到卡頓，因為人眼的識別主要是24幀
圖中藍色標註出來的區域，就是FPS記錄的資訊
放大點看，FPS由兩部分組成：
1，紅色的條
2，綠色的半透明條
action :1 切換至“已優化”狀態
此時切換優化狀態，到已優化的狀態，再次進行效能錄製：
得到Fps資料如下：
可以看到此時：
1，沒有了紅色條
2，綠色半透明條的高度，明顯要比未優化的場景高度要高不少
總結：
-
紅色：意味著幀數已經下降到影響使用者體驗的程度，chrome已經幫你標註了，這塊有問題
-
綠色：其實就是Fps指數，所有綠色柱體高度越高，效能越好
step 2：瞭解Cpu
上圖中Fps下面的位置，即是Cpu資訊
我們再採集一個真實業務的cpu資料，如下圖：
對比可以發現，cpu資料的一些特性：
-
1，cpu包括兩種狀態：
-
（1）充滿顏色
-
（2）不充滿顏色
-
-
2，cpu是否充滿顏色和fps存在聯絡
step 3：瞭解Net
Net部分可以將螢幕逐幀錄製下來，可以幫助觀察頁面的狀態，主要用處，可以幫助分析首屏渲染速度
step 4：瞭解Frames
1，檢視特定幀的fps
Frames部分，主要用於檢視特定幀的fps，可以檢視特定的幀情況。
2，懸停其上，可以檢視資料
可以看到：
-
這一幀的時間間隔是129.1ms
-
當前的fps是1000ms/129.1ms = 7.75fps，約等於8fps
3，點選Frames塊，得到更詳細的資料
點選Frames可以顯示當前關鍵幀的詳細資訊：
-
1，duration是當前幀從796.31ms開始等待，796.31ms+127.73ms後進行了一次渲染
-
2，fps還是老演算法，1000ms/127.73ms約等於7fps
-
3，最下面是關鍵幀的檢視畫像
step 5：瞭解FPS快捷工具
1，在chrome中，還有格more tools選項，選中rendering選項
2，開啟fps meter開關
3，直接在頁面上，出現了一個fps統計器
這個東西，暫時先關閉，不利於系統性的學習
三，找到瓶頸
前面已經知道我們的測試頁面有效能問題，那麼接下來就要想為什麼了？
step 1：瞭解Summary
對效能進行錄製完成的時候，會預設在底部展示一個Summary摘要，顯示全域性的資訊
上面展示了0～5.52s錄製時間的具體耗時：
-
1，script執行耗時1952.8ms
-
2，render渲染耗時2986.8ms
-
3，Painting重繪耗時472.1ms
主要就是這3個耗時，知道了這三部分耗時，只是知道了，哪有問題，但具體問題在哪呢？
step 2：瞭解Main
上圖，紅色邊框圈出來的，就是Main部分，其中每一塊是每一幀中所做的事情
目前這樣看不出來什麼，腦殼疼，為了方便我們觀看，我們可以在fps、cpu、net模組，點選一下，縮小時間區間
如上圖，可以通過縮小時間區間，從而放大Main中的內容
現在已經能夠看到，Main中展示的是火焰圖，也就是函式呼叫的堆疊
火焰圖，可以簡單理解，x軸表示時間，y軸表示呼叫的函式，函式中還包含依次呼叫的函式，y軸只佔用x軸的一個時間維度
step 3：識別問題，紅色三角號
上圖中，可以看到Animation Frame Fired右上角有個紅色三角號，這就是chrome自動幫助識別出有問題的部分
就像FPS中的紅條一樣，用來識別問題
上圖可以看到提示了Warning : 重複處理程式耗時287.77毫秒
step 4：追溯問題，定位程式碼位置
如上圖，可以看到函式呼叫在程式碼中的位置，可以點選進行檢視
雖然定位到了，是方法update造成的問題，但不夠明確，所以需要進一步探索
step 5：進一步分析問題位置
繼續檢視Main，可以看到app.update下面有很多紫色的條，紫色條本身表示渲染
但請注意！！！ 紫色條上還有更小的
運用前面學過放大功能，調整時間區間
可以看到，每個小紫條上，都有一個紅色三角
前面提到：紅色三角就是chrome幫助自動識別有問題的地方
檢視提示資訊：強制迴流可能是效能瓶頸
點選檢視摘要：
可以看到問題定位在了，app.js的71行，點選檢視，能夠看到是對每一個元素進行樣式修改
此程式碼的問題在於，在每個動畫幀中，它會更改每個方塊的樣式，然後查詢頁面上每個方塊的位置。由於樣式發生了變化，瀏覽器不知道每個方塊的位置是否發生了變化，因此必須重新佈局方塊以計算其位置。
避免這種情況的出現，可以參考developers.google.com/web/fundame…
step 6：對比優化的效果
demo中存在兩種狀態，優化和非優化
可以看到優化的狀態，script和render的時間都大大減少了
所以fps明顯提高
step 7：效能優化的知識儲備
使用rail模型測量效能developers.google.com/web/fundame…
基礎儲備：
-
A Frame 的剖析aerotwist.com/blog/the-an…