我優(yōu)化了進(jìn)度條，頁面性能竟提高了70%
Part1前言
大家好，我是零一。最近我準(zhǔn)備在組里進(jìn)行代碼串講，所以我梳理了下項(xiàng)目之前的業(yè)務(wù)代碼。在梳理的過程中，我看到了有個(gè)進(jìn)度條組件寫的非常好，這又想起我剛開始學(xué)前端時(shí)寫的進(jìn)度條的代碼，跟這個(gè)比起來真的差距太大了（大部分的初學(xué)者應(yīng)該都想不到，而且我第一次實(shí)習(xí)的公司帶我的mentor亦是如此）。
因此，我想給大家分享一下這個(gè)思路極好的進(jìn)度條組件，同時(shí)它也存在非常嚴(yán)重的性能問題，本文末尾也會(huì)講解一下問題所在以及優(yōu)化方式
Part2進(jìn)度條的應(yīng)用場(chǎng)景
一般進(jìn)度條組件都出現(xiàn)在類似抖音播放視頻的這樣場(chǎng)景中，如圖中底部的箭頭所示：
進(jìn)度條隨著視頻的長度而進(jìn)行增長，視頻暫停，進(jìn)度條的動(dòng)畫也會(huì)隨之暫停
接下來看看大部分人是怎么寫的，為什么說思路和性能不好。這里以React為例，Vue開發(fā)者也不用怕看不懂，主要是看思路
主要實(shí)現(xiàn)功能：
支持播放、暫停、重播 播放結(jié)束后，播放次數(shù)+1，并重新開始播放
Part3不推薦的寫法
組件部分
// index.jsx
import { useState } from 'react'
import './index.css'
let timer = null // 遞增進(jìn)度的定時(shí)器
let totalTime = 3000 // 假設(shè)視頻播放為3s
function App() {
const [progress, setProgress] = useState(0) // 進(jìn)度
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;
}
來簡單演示一下這個(gè)進(jìn)度條的樣子
為什么說這種寫法不太好呢？因?yàn)槲覀兪峭ㄟ^定時(shí)器來快速遞增變量progress以此來實(shí)現(xiàn)進(jìn)度增加的，變量每次改變都會(huì)驅(qū)動(dòng)視圖重新計(jì)算渲染，這必然是性能很差的（說實(shí)話，我在體驗(yàn)這個(gè)demo的時(shí)候，肉眼可見的小卡頓）
除此之外呢？其實(shí)還有一個(gè)造成卡頓的原因，你們不妨猜猜看，我們放到最后一起講，想知道答案的小伙伴可以直接滑到下面
Part4推薦的寫法
這里推薦的就是我在閱讀代碼時(shí)看到的比較優(yōu)秀的方案了，接下來分享給大家
組件部分
// index.jsx
import { useState } from 'react'
import './index.css'
let totalTime = 3000 // 假設(shè)視頻播放為3s
function App() {
const [isPlay, setIsPlay] = useState(false) // 是否播放
const [count, setCount] = useState(0) // 播放次數(shù)
const [type, setType] = useState(0) // 使用哪個(gè)動(dòng)畫。0: @keyframes play; 1: @keyframes replay;
// 暫停 && 播放
const handleVideo = () => setIsPlay(!isPlay);
// 重播
const replay = () => {
setIsPlay(true)
setType(type ? 0 : 1)
}
// 動(dòng)畫結(jié)束時(shí)觸發(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} // 動(dòng)畫結(jié)束時(shí)的事件
/>
</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動(dòng)畫啟動(dòng) */
animation-play-state: running;
}
.progress.pause { /* 使animation動(dòng)畫暫停 */
animation-play-state: paused;
}
我們?cè)O(shè)置了兩個(gè)@keyframes動(dòng)畫是為了在使進(jìn)度條重新播放時(shí)可以做一個(gè)切換，即點(diǎn)擊 "重播" 時(shí)，直接切換到另一個(gè)動(dòng)畫，就可以實(shí)現(xiàn)進(jìn)度條從0開始遞增
同時(shí)我們還設(shè)置了兩個(gè)類名的樣式，分別用于控制動(dòng)畫的播放和暫停
播放完成時(shí)，播放次數(shù)+1的功能可以通過事件animationend來監(jiān)聽即可
同樣的，來看一下這套方案的效果圖（跟前一套方案功能一模一樣）
對(duì)比一下前一套方案，你就能知道這種寫法不需要去一直修改數(shù)據(jù)來驅(qū)動(dòng)視圖的改變，減少了框架內(nèi)的大量計(jì)算，提升了不少的性能
Part5缺陷
第二種方案雖然性能很好，但是與第一種方案一樣，存在另外一個(gè)隱藏的性能問題，這也是我在排查前同事代碼性能問題時(shí)所發(fā)現(xiàn)的。
缺陷：這兩種方案都會(huì)引發(fā)頻繁的重排和重繪
可以借助chrome devtools performance來驗(yàn)證一下頁面的情況
小小的一個(gè)進(jìn)度條觸發(fā)了那么那么多次重排和重繪，那么它到底有什么影響呢？來簡單回顧一下重排和重繪的影響
重排：瀏覽器需要重新計(jì)算元素的幾何屬性，而且其他元素的幾何屬性或位置可能也會(huì)因此改變受到影響。
重繪：不是所有的DOM變化都影響元素的幾何屬性，如果改變?cè)氐谋尘吧⒉挥绊懰膶挾群透叨?，這種情況，只會(huì)發(fā)生一次重繪，而不會(huì)發(fā)生重排，因?yàn)樵氐牟季譀]改變
所以知道了重排和重繪造成的嚴(yán)重問題后，我們馬上對(duì)其進(jìn)行分析優(yōu)化
Part6極致的優(yōu)化
先來看看一個(gè)非常常見的圖
頁面的渲染，大體上走的就是這5個(gè)流程。當(dāng)然也有辦法跳過中間某些步驟，例如避免Layout和Paint
再來回顧一下有哪些方法會(huì)引起重排和重繪吧
觸發(fā)重排的因素：添加或刪除可見的DOM元素、改變?cè)匚恢谩⒃氐某叽绺淖儯òǎ和膺吘?、?nèi)邊距、邊框、高度等）、內(nèi)容改變（如：文本改變或圖片被另外一個(gè)不同尺寸的圖片替代）、瀏覽器窗口尺寸的改變、通過display: none隱藏?個(gè)DOM節(jié)點(diǎn)等
觸發(fā)重繪的因素：重排必定觸發(fā)重繪（重要）、通過visibility: hidden隱藏?個(gè)DOM節(jié)點(diǎn)、修改元素背景色、修改字體顏色等
那么我們前面寫的代碼中到底是哪里觸發(fā)了重排和重繪呢？簡單檢查一下，不難發(fā)現(xiàn)兩種方案都是在不停改變?cè)氐?code style="font-size: 14px;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px;color: rgb(30, 107, 184);background-color: rgba(27, 31, 35, 0.05);font-family: "Operator Mono", Consolas, Monaco, Menlo, monospace;word-break: break-all;">width，元素的寬度一改變必然會(huì)引起重排和重繪，更何況是超頻繁的改變呢！
解決方案：啟用GPU加速，避開重排和重繪的環(huán)節(jié)，將進(jìn)度條單獨(dú)提升到一個(gè)圖層，即不影響其它元素
就單獨(dú)針對(duì)第二種方案進(jìn)行優(yōu)化吧~我們只需要改動(dòng)其css內(nèi)容即可（標(biāo)注出即為改動(dòng)處）
@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%，因?yàn)槲覀円獙?duì)其縮放 */
background-color: red;
will-change: transform; /* 通過will-change告知瀏覽器提前做好優(yōu)化準(zhǔn)備 */
animation-timing-function: linear;
}
.progress.play {
animation-play-state: running;
}
.progress.pause {
animation-play-state: paused;
}
這里簡單解釋一下translateX和scaleX的數(shù)值設(shè)置。設(shè)置進(jìn)度條width: 100%，我們通過scaleX(0.5)將其縮放一半，可以發(fā)現(xiàn)進(jìn)度條長度為容器的一半且居中，此時(shí)我們就需要通過translateX(-25%)將其向左平移到最左端，為什么是-25%呢？因?yàn)檫M(jìn)度條占了容器的一半且居中，表明左右的留白正好分別是(100% - 50%) / 2 = 25%，所以也不難得知當(dāng)初始狀態(tài)scaleX(0)時(shí)，translateX的值為-(100% - 0%) / 2 = -50%
這么做了以后，我們?cè)俅斡?code style="font-size: 14px;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px;color: rgb(30, 107, 184);background-color: rgba(27, 31, 35, 0.05);font-family: "Operator Mono", Consolas, Monaco, Menlo, monospace;word-break: break-all;">performance檢驗(yàn)一下
可以很明顯地看到頁面重排重繪的次數(shù)減少了很多很多，剩余的基本都是頁面最基本的重排和重繪了。
有人要說我標(biāo)題黨了，接下來給你們展示一下到底優(yōu)化了多少性能
先用剛極致優(yōu)化完的跑一下performance
看圖中右側(cè)，F(xiàn)PS基本是穩(wěn)定在55 ~ 70之間
再來看看文章開頭第一種方案的performance跑分
看圖中右側(cè)，F(xiàn)PS基本是穩(wěn)定在32 ~ 50之間
可以很清楚得看到，優(yōu)化前的FPS波動(dòng)非常嚴(yán)重，即不夠穩(wěn)定，所以容易出現(xiàn)卡頓問題；而優(yōu)化后的FPS的變化是不大的，整體變化趨勢(shì)比較平，幾乎是一直線
在這樣一個(gè)極簡頁面中，我們優(yōu)化后性能都大約提升了大約40% ~ 54%
那么如果在正常的項(xiàng)目中，考慮到頁面的復(fù)雜性，我們優(yōu)化后的方案既避免了頁面反復(fù)得計(jì)算渲染，又避免了重繪回流，可想而知在那種情形下性能的提升應(yīng)該是遠(yuǎn)不止40% ~ 54%的，emmmmmm，所以我說性能提高70%應(yīng)該也不是很過分吧 hhhhh
Part7小彩蛋
啟用GPU加速會(huì)將元素提升到單獨(dú)的一個(gè)圖層中，我們可以通過chrome devtools layers來查看
這里就分別展示一下我們優(yōu)化前和優(yōu)化后的頁面分層情況吧
「優(yōu)化前」
很明顯地看到，整個(gè)頁面就只有document層，即進(jìn)度條沒有被分層出來
「優(yōu)化后」
同樣也很明顯地可以看到，進(jìn)度條被單獨(dú)分出來一個(gè)圖層了
Part8結(jié)尾
如果你覺得這篇內(nèi)容對(duì)你挺有啟發(fā)，我想邀請(qǐng)你幫我三個(gè)小忙：
點(diǎn)個(gè)「在看」，讓更多的人也能看到這篇內(nèi)容（喜歡不點(diǎn)在看，都是耍流氓 -_-） 歡迎加我微信「TH0000666」一起交流學(xué)習(xí)... 關(guān)注公眾號(hào)「前端Sharing」，持續(xù)為你推送精選好文。