Chrome開發(fā)工具 時(shí)間軸示例

時(shí)間軸示例：強(qiáng)制同步布局的診斷

該示例展示了怎么使用時(shí)間軸找出一種被稱為“強(qiáng)制同步布局”的性能瓶頸。示例應(yīng)用程序循環(huán)演示了幾張圖片并且強(qiáng)制使用了在執(zhí)行基于幀的動(dòng)畫時(shí)所推薦的 requestAnimationFrame() 方法。但是在動(dòng)畫運(yùn)行的時(shí)候仍然會(huì)出現(xiàn)不大理想的狀況，我們將使用時(shí)間軸來診斷發(fā)生了什么問題。

如果想要了解更多關(guān)于幀模式以及強(qiáng)制同步布局的內(nèi)容，請(qǐng)參考 使用時(shí)間軸 章節(jié)中的 Locating forced synchronous layouts。

制作記錄

首先，你需要制作關(guān)于動(dòng)畫的記錄：

1. 點(diǎn)擊 Start 來啟動(dòng)動(dòng)畫。
2. 打開時(shí)間軸面板，然后找到幀視圖。
3. 點(diǎn)擊時(shí)間軸上的 Record 按鈕。
4. 在一到兩秒后（記錄了大概十到十二幀）停止記錄并且點(diǎn)擊 Stop 來停止動(dòng)畫。

分析記錄

查看記錄中的前幾幀，每一幀的完整時(shí)間都在 300毫秒左右。如果你將你的鼠標(biāo)停在其中一幀的上面，瀏覽器會(huì)顯示出該幀的詳細(xì)信息。

選中記錄中的某個(gè)動(dòng)畫幀，在它的旁邊有個(gè)黃色的警告標(biāo)志，此標(biāo)志說明它是一個(gè)強(qiáng)制同步布局。顏色較暗的圖標(biāo)表明其子記錄中存在有問題的代碼，而不是記錄本身有問題，此時(shí)可以展開 Animation Frame 字段來查看其子記錄。

子記錄顯示了 Recalculate Style 和 Layout 記錄的長(zhǎng)度以及重復(fù)模式。每個(gè)布局記錄都是重新計(jì)算布局得到的結(jié)果，相應(yīng)地，也就是 requestAnimatinoFrame() 處理器請(qǐng)求頁面上的每張圖片的 offsetTop 值時(shí)所獲得的結(jié)果。將你的鼠標(biāo)停留在其中一條記錄上，然后點(diǎn)擊 Layout Forced 屬性旁邊的 source.js 連接。

Sources 面板會(huì)打開源文件第43行的 update() 方法，也就是 requestAnimationCallback() 方法的回調(diào)處理器。該處理器會(huì)計(jì)算圖片 offsetTop 上的 left CSS 樣式屬性。這就使得修改布局后 Chrome 會(huì)立即將其展示出來，以確保它提供的值是正確的。

// 動(dòng)畫循環(huán)
function update(timestamp) {
    for(var m = 0; m < movers.length; m++) {
        movers[m].style.left = ((Math.sin(movers[m].offsetTop + timestamp/1000)+1) * 500) + 'px';
    }
    raf = window.requestAnimationFrame(update);
};

在每個(gè)動(dòng)畫幀中都強(qiáng)制載入頁面布局會(huì)使得運(yùn)行速度變慢，現(xiàn)在我們可以嘗試直接使用 DevTools 來修復(fù)這個(gè)問題。

DevTools 內(nèi)的應(yīng)用修復(fù)

既然我們已經(jīng)知道了造成性能問題的原因，我們就可以直接在 Sources 面板中修改 JavaScript 文件然后立即測(cè)試更改的效果。

1. 在之前打開的 Sources 面板中，用以下代碼替換43行代碼。

通過其他記錄來驗(yàn)證

該動(dòng)畫顯然比以前更快、更流暢，但是衡量一下調(diào)整后的記錄和其他記錄的差異將會(huì)是一種很好的做法。具體的情況應(yīng)該像下面的記錄這樣：