我優化了進度條，頁面性能竟提高了70%

作者：佚名 2021-07-28 14:35:09

我想給大家分享一下這個思路極好的進度條組件，同時它也存在非常嚴重的性能問題，本文末尾也會講解一下問題所在以及優化方式。

[[413837]]

前言

最近準備進行代碼串講，所以梳理了下項目之前的業務代碼。在梳理的過程中，我看到了有個進度條組件寫的非常好，這又想起我剛開始學前端時寫的進度條的代碼，跟這個比起來真的差距太大了（大部分的初學者應該都想不到，而且我第一家實習的公司帶我的mentor亦是如此）。

因此，我想給大家分享一下這個思路極好的進度條組件，同時它也存在非常嚴重的性能問題，本文末尾也會講解一下問題所在以及優化方式

進度條的應用場景

一般進度條組件都出現在類似抖音播放視頻的這樣場景中，如圖中底部的箭頭所示：

image.png

進度條隨著視頻的長度而進行增長，視頻暫停，進度條的動畫也會隨之暫停

接下來看看大部分人是怎么寫的，為什么說思路和性能不好。這里以React為例，Vue開發者也不用怕看不懂，主要是看思路

主要實現功能：

支持播放、暫停、重播
播放結束后，播放次數+1，并重新開始播放

不推薦的寫法

組件部分

// index.jsx  
import { useState } from 'react'  
import './index.css'  
let timer = null  //  遞增進度的定時器  
let totalTime = 3000  // 假設視頻播放為3s  
function App() { 
     const [progress, setProgress] = useState(0)  // 進度  
    const [isPlay, setIsPlay] = useState(false)  // 是否播放     
    // setProgress的遞增邏輯  
    const handlerProgress = pre => {  
        if(pre < 100) return pre + 1;  
        else {    
          alert('播放結束')  
          return 0   // 播放結束，重新開始播放  
        }  
    }  
     // 開始播放 && 暫停播放  
    const handleVideo = () => {  
        setIsPlay(!isPlay)  
        isPlay  
        ? clearInterval(timer)  
        : timer = setInterval(() => setProgress(handlerProgress), totalTime / 100) 
    }  
     // 重播  
    const replay = () => {  
        setIsPlay(true)  
        if(timer) clearInterval(timer);  
        setProgress(0)  
        timer = setInterval(() => setProgress(handlerProgress), totalTime / 100)  
    } 
    return (  
        <div id="root">  
            <button onClick={handleVideo}>{ isPlay ? '暫停' : '播放' }</button>  
            <button onClick={replay}>重播</button>  
            <div className="container">  
                <div className="progress" style={{ width: `${progress}%` }}/>  
            </div>  
        </div>  
    )  
}

樣式部分

.container {  
    height: 10px;  
    border-radius: 5px;  
    border: 1px solid black;  
}  
.progress {  
    height: 100%;  
    width: 0;  
    background-color: red;  
}

來簡單演示一下這個進度條的樣子

0opakkask9kklana669029.gif

為什么說這種寫法不太好呢？因為我們是通過定時器來快速遞增變量progress以此來實現進度增加的，變量每次改變都會驅動視圖重新計算渲染，這必然是性能很差的（說實話，我在體驗這個demo的時候，肉眼可見的小卡頓）

除此之外呢？其實還有一個造成卡頓的原因，你們不妨猜猜看，我們放到最后一起講，想知道答案的小伙伴可以直接滑到下面

推薦的寫法

這里推薦的就是我在閱讀代碼時看到的比較優秀的方案了，接下來分享給大家

組件部分

// index.jsx  
import { useState } from 'react'  
import './index.css'  
let totalTime = 3000  // 假設視頻播放為3s  
function App() {  
    const [isPlay, setIsPlay] = useState(false)  // 是否播放  
    const [count, setCount] = useState(0)  // 播放次數  
    const [type, setType] = useState(0)   // 使用哪個動畫。0: @keyframes play; 1: @keyframes replay;      
    // 暫停 && 播放  
    const handleVideo = () => setIsPlay(!isPlay);   
     // 重播 
    const replay = () => {  
        setIsPlay(true)  
        setType(type ? 0 : 1)  
    }   
     // 動畫結束時觸發的事件  
    const end = () => {  
        setCount(count + 1)  // 播放次數 +1  
        replay()   // 重新開始播放  
    }   
     return (  
        <div id="root">  
            <button onClick={handleVideo}>{ isPlay ? '暫停' : '播放' }</button>  
            <button onClick={replay}>重播</button>  
            <span>{ `播放次數為：${count}` }</span>  
            <div className="container">  
                <div   
                    className={`progress ${isPlay ? 'play' : 'pause'}`}   
                    style={{  
                        animationDuration: `${totalTime}ms`,  
                        animationName: `${type ? 'replay' : 'play'}`  
                    }}  
                    onAnimationEnd={end}  // 動畫結束時的事件  
                />  
            </div>  
        </div>  
    )  
}

