一個Chrome 運行時性能瓶頸分析案例

初診

打開Chrome隱身模式

主要是爲了確保有一個乾淨的測試環境, 不被其它因素所影響.

打開測試地址

谷歌性能測試地址 googlechrome.github.io/devtools-sa…

國內性能測試地址: gitee.com/hellojamesz…

能夠看到以下畫面:

能夠看到頁面藍色小方塊在運動

限制CPU速度

有些用戶電腦的CPU性能很好, 可能沒法較好的分析問題(難以發現低端配置設備的性能問題), 因此須要降速.

在Chrome瀏覽器控制檯中找到"Performance" => "CPU"選項, 選擇下降4/6倍性能

添加更多小方塊, 找到性能瓶頸

上面已經限制了CPU的性能, 接下來須要尋找性能瓶頸了.

屢次點擊"Add 10", 向頁面中添加小塊, 直到感受頁面上小塊運動時出現明顯卡頓便可.

此時, 已經能夠明顯感受到頁面很卡頓了.

優化先後的效果對比

經過點擊"Optimize"按鈕, 能夠提早感覺下優化先後的效果對比

能夠明顯感覺到優化先後頁面的流暢度明顯不同.

瞭解Performance各模塊

如何分析問題, 確定是要依賴數據, 這裏須要使用到Chrome的Performance功能.

將頁面切換至非優化的狀態, 點擊"Record".

錄製的結果以下圖所示:

以上數據初學者可能看不明白, 不要緊, 咱們來一步步瞭解各部分的含義

FPS

fps, 指頁面每秒幀數

• fps = 60性能最佳
• fps < 24會讓用戶感受到卡頓, 由於人眼的識別主要是24幀

圖中藍色標記出的區域, 即FPS記錄的信息 放大某一區域, 能夠看到, FPS由兩部分組成:

• 紅色的條
• 綠色的半透明條

切換至優化狀態

切換至已優化狀態, 再進行錄製後, 獲得FPS數據以下:

能夠看出:

• 沒有了紅色條
• 綠色半透明條的高度, 明顯比沒有優化時高很多

小結

• 紅色, 即幀數已經降低到影響用戶體驗的程度, Chrome已經標註出來, 這塊有問題
• 綠色, 即FPS指數, 全部綠色柱體高度越高, 性能越好

瞭解CPU

上圖中FPS下的位置, 即CPU信息 咱們採集些一個真實業務的CPU數據, 這裏我抓取的是我的簡書的performance, 以下圖所示:

對比能夠發現, CPU數據的一些特性:

• CPU包括兩種狀態
  • 充滿顏色
  • 不充滿顏色
• CPU是否充滿顏色和FPS存在聯繫

瞭解NET

NET部分能夠將屏幕逐幀錄製下來, 能幫忙觀察頁面的狀態, 分析首屏渲染速度

瞭解Frames

查看特定幀的FPS

Frames部分, 主要用於查看特定幀的FPS, 能夠查看特定的幀狀況, 懸停其上, 能夠查看數據.

能夠看到:

• 這一幀的時間間隔是: 327ms
• 當前FPS是1000ms/327ms = 3fps 這裏主要體現的是頁面兩次刷新之間間隔了327ms

查看某個Frames塊更詳細的信息

點擊某個Frames塊, 能夠查看到更加詳細的數據

點擊某個Frames塊, 能夠查看到更加詳細的數據

• Duration, 是當前幀從1.02s開始等待, 1.02s+326.97ms後進行了一次渲染
• fps, 1000ms/326.97ms = 3fps
• 最下面的是當前幀的視圖畫像

瞭解FPS快捷工具

在Chrome中, 還有一個More Tools選項, 選中"Rendering"選項

接着, 開啓"FPS meter"選項

勾選後, 在頁面上會出現一個FPS統計器, 如上圖左上角.

暫時先不勾選"FPS meter", 不利於系統性學習

找到瓶頸

經過前面的內容, 咱們已經知道頁面有性能問題, 那接下來就要開始尋找緣由了.

瞭解 Summary

對性能進行錄製完成時, 會默認在底部顯示一個 Summary摘要, 顯示全局信息.

上面展現了0~4.90s錄製時間的具體耗時:

• script, 耗時1534ms
• rendering, 耗時2557ms
• Painting, 耗時281ms

主要了解這3個耗時, 但瞭解這3個耗時, 對於哪有問題, 還須要進一步的排查.

瞭解 Main

上圖紅色框出部分, 就是Main, 其中每一塊是每一幀中所作的事情

目前仍看不出什麼. 爲了方便觀看, 咱們可在fps, cpu, net模塊, 點擊一下, 縮小時間區間:

如上圖所示, 經過縮小時間區間, 來實現放大Main中的內容. 如今已經可以看到, Main中展現的"火焰圖", 即函數調用的堆棧. 其中:

• x軸表示時間
• y軸表示調用函數, 函數中還包含依次調用的函數, y軸只佔用x軸的一個時間維度

識別問題, 紅色三角號

上圖中, 能夠看到Animation Frame Fired右上角有一個紅色三角號, 這是Chrome自動幫助識別出有問題的部分, 就像FPS中的紅色同樣, 用來識別問題

上圖能夠到提示"Warning: Recurring handler took 318.21 ms", 即重複處理程序耗時318.21ms

追溯問題, 定位代碼問題

點擊Animation Frame Fired下面的"Function Call"

如上圖, 能夠看到函數調用代碼中的位置, 能夠點擊進行查看:

雖然定位到了, 是方法 update形成的問題, 但不夠明確, 因此須要進一步探索.

進一步分析問題位置

繼續查看Main, 能夠看到app.update下面有不少"紫色"的條, 紫色條自己表示渲染. 但請 注意!!!的是紫色條上還有更小的, 運用前面學過的放大功能, 調整時間區間.

能夠看到, 每一個紫色條都有一個紅色的小三角, 前面提到"紅色三角是Chrome幫助自動識別有問題的地方", 查看提示信息: "Forced reflow is a likely performance bottleneck.", 即強制迴流多是性能瓶頸

點擊查看摘要.

能夠看到, 問題定位在了 performanceTest.html的第136行, 點擊查看, 可以看到是對每個元素進行樣式修改.

這段代碼的問題在於, 在每一個動畫幀中, 它會更改每一個方塊的樣式, 而後查詢頁面上每一個方塊的位置. 因爲樣式發生了變化, 瀏覽器不知道每一個方塊的位置是否發生了變化, 所以必須從新佈局方塊以計算其位置.

避免這種狀況的出現, 能夠參考: 避免大型、複雜的佈局和佈局抖動

對比優化的效果

能夠看到, 優化後的狀態, script, render的時間都大大減小了, 所以fps明顯提升.

性能優化知識儲備

• 使用 rail 模型測量性能
• 基礎儲備
  • 渲染性能概述
  • A Frame的剖析

相關連接

• Chrome性能測試demo
• Chrome性能測試demo-國內
• 避免大型、複雜的佈局和佈局抖動
• 性能優化知識儲備
  • 使用 rail 模型測量性能
  • 基礎儲備
    • 渲染性能概述
    • A Frame的剖析

掘金: 一個Chrome 運行時性能瓶頸分析案例