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

step 1: 隱身模式打開chrome

目的是避免緩存以及不必要的問題

step 2: 打開測試地址

谷歌性能測試地址 https://googlechrome.github.io/devtools-samples/jank/ 可以看到如下的頁面：

頁面中有一些藍色小方塊在運動

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.75 fps，約等于 8 fps

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

3，點擊 Frames 塊，得到更詳細的數據

點擊 Frames 可以顯示當前關鍵幀的詳細信息：

• 1，duration 是當前幀從 796.31ms 開始等待，796.31 ms + 127.73 ms 后進行了一次渲染

• 2，fps 還是老算法，1000 ms/127.73 ms 約 等于 7fps

• 3，最下面是關鍵幀的視圖畫像

• ---

step 5：了解 FPS 快捷工具

1，在 chrome 中，還有格 more tools 選項，選中 rendering 選項

2，開啟 fps meter 開關

3，直接在頁面上，出現了一個fps統計器

這個東西，暫時先關閉，不利于系統性的學習

三，找到瓶頸

前面已經知道我們的測試頁面有性能問題，那么接下來就要想為什么了？

step 1：了解 Summary

對性能進行錄制完成的時候，會默認在底部展示一個 Summary 摘要，顯示全局的信息

上面展示了 0～5.52 s 錄制時間的具體耗時：

• 1，script 執行耗時 1952.8 ms
• 2，render 渲染耗時 2986.8 ms
• 3，Painting 重繪耗時 472.1 ms

主要就是這 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 行，點擊查看，能夠看到是對每一個元素進行樣式修改

此代碼的問題在于，在每個動畫幀中，它會更改每個方塊的樣式，然后查詢頁面上每個方塊的位置。由于樣式發生了變化，瀏覽器不知道每個方塊的位置是否發生了變化，因此必須重新布局方塊以計算其位置。

避免這種情況的出現，可以參考 https://developers.google.com/web/fundamentals/performance/rendering/avoid-large-complex-layouts-and-layout-thrashing#avoidforcedsynchronous_layouts

step 6：對比優化的效果

demo中存在兩種狀態，優化和非優化 可以看到優化的狀態，script和render的時間都大大減少了 所以fps明顯提高

step 7：性能優化的知識儲備

使用 rail 模型測量性能 https://developers.google.com/web/fundamentals/performance/rail 基礎儲備：

• 渲染性能概述https://developers.google.com/web/fundamentals/performance/rendering/
• A Frame 的剖析 https://aerotwist.com/blog/the-anatomy-of-a-frame/