Chrome運行時性能瓶頸分析

一，初探，根據現象發現問題

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

這裏主要體現的是頁面兩次刷新之間間隔了129.1ms

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…
基礎儲備：

• 渲染性能概述developers.google.com/web/fundame…

• A Frame 的剖析aerotwist.com/blog/the-an…