聊聊遊戲開發與動畫利器 raf

今年下半年打算正式擼一擼小遊戲，正好這些天整理一下有關遊戲的一些知識，固然了，目前仍是打算使用瀏覽器網頁進行遊戲開發。

網頁遊戲開發的優點與將來

若是使用其餘語言開發遊戲，不管遊戲自己大小與否，咱們都須要遊戲引擎來幫助咱們構建開發，而對於瀏覽器來講，咱們在開發小遊戲時候，利用瀏覽器自己提供的組件和 api 就能夠直接進行業務處理，咱們也能夠更加高效的學習與實踐遊戲邏輯。同時網頁遊戲的構建與發佈也很是簡單。

例如像 Js13kGames (Js13kGames是一個針對 HTML5遊戲開發者的 JavaScript 編碼競賽,該競賽的有趣之處在於將文件大小限制設置爲13 kb ) 這樣的限制代碼量的遊戲開發競賽。對於非網頁遊戲開發來講，這基本上是不可能完成的，由於它們不具有有像瀏覽器這種量級的通用型的工具。

隨着時間的發展，瀏覽器的功能，性能也在不斷提高。經過 WebGL, WebAssembly 各類層出不窮的技術。讓不少以前想都不敢想的功能在瀏覽器上實現。同時,伴隨着 5G 到來，網速的提高，在瀏覽器上開發遊戲充滿了無限的可能。

固然了，事實上，不一樣的遊戲須要不一樣的組件，其中包括數學庫，隨機算法，碰撞及物理引擎，音頻，資源管理，AI機制等等等等，不過在瀏覽器環境下，這些組件均可以作到按需引用。

遊戲循環架構與風格

遊戲自己是基於動畫的。不知道你們在小學的時候有沒有買果或者玩過翻紙動畫？若是你沒有了解過，也能夠看一看bilibili 中的視頻 高中生自制的翻紙動畫短片。視頻中經過快速翻動紙張來實現兩個火彩人打架的精彩動畫。事實上，咱們的電腦，手機設備可以展現動畫都是基於此原理。

所謂動畫，就是不間斷，基於時間和邏輯不斷更新數據以及重繪界面。其核心必定會有至少一個循環。這裏我介紹幾種常見架構。

視窗消息泵

在 Windows 平臺中，遊戲除了須要對自身進行服務外，還須要處理來自於 Windows 系統自己的消息，所以，Windows中有遊戲都會有一段被稱爲消息泵的代碼。其原理是先處理 Windows 的消息，以後再處理遊戲循環邏輯。

// 不斷循環處理
while (true) {
  MSG msg;
  
  // 若是當前消息隊列中有消息，取出消息
  while(PeekMessage(&msg, NULL, 0, 0) > 0) {
    TranslateMessage(&msg);
    DispatchMessage(&msg)
  }
  
  // 執行遊戲循環，相似於更新與重繪
  RunGame()  
}

以上代碼的反作用在於默認設置了遊戲處理消息的的優先級，循環中先處理了 Windows 內部消息。若是遊戲在調整界面或者移動視窗時候，遊戲就會卡住不動。

回調與事件驅動

不少遊戲框架(包括瀏覽器)已經在內部實現了主遊戲循環，咱們沒法直接介入內部循環機制，咱們只可以填充框架中空缺的自定義部分。經過編寫回調函數或者覆蓋框架預設行爲來實行。

例如一些遊戲渲染引擎是這樣實現的:

while(true) {
  // 渲染前執行（遊戲子系統邏輯）  
  for(each frameListener) {
    // 回調函數
    frameListener.frameStarted()
  }
  
  // 渲染  
  renderCurrentScene()
  
  // 場景渲染後執行    
  for(each frameListener) {
    // 回調函數  
    frameListener.frameEnded()
  }  
  
  // 結束場景與交換緩衝區
  finalizeSceneAndSwapBuffers()  
}

