本文參考自 chrome
的官方文件: 傳送門(需要科學上網)
chrome 的開發者工具中提供了很多高效工具方便我們對頁面進行效能分析.之前自己只用著一些基本的功能, 最近詳細的過了一下官方文件,特別是 performance
皮膚(大部分都是之前的Timeline皮膚) 的使用(需要相對新一些的chrome瀏覽器版本).
Tip: 本文旨在分享給大家使用 chrome
進行效能分析基本方法, 在具體效能問題產生的原因的點上不會太過深入
準備工作
首先,開始分析之前是一些準備工作:
- 進入隱身模式,這是為了避免瀏覽器外掛帶來的干擾
- 開啟
performance
選項卡 - 點選最右邊的設定的小齒輪圖示,如果是移動端專案,開啟
CPU
節流開關,根據電腦效能選擇相應的(用於模擬手機的效能) - 開啟截圖
Screenshots
記錄過程中 每一幀的截圖 - 如果勾選了
memory
還可以看到佔用記憶體的不同組成部分(ex:Heap,node...)在記錄過程中的變化,根據變化的情況看到大致的垃圾回收的週期,以及有無明顯的記憶體洩漏的情況.
官方案例分析
官方案例地址(需要科學上網>_>) 按照上述準備開啟,如果打不開就暫時先看我這邊擷取的圖片;
我們先獲取優化前的各種資料分析:先點選左上角record
圓點記錄優化前版本的執行時效能,過一段時間之後點選停止. 圓點旁邊的圓形箭頭是用於 loading
的效能分析的按鈕.
所得結果如上圖所示.
我們將根據所得的結果一步步分析該 demo
的效能瓶頸是什麼?
先介紹圖中各部的資訊的含義:
- 圖片的右邊標有:
FPS;CPU;NET
-
首先是
FPS
(Analyze frames per second)
幀率;FPS
上的紅色橫條表明,幀率過低已經影響了使用者體驗,通常情況下綠條越高,幀率越高,體驗越好.當幀率不影響使用的時候橫條是不會出現的. -
接下來是
CPU
相關的分析: 如下圖CPU
對應的橫條與下面summary Tab
相一致,這一部分的顏色條也是一一對應. 這一部分佔的越高對CPU
的消耗也就越多.從summary Tab
中還可以看出我們最多的時間其實花費在rendering
中,這也提示了我們demo中的問題極有可能處在渲染相關的程式碼中 . -
在FPS,CPU,NET上 左右移動滑鼠,就可以看到各個時間點的截圖,這在分析動畫執行的各個階段,以及了loading的各個階段的時候尤其有用.
- 然後是名稱在右邊的部分:
-
如果記錄期間包含網路請求那麼在
frame
上面還有一欄Network
,會用不同的顏色表示請求不同的資源 -
然後是 frames 區域: 滑鼠移上去可以讀取到當時的幀率
-
在記錄過程中按快捷鍵cmd + shift + p 然後輸入 show rendering (開啟實時檢視幀率的皮膚),可以看到實時的幀率變化
-
main
代表主執行緒, 一段橫條代表執行一個事件(函式),長度越長,花費的時間越多; 豎向代表呼叫棧.如果在這些橫條中右上角是紅色的就表示在該段程式碼執行過程中可能存在效能問題.
介紹到這裡,我們可以看到上圖中很多黃色橫條的右上角是紅色的,那就讓我們來順便把官方demo中的效能瓶頸排查一下點選展開 main
中的 這一部分:
點選 animation frame fired
事件,可以在下面看到相關資訊. 並且可以定位到 source
皮膚中的相關程式碼.根據定位到的程式碼段,閱讀程式碼我們可以發現,問題是出在選中的藍色背景的這句程式碼中
為什麼這個句程式碼有問題?它強制性的觸發了layout, 這就涉及到重排和重繪的問題,這裡不繼續展開了.感興趣的可以點選下面的參考連結深入瞭解.
最後再補充介紹一下performance
皮膚最下方與 Summary Tab
同級的幾個tab:
- Bottom-Up Tab
在Timeline
中選取一段時間,然後點選Bottom-Up
得到上圖,圖片中展示瀏覽器執行的各個操作說佔用的時間 - Call-tree Tab
同理點選
Call Tree
得到上圖: 表示瀏覽器的基本操作(事件執行,繪製...)所佔用的時間 - Event log Tab
同理點選
Event Log
得到上圖: 可以按照選中時間內事件發生的順序來檢視事件執行所佔用的時間.
tip: 文中的圖片均來自chrome 開發者工具的官方文件.
廣而告之
本文釋出於薄荷前端週刊,歡迎Watch & Star ★,轉載請註明出處。