前言
計(jì)時(shí)器一直是javascript動(dòng)畫的核心技術(shù)。而編寫動(dòng)畫循環(huán)的關(guān)鍵是要知道延遲時(shí)間多長合適。一方面，循環(huán)間隔必須足夠短，這樣才能讓不同的動(dòng)畫效果顯得平滑流暢；另一方面，循環(huán)間隔還要足夠長，這樣才能確保瀏覽器有能力渲染產(chǎn)生的變化。
大多數(shù)電腦顯示器的刷新頻率是60Hz，大概相當(dāng)于每秒鐘重繪60次。大多數(shù)瀏覽器都會(huì)對重繪操作加以限制，不超過顯示器的重繪頻率，因?yàn)榧词钩^那個(gè)頻率用戶體驗(yàn)也不會(huì)有提升。因此，最平滑動(dòng)畫的最佳循環(huán)間隔是1000ms/60，約等于16.6ms。
而setTimeout和setInterval的問題是，它們都不精確。它們的內(nèi)在運(yùn)行機(jī)制決定了時(shí)間間隔參數(shù)實(shí)際上只是指定了把動(dòng)畫代碼添加到瀏覽器UI線程隊(duì)列中以等待執(zhí)行的時(shí)間。如果隊(duì)列前面已經(jīng)加入了其他任務(wù)，那動(dòng)畫代碼就要等前面的任務(wù)完成后再執(zhí)行。
requestAnimationFrame采用系統(tǒng)時(shí)間間隔，保持最佳繪制效率，不會(huì)因?yàn)殚g隔時(shí)間過短，造成過度繪制，增加開銷；也不會(huì)因?yàn)殚g隔時(shí)間太長，使用動(dòng)畫卡頓不流暢，讓各種網(wǎng)頁動(dòng)畫效果能夠有一個(gè)統(tǒng)一的刷新機(jī)制，從而節(jié)省系統(tǒng)資源，提高系統(tǒng)性能，改善視覺效果。
特點(diǎn)
- requestAnimationFrame會(huì)把每一幀中的所有DOM操作集中起來，在一次重繪或回流中就完成，并且重繪或回流的時(shí)間間隔緊緊跟隨瀏覽器的刷新頻率。
- 在隱藏或不可見的元素中，requestAnimationFrame將不會(huì)進(jìn)行重繪或回流，這當(dāng)然就意味著更少的CPU、GPU和內(nèi)存使用量。
- requestAnimationFrame是由瀏覽器專門為動(dòng)畫提供的API，在運(yùn)行時(shí)瀏覽器會(huì)自動(dòng)優(yōu)化方法的調(diào)用，并且如果頁面不是激活狀態(tài)下的話，動(dòng)畫會(huì)自動(dòng)暫停，有效節(jié)省了CPU開銷。
用法
requestAnimationFrame方法將一個(gè)callback作為參數(shù)，回調(diào)函數(shù)會(huì)被傳入一個(gè)參數(shù)，DOMHighResTimeStamp，指示當(dāng)前被 requestAnimationFrame() 排序的回調(diào)函數(shù)被觸發(fā)的時(shí)間。返回值是一個(gè)請求 ID，表示回調(diào)列表中唯一的標(biāo)識(shí)。可以傳這個(gè)值給 window.cancelAnimationFrame() 以取消回調(diào)函數(shù)。
requestID = window.requestAnimationFrame(callback);
利用這個(gè)api,可以將某些代碼放到下一次重新渲染時(shí)執(zhí)行,避免短時(shí)間內(nèi)觸發(fā)大量reflow。
例如頁面滾動(dòng)事件（scroll）的回調(diào)函數(shù)就很適合使用這個(gè)api, 將回調(diào)操作推遲到下一次重新渲染。但需要注意的是requestAnimationFrame 不管理回調(diào)函數(shù)，即在回調(diào)被執(zhí)行前，多次調(diào)用帶有同一回調(diào)函數(shù)的 requestAnimationFrame，會(huì)導(dǎo)致回調(diào)在同一幀中執(zhí)行多次。最簡單的，可以用節(jié)流函數(shù)來解決這個(gè)問題，也可以想辦法讓requestAnimationFrame的隊(duì)列里同樣的回調(diào)函數(shù)只有一個(gè):
let scheduledAnimationFrame = false;
document.body.onscroll = () => {
if (scheduledAnimationFrame) return;
scheduledAnimationFrame = true;
window.requestAnimationFrame(() => {
scheduledAnimationFrame = false;
// do something
});
};
當(dāng)然，最佳的應(yīng)用場景還是在幀動(dòng)畫里，可以大幅優(yōu)化性能。
面試題
如何渲染幾萬條數(shù)據(jù)并不卡住界面
這道題考察了如何在不卡住頁面的情況下渲染數(shù)據(jù)，也就是說不能一次性將幾萬條都渲染出來，而應(yīng)該一次渲染部分 DOM，那么就可以通過 requestAnimationFrame 來每 16 ms 刷新一次。
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta http-equiv="X-UA-Compatible" content="ie=edge">
<title>Document</title>
</head>
<body>
<ul>控件</ul>
<script>
setTimeout(() => {
// 插入十萬條數(shù)據(jù)
const total = 100000
// 一次插入 20 條，如果覺得性能不好就減少
const once = 20
// 渲染數(shù)據(jù)總共需要幾次
const loopCount = total / once
let countOfRender = 0
let ul = document.querySelector("ul");
function add() {
// 優(yōu)化性能，插入不會(huì)造成回流
const fragment = document.createDocumentFragment();
for (let i = 0; i < once; i++) {
const li = document.createElement("li");
li.innerText = Math.floor(Math.random() * total);
fragment.appendChild(li);
}
ul.appendChild(fragment);
countOfRender += 1;
loop();
}
function loop() {
if (countOfRender < loopCount) {
window.requestAnimationFrame(add);
}
}
loop();
}, 0);
</script>
</body>
</html>
兼容性
一些老的瀏覽器是不支持這個(gè)api的，為了也能使用這個(gè)api, 可以自定義這個(gè)方法，掛載到window下面：
(function() {
var lastTime = 0;
var vendors = ['webkit', 'moz'];
for(var x = 0; x < vendors.length && !window.requestAnimationFrame; ++x) {
window.requestAnimationFrame = window[vendors[x]+'RequestAnimationFrame'];
window.cancelAnimationFrame =
window[vendors[x]+'CancelAnimationFrame'] || window[vendors[x]+'CancelRequestAnimationFrame'];
}
if (!window.requestAnimationFrame)
window.requestAnimationFrame = function(callback) {
var currTime = new Date().getTime();
var timeToCall = Math.max(0, 16 - (currTime - lastTime));
var id = window.setTimeout(function() { callback(currTime + timeToCall); },
timeToCall);
lastTime = currTime + timeToCall;
return id;
};
if (!window.cancelAnimationFrame)
window.cancelAnimationFrame = function(id) {
clearTimeout(id);
};
}());
以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。