而另外一種回調是基於事件驅動，實現方式爲：事件系統會將事件置於不一樣的隊列之中，而後在合適的時機從隊列中取出事件進行處理。這種方式也就是瀏覽器的處理方式，利用消息隊列和事件循環來讓網頁動起來。

while(true) {
  // 從任務隊列中取出任務  
  Task task = task_queue.takeTask(); 
    
  // 執行任務
  ProcessTask(task);
  // 執行各類其餘任務 Process...  
}

而瀏覽器提供的回調就包括 setTimeout(延遲執行) 與 setInterval (間隔執行) requestAnimationFrame(動畫渲染) requestIdleCallback (低優先級任務)。前二者執行時機由用戶指定時機執行，後二者是由瀏覽器控制執行。

setTimeout 是一個定時器，用來指定某個函數在多少毫秒以後執行。他會返回一個編號，表示當前定時器的編號，同時你也可經過 clearTimeout 加入編號來取消定時器的執行。

// 註冊 10 ms 後打印 hello world
const id = setTimeout(() => {
  console.log('hello world')
}, 10)

clearTimeout(id)

結合上面的事件驅動模型，能夠看出該回調函數就是在循環中不斷執行任務,當發現延遲任務隊列中的某個任務超過了當前的時間節點(經過發起時間和設定的延遲時間來計算)，就直接取出任務執行調用。等到期的任務都執行完成後，在進行下一個循環過程，經過這樣的方式，一個完整的定時器就實現了。瀏覽器取消定時器則是經過 id 查找到對應的任務，直接將任務從隊列中刪除。

咱們也能夠經過 setTimout 回調函數內再次執行 setTimout 來實現 setInterval 函數的功能，看起來也相似於間隔執行，其實仍是會有必定的區別。

// 在回調函數完成後纔去設置定時器，時間會超過 16 ms
setTimeout(function render(){
  // 執行須要 6 ms
  // 定時 16ms 後
  console.log(+ new Date())
  setTimeout(render, 500);
}, 500)

// 嘗試每 16 ms 執行一次，無論內部回調函數耗時
setInterval(function render(){
   console.log(+ new Date())
}, 16)

重點在於，JavaScript 自己是單線程的，同時基於上面的事件驅動代碼，咱們只能依賴任務加入順序依次處理任務，沒法切斷當前任務的執行，咱們只可以控制定時器任務什麼時候可以加入隊列，卻沒法控制什麼時候執行，若是其餘任務執行的時間太久的話，定時器任務就必須延後執行，開發者沒有任何辦法。 固然了，社區的力量也是無窮的，facebook 的 React Fiber 就是實現了在渲染更新過程當中斷當前任務，執行優先級更高的任務的功能。

不過像使用瀏覽器的系統(包括遊戲等)都是軟實時系統。所謂軟實時系統，就是即便錯過限按期限也不會形成災難性後果——錯過了當前幀數，現實世界不會所以形成災難性後果，與此相比，航空電子，核能發電等系統都屬因而硬實時系統，錯過時限會有嚴重的後果。不過就算如此，誰會喜歡一個常常卡頓的系統呢？因此實際業務開發中的性能優化仍是重中之重。

固然了， requestAnimationFrame 自己也是回調函數，那麼這個函數究竟有什麼過人之處能夠提高動畫性能呢?在此以前，咱們先介紹一下屏幕刷新率與 Fps 的區別。

屏幕刷新率與 FPS

屏幕刷新率即圖像在屏幕上更新的速度，也即屏幕上的圖像每秒鐘出現的次數，它的單位是赫茲(Hz)。 對於通常筆記本電腦，這個頻率大概是 60Hz，在 Window 10 上 能夠經過桌面上右鍵->顯示設置->高級顯示設置 中查看和設置。屏幕刷新率表示顯示器的物理刷新速度。

對於個人電腦來講，不管我目前是在瀏覽網頁仍是在掛機狀態，當前顯示器都以 1 秒刷新 165 次當前界面，該數值取決於顯示器。咱們也能夠經過修改適配器屬性->監視器來調整屏幕刷新率,通常來講，咱們只要調整到眼睛溫馨便可。

