一個進度條優(yōu)化的例子
功能很簡單：實現(xiàn)一個類似抖音視頻下放的播放進度條, 進度條隨著視頻的長度而進行增長达箍，視頻暫停幻件，進度條的動畫也會隨之暫停
接下來看看大部分人是怎么寫的蛀蜜，為什么說思路和性能不好。 以react為例
主要實現(xiàn)功能：
- 支持播放挽鞠、暫停牵署、重播
- 播放結(jié)束后漏隐，播放次數(shù)+1，并重新開始播放
不推薦的寫法
組件部分
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('播放結(jié)束')
return 0 // 播放結(jié)束奴迅，重新開始播放
}
}
// 開始播放 && 暫停播放
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;
}
效果是這個樣子的
[圖片上傳失敗...(image-125e2-1626945927153)]
為什么說這種寫法不太好呢青责？因為我們是通過定時器來快速遞增變量progress以此來實現(xiàn)進度增加的，變量每次改變都會驅(qū)動視圖重新計算渲染，這必然是性能很差的爽柒。（有肉眼可見的小卡頓哦）
除此之外呢？其實還有一個造成卡頓的原因者填，你們不妨猜猜看浩村。
推薦的寫法
組件部分
// 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) // 播放次數(shù)
const [type, setType] = useState(0) // 使用哪個動畫。0: @keyframes play; 1: @keyframes replay;
// 暫停 && 播放
const handleVideo = () => setIsPlay(!isPlay);
// 重播
const replay = () => {
setIsPlay(true)
setType(type ? 0 : 1)
}
// 動畫結(jié)束時觸發(fā)的事件
const end = () => {
setCount(count + 1) // 播放次數(shù) +1
replay() // 重新開始播放
}
return (
<div id="root">
<button onClick={handleVideo}>{ isPlay ? '暫停' : '播放' }</button>
<button onClick={replay}>重播</button>
<span>{ `播放次數(shù)為：${count}` }</span>
<div className="container">
<div
className={`progress ${isPlay ? 'play' : 'pause'}`}
style={{
animationDuration: `${totalTime}ms`,
animationName: `${type ? 'replay' : 'play'}`
}}
onAnimationEnd={end} // 動畫結(jié)束時的事件
/>
</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動畫是為了在使進度條重新播放時可以做一個切換占哟，即點擊 "重播" 時心墅，直接切換到另一個動畫，就可以實現(xiàn)進度條從0開始遞增
同時我們還設置了兩個類名的樣式榨乎，分別用于控制動畫的播放和暫停
播放完成時怎燥，播放次數(shù)+1的功能可以通過事件animationend來監(jiān)聽即可
同樣的，來看一下這套方案的效果圖（跟前一套方案功能一模一樣）
[圖片上傳失敗...(image-2b8734-1626945927153)]
缺陷
第二種方案雖然性能很好蜜暑，但是與第一種方案一樣铐姚，存在另外一個隱藏的性能問題 >>>>
缺陷：這兩種方案都會引發(fā)頻繁的重排和重繪
可以借助chrome devtools performance來驗證一下頁面的情況
[圖片上傳失敗...(image-a8a761-1626945927153)]
- 小小的一個進度條觸發(fā)了那么那么多次重排和重繪，那么它到底有什么影響呢肛捍？
簡單回顧一下： 重排與重繪
重排：瀏覽器需要重新計算元素的幾何屬性隐绵，而且其他元素的幾何屬性或位置可能也會因此改變受到影響。
重繪：不是所有的DOM變化都影響元素的幾何屬性拙毫，如果改變元素的背景色并不影響它的寬度和高度依许，這種情況，只會發(fā)生一次重繪缀蹄，而不會發(fā)生重排峭跳，因為元素的布局沒改變
所以知道了重排和重繪造成的嚴重問題后，我們馬上對其進行分析優(yōu)化
繼續(xù)優(yōu)化
先看一個傳統(tǒng)的圖：
[圖片上傳失敗...(image-59174b-1626945927153)]
頁面的渲染缺前，大體上走的就是這5個流程蛀醉。當然也有辦法跳過中間某些步驟，例如避免Layout和Paint
再來回顧一下诡延，引起重排和重繪的操作吧滞欠！
觸發(fā)重排的因素：添加或刪除可見的DOM元素、改變元素位置肆良、元素的尺寸改變（包括：外邊距筛璧、內(nèi)邊距、邊框惹恃、高度等）夭谤、內(nèi)容改變（如：文本改變或圖片被另外一個不同尺寸的圖片替代）、瀏覽器窗口尺寸的改變巫糙、通過display: none隱藏?個DOM節(jié)點等
觸發(fā)重繪的因素：重排必定觸發(fā)重繪（重要）朗儒、通過visibility: hidden隱藏?個DOM節(jié)點、修改元素背景色、修改字體顏色等
那么我們前面寫的代碼中到底是哪里觸發(fā)了重排和重繪呢醉锄？簡單檢查一下乏悄，不難發(fā)現(xiàn)兩種方案都是在不停改變元素的width，元素的寬度一改變必然會引起重排和重繪恳不，更何況是超頻繁的改變呢檩小！
解決方案：啟用GPU加速，避開重排和重繪的環(huán)節(jié)烟勋，將進度條單獨提升到一個圖層规求，即不影響其它元素
針對第二套方案來優(yōu)化，我們只需要改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告知瀏覽器提前做好優(yōu)化準備 */
animation-timing-function: linear;
}
.progress.play {
animation-play-state: running;
}
.progress.pause {
animation-play-state: paused;
}
這里簡單解釋一下translateX和scaleX的數(shù)值設置。設置進度條width: 100%沮尿，我們通過scaleX(0.5)將其縮放一半丛塌，可以發(fā)現(xiàn)進度條長度為容器的一半且居中，此時我們就需要通過translateX(-25%)將其向左平移到最左端蛹找，為什么是-25%呢姨伤？因為進度條占了容器的一半且居中，表明左右的留白正好分別是(100% - 50%) / 2 = 25%庸疾，所以也不難得知當初始狀態(tài)scaleX(0)時乍楚，translateX的值為-(100% - 0%) / 2 = -50%
這么做了以后，我們再次用performance檢驗一下
[圖片上傳失敗...(image-64ed59-1626945927153)]
可以很明顯地看到頁面重排重繪的次數(shù)減少了很多很多届慈，剩余的基本都是頁面最基本的重排和重繪了徒溪。
接下來給你們展示一下到底優(yōu)化了多少性能
先用剛極致優(yōu)化完的跑一下performance
[圖片上傳失敗...(image-dc382d-1626945927153)]
看圖中右側(cè)，F(xiàn)PS基本是穩(wěn)定在55 ~ 70之間
再來看看文章開頭第一種方案的performance跑分
[圖片上傳失敗...(image-dcd0aa-1626945927153)]
看圖中右側(cè)金顿，F(xiàn)PS基本是穩(wěn)定在32 ~ 50之間
可以很清楚得看到臊泌，優(yōu)化前的FPS波動非常嚴重，即不夠穩(wěn)定揍拆，所以容易出現(xiàn)卡頓問題渠概；而優(yōu)化后的FPS的變化是不大的，整體變化趨勢比較平嫂拴，幾乎是一直線
在這樣一個極簡頁面中播揪，我們優(yōu)化后性能都大約提升了大約40% ~ 54%
那么如果在正常的項目中，考慮到頁面的復雜性筒狠，我們優(yōu)化后的方案既避免了頁面反復得計算渲染猪狈，又避免了重繪回流，可想而知在那種情形下性能的提升應該是遠不止40% ~ 54%的辩恼。
總結(jié)
啟用GPU加速會將元素提升到單獨的一個圖層中雇庙，我們可以通過chrome devtools layers來查看
[圖片上傳失敗...(image-f5ec23-1626945927153)]
這里就分別展示一下我們優(yōu)化前和優(yōu)化后的頁面分層情況吧
「優(yōu)化前」
[圖片上傳失敗...(image-9ed81f-1626945927153)]
很明顯地看到谓形，整個頁面就只有document層，即進度條沒有被分層出來
「優(yōu)化后」
[圖片上傳失敗...(image-29aca2-1626945927153)]
同樣也很明顯地可以看到疆前，進度條被單獨分出來一個圖層了
