jQuery 動(dòng)畫的原理還是很簡(jiǎn)單的，靠定時(shí)器不斷的改變?cè)氐膶傩?，我們模擬下 animate 的大致實(shí)現(xiàn)，讓元素執(zhí)行一個(gè) 2 秒的動(dòng)畫到坐標(biāo)為 left 50 的區(qū)域。
animate({
left: '50',
duration: '2000'
}
按照常規(guī)的思路，我們需要 3 個(gè)參數(shù)：
思路一：等值變化
我們?cè)?animate 內(nèi)部還需要計(jì)算出當(dāng)然元素的初始化布局的位置（比如 500px），那么我們?cè)?2 秒的時(shí)間內(nèi)需變換成 50px，也就是運(yùn)行的路勁長(zhǎng)就是 500-50 = 450px。
那么算法是不是呼之欲出了？
每毫秒移動(dòng)的距離： pos = 450/2000 = 0.225px 每毫秒移動(dòng)： left = 初始位置 (+/-) 每毫秒遞增的距離（pos * 時(shí)間）
這樣算法我們放到 setInterval 就會(huì)發(fā)現(xiàn)錯(cuò)的一塌糊涂，我們錯(cuò)在最本質(zhì)的東西。
JS 是單線程，定時(shí)器都是排隊(duì)列的，理論上也達(dá)不到 1ms 繪制一次 dom
所以每次產(chǎn)生的這個(gè)下一次繪制的時(shí)間差根本不是一個(gè)等比的，所以我們按照線性的等值遞增是有誤的。
思路二：動(dòng)態(tài)計(jì)算
setInterval 的調(diào)用是不規(guī)律的，但是調(diào)用的時(shí)間是（2秒）是固定的，我們可以在每次調(diào)用的時(shí)候算法時(shí)間差的比值，用這個(gè)比值去計(jì)算移動(dòng)的距離就比較準(zhǔn)確了。
remaining = Math.max(0, startTime + duration - currentTime),
通過這個(gè)公司我們計(jì)算出，每次 setInterval 調(diào)用的時(shí)候，當(dāng)前時(shí)間在總時(shí)間中的一個(gè)位置。
remainin 結(jié)果：
看到?jīng)]有，這個(gè)值其實(shí)很符合定時(shí)器的特性，也是一個(gè)沒有規(guī)律的值，根據(jù)這個(gè)值，我們可以得出當(dāng)前位置的一個(gè)百分比了：
var remaining = Math.max(0, startTime + options.duration - createTime()) var temp = remaining / options.duration || 0; var percent = 1 - temp;
pecent結(jié)果
那么這個(gè)移動(dòng)的距離就很簡(jiǎn)單了，我把整個(gè)公式就直接列出來了。
function tick(){
//每次變化的時(shí)間
var remaining = Math.max(0, startTime + duration - createTime())
var temp = remaining / duration || 0;
var percent = 1 - temp;
//最終每次移動(dòng)的left距離
var leftPos = (endLeft- startLeft) * percent +startLeft;
}
leftPos 就是每次移動(dòng)的距離了，基本上比較準(zhǔn)確了，事實(shí)上 jQuery 內(nèi)部也就是這么干的，這里 13 代表了動(dòng)畫每秒運(yùn)行幀數(shù)，默認(rèn)是13毫秒，屬性值越小，在速度較快的瀏覽器中（例如，Chrome），動(dòng)畫執(zhí)行的越流暢，但是會(huì)影響程序的性能并且占用更多的 CPU 資源，在新的游覽器中，我們都可以采用 requestAnimationFrame 會(huì)更優(yōu)。
請(qǐng)驗(yàn)證，完成請(qǐng)求
由于請(qǐng)求次數(shù)過多，請(qǐng)先驗(yàn)證，完成再次請(qǐng)求
打開微信掃碼自動(dòng)綁定
綁定后可得到
使用 Ctrl+D 可將課程添加到書簽
舉報(bào)