事實上，僅僅靠顯示屏的刷新率是沒有用的，就像上面的循環機制,若是 GPU 處理當前任務的耗時大於當前屏幕刷新的間隔時段。就沒法按時提供圖像。該特性也就是咱們所說的 FPS 每秒傳輸幀數(Frames Per Second)。而對幀數起到決定性的是電腦中的顯卡，顯卡性能越強，幀數也就越高。

即 FPS 幀數是由顯卡決定，刷新率是由顯示器決定。若是顯卡輸出 FPS 低於顯示屏的刷新率，則在顯示屏刷新中將會複用同一張畫面。反過來，顯示器也會丟棄提供過多的圖像。

requestAnimationFrame (Raf) 使用與機制

下面咱們就談一談 raf 函數對比其餘定時器回調的優勢。

首先，raf 函數自己並非一個新特性，就連 IE 10 都提供了支持，因此這裏再也不介紹兼容。設置這個 API 的目的是爲了讓各類網頁動畫效果（DOM動畫、Canvas動畫、SVG動畫、WebGL動畫）可以有一個統一的刷新機制，從而節省系統資源，提升系統性能，改善視覺效果。使用方式以下:

let start = null;
let element = document.getElementById('SomeElementYouWantToAnimate');
element.style.position = 'absolute';

function step(timestamp) {
  if (!start) start = timestamp;
  var progress = timestamp - start;
  element.style.left = Math.min(progress / 10, 200) + 'px';
  if (progress < 2000) {
    window.requestAnimationFrame(step);
  }
}

window.requestAnimationFrame(step);

能夠看到，其實函數使用方式和 setTimeout 基本一致，只不過不須要提供第二個參數。

那麼在沒有第二個參數的狀況下，函數究竟多久執行一次呢？raf 充分利用顯示器的刷新機制，執行頻率和顯示屏的刷新頻率保持同步，利用這個刷新頻率進行頁面重繪。也就是說在個人電腦上，raf 函數每秒執行 165 次。也就是 6 ms 執行一次，若是其餘任務執行事件過長的話，該函數順延到合適的時機。也就是其餘任務執行時間大於 6 ms，函數就會在 12 ms 時候第二次執行，若是大於 12 ms,則會在 18 ms 時候第二次執行。

當看到 raf 函數和屏幕刷新率一致時候，你們也能大體的猜想出，瀏覽器爲何要提供 raf 函數了。由於顯示器和 GPU 屬於兩個不一樣的系統，二者很難協調的運行，即便二者週期一致，也是很難同步起來。

因此當顯示器將一幀畫面繪製完成後，並在準備讀取下一幀以前，顯示器會發出一個垂直同步信號（vertical synchronization）給 GPU，簡稱 VSync。這時候瀏覽器就會利用 VSync 信號來對 raf 進行調用。

CSS 動畫是由瀏覽器渲染進程自動處理的，因此瀏覽器直接讓 css 動畫於 VSync 的時鐘保持一致。可是 js 中 setTimout 和 setInterval 由開發者控制，調用時機基本不可能和 VSync 保持一致。因此瀏覽器爲 js 提供了raf 函數，用來和 VSync 的時鐘週期同步執行。

針對於 VSync，你們能夠參考 理解 VSync 這篇文章。

擴展

注意: 瀏覽器爲了優化後臺頁面的加載損耗以及下降耗電量，會讓沒有激活的瀏覽器標籤 setTimeout 執行間隔大於 1s。requestAnimationFrame 執行速率會不斷降低，同理 requestIdleCallback 也是如此。

同時，相信瀏覽器後面也會函數調度提供更加方便的支持，你們感興趣也能夠了解一下 isInputPending，不過該提案還處於起草階段，工做組還沒有批准，更不用說投入生產中了。

鼓勵一下

若是你以爲這篇文章不錯，但願能夠給與我一些鼓勵，在個人 github 博客下幫忙 star 一下。
博客地址

參考資料

《遊戲引擎架構》

深刻理解 requestAnimationFrame

理解 VSync