再看別人實(shí)現(xiàn)粒子效果的時(shí)候會(huì)有以下代碼：

這個(gè)到底是什么意思，它又是怎么用的呢？
window.requestAnimationFrame 告訴瀏覽器您要執(zhí)行的動(dòng)畫(huà)并且請(qǐng)求瀏覽器的在下一個(gè)動(dòng)畫(huà)幀重繪窗口。該方法在瀏覽器重繪之前作為一個(gè)回調(diào)函數(shù)被調(diào)用。
就是告訴瀏覽器在刷新屏幕的時(shí)候，調(diào)用這個(gè)方法。

window.requestAnimationFrame的前世今生：
在90年代，那個(gè)互聯(lián)網(wǎng)做廣告的年代，window上面各種走馬燈，各種狀態(tài)文字都是用setTimeout來(lái)時(shí)實(shí)現(xiàn)的,如下：

動(dòng)畫(huà)的問(wèn)題最棘手的是延時(shí)問(wèn)題，對(duì)于顯示器來(lái)說(shuō)，每一秒60幀頻，如果我們按照瀏覽器的刷新速率來(lái)控制我們的動(dòng)畫(huà)時(shí)間的話(huà)會(huì)有很好的效果，即17ms,setTimeout（callback,1000/60)，但是：
1.各個(gè)瀏覽器及時(shí)精度是不一樣的。
2.對(duì)于setTimeout 和setInterval 實(shí)現(xiàn)機(jī)制并不是我們需要的那樣，當(dāng)經(jīng)過(guò)特定的時(shí)間后，瀏覽器會(huì)將那部分代碼加入到UI的繪制隊(duì)列當(dāng)中，如果這個(gè)時(shí)候UI線(xiàn)程很忙，有其它的任務(wù)阻塞，動(dòng)畫(huà)的下一幀就不會(huì)按時(shí)執(zhí)行。經(jīng)過(guò)長(zhǎng)時(shí)間的累計(jì)堆加之后，可能我們偏離原來(lái)的時(shí)間點(diǎn)誤差越來(lái)越大。

Mozilla 的 Robert O'Callahan 在思考這個(gè)問(wèn)題，并想出了一個(gè)獨(dú)特的方案。他指出CSS transitions 和 animations的優(yōu)勢(shì)在于瀏覽器知道哪些動(dòng)畫(huà)將會(huì)發(fā)生，所以得到正確的間隔來(lái)刷新UI。而javascript動(dòng)畫(huà)，瀏覽器不知道動(dòng)畫(huà)正在發(fā)生。他的解決方案是創(chuàng)建一個(gè)mozRequestAnimationFrame()方法來(lái)告訴瀏覽器哪些javascript代碼正在執(zhí)行，這使得瀏覽在執(zhí)行一些代碼后得到優(yōu)化。

mozRequestAnimationFrame()方法接受一個(gè)參數(shù)，是一個(gè)屏幕重繪前被調(diào)用的函數(shù)。這個(gè)函數(shù)用來(lái)對(duì)生成下合適的dom樣式的改變，這些改變用在下一次重繪中。你可以像調(diào)用setTimeout()一樣的方式鏈?zhǔn)秸{(diào)用mozRequestAnimationFrame()。
這個(gè)就是window.requestAnimationFrame的由來(lái)。

在Mozilla官網(wǎng)看到如下
Because this technology's specification has not stabilized, check the compatibility table for the proper prefixes to use in various browsers. Also note that the syntax and behavior of an experimental technology is subject to change in future version of browsers as the spec changes.
由于這項(xiàng)技術(shù)的規(guī)范還沒(méi)有穩(wěn)定，正確的前綴使用在各種瀏覽器的兼容性表。還要注意的是語(yǔ)法和行為的實(shí)驗(yàn)技術(shù)是如有改變，在未來(lái)版本的瀏覽器的規(guī)格變化。

目前在Android系統(tǒng)下是不支持的，動(dòng)畫(huà)只能setTimeout咯。