樣式部分

@keyframes play {     
    to {  
        width: 100%;  
    }  
}  
@keyframes replay {  
    to {  
        width: 100%;  
    }  
}  
.container {  
    height: 10px;  
    border-radius: 5px;  
    border: 1px solid black;  
} 
.progress {  
    height: 100%;  
    width: 0;  
    background-color: red;  
    animation-timing-function: linear;  
}  
.progress.play {     /* 使animation動畫啟動 */  
    animation-play-state: running;  
}  
.progress.pause {    /* 使animation動畫暫停 */  
    animation-play-state: paused;  
}

我們設置了兩個@keyframes動畫是為了在使進度條重新播放時可以做一個切換，即點擊 "重播" 時，直接切換到另一個動畫，就可以實現進度條從0開始遞增

同時我們還設置了兩個類名的樣式，分別用于控制動畫的播放和暫停

播放完成時，播放次數+1的功能可以通過事件animationend來監聽即可

同樣的，來看一下這套方案的效果圖（跟前一套方案功能一模一樣）

0opakkask9kklana669029.gif

對比一下前一套方案，你就能知道這種寫法不需要去一直修改數據來驅動視圖的改變，減少了框架內的大量計算，提升了不少的性能

缺陷

第二種方案雖然性能很好，但是與第一種方案一樣，存在另外一個隱藏的性能問題，這也是我在排查前同事代碼性能問題時所發現的。

缺陷：這兩種方案都會引發頻繁的重排和重繪

可以借助chrome devtools performance來驗證一下頁面的情況

11010asdakkkakasd69029.gif

小小的一個進度條觸發了那么那么多次重排和重繪，那么它到底有什么影響呢？來簡單回顧一下重排和重繪的影響

重排：瀏覽器需要重新計算元素的幾何屬性，而且其他元素的幾何屬性或位置可能也會因此改變受到影響。

重繪：不是所有的DOM變化都影響元素的幾何屬性，如果改變元素的背景色并不影響它的寬度和高度，這種情況，只會發生一次重繪，而不會發生重排，因為元素的布局沒改變

所以知道了重排和重繪造成的嚴重問題后，我們馬上對其進行分析優化

極致的優化

先來看看一個非常常見的圖

頁面的渲染，大體上走的就是這5個流程。當然也有辦法跳過中間某些步驟，例如避免Layout和Paint

再來回顧一下有哪些方法會引起重排和重繪吧

觸發重排的因素：添加或刪除可見的DOM元素、改變元素位置、元素的尺寸改變（包括：外邊距、內邊距、邊框、高度等）、內容改變（如：文本改變或圖片被另外一個不同尺寸的圖片替代）、瀏覽器窗口尺寸的改變、通過display: none隱藏⼀個DOM節點等

觸發重繪的因素：重排必定觸發重繪（重要）、通過visibility: hidden隱藏⼀個DOM節點、修改元素背景色、修改字體顏色等

那么我們前面寫的代碼中到底是哪里觸發了重排和重繪呢？簡單檢查一下，不難發現兩種方案都是在不停改變元素的width，元素的寬度一改變必然會引起重排和重繪，更何況是超頻繁的改變呢！

解決方案：啟用GPU加速，避開重排和重繪的環節，將進度條單獨提升到一個圖層，即不影響其它元素

就單獨針對第二種方案進行優化吧~我們只需要改動其css內容即可（標注出即為改動處）

@keyframes play {     /* 通過transform來啟用GPU加速，跳過重排重繪階段 */  
    0% {    
        transform: translateX(-50%) scaleX(0);  /* 用 scaleX 來代替 width */  
    }  
    to {  
        transform: translateX(0) scaleX(1);  
    }  
}  
@keyframes replay {  
    0% {  
        transform: translateX(-50%) scaleX(0);  
    }  
    to {  
        transform: translateX(0) scaleX(1);  
    }  
} 
.container {  
    height: 10px;  
    border-radius: 5px;  
    border: 1px solid black;  
}  
.progress {  
    height: 100%;  
    width: 100%;   /* 初始寬度為100%，因為我們要對其縮放 */  
    background-color: red;  
    will-change: transform;   /* 通過will-change告知瀏覽器提前做好優化準備 */  
    animation-timing-function: linear;  
}  
.progress.play {      
    animation-play-state: running;  
}  
.progress.pause {     
    animation-play-state: paused; 
 }

這里簡單解釋一下translateX和scaleX的數值設置。設置進度條width: 100%，我們通過scaleX(0.5)將其縮放一半，可以發現進度條長度為容器的一半且居中，此時我們就需要通過translateX(-25%)將其向左平移到最左端，為什么是-25%呢？因為進度條占了容器的一半且居中，表明左右的留白正好分別是(100% \- 50%) / 2 = 25%，所以也不難得知當初始狀態scaleX(0)時，translateX的值為-(100% \- 0%) / 2 = \-50%

這么做了以后，我們再次用performance檢驗一下