可行性：

游戲循環主要包括這幾個部分：

硬件事件，主要就是指觸屏事件，按鍵事件和鼠標事件；

游戲事件，主要指定時器事件和預定義事件，比如schedule；

游戲邏輯，對于胖腳本端來說，這個就指的腳本邏輯；

渲染數據的生成，在引擎里面就是指node的visit，這里計算生成所有即將發往OpenGL的數據，包括頂點紋理坐標等attribute數據，變換矩陣紋理等uniform數據，混合模式等渲染狀態；

通過OpenGL接口把所有數據發往OpenGL。

這幾個步驟里面，只有第五個步驟需要涉及到OpenGL操作，而前面四個步驟都是為第五個步驟做準備，而第五個步驟不用或者很少需要反饋數據給前面四個步驟。這是一個典型的生產者消費者模式，在很低線程同步開銷的情況下課采用多線程處理。

必要性：

處理游戲邏輯（包括前四個步驟）承擔了太多cpu運算，而發數據到OpenGL也相當耗時，尤其涉及到多次的渲染狀態切換。在多核cpu上面把二者分開可以提高并行性，進而提高游戲幀率。

一些方案：

cocos2d-x3.0之后有一個很大的轉變就是不是在visit里面渲染，而是在visit里面生成渲染命令，并把命令發往render類緩存，等待某個時機處理這些命令，即渲染。

這是一個典型的命令模式，只要保證這些command的執行處理的數據和主線程（游戲邏輯的執行線程）不一樣或者通過加鎖做好和主線程的數據互斥，就可以保證線程安全。大多數數據我們都可以在visit（其實是draw）里面生成一份拷貝，而對于較少個數但是每個都包含大量頂點數據的對象，我們可以通過加鎖做好互斥，比如粒子系統。較少的線程互斥操作也不會造成太大線程通信開銷。

游戲主循環也是先執行游戲邏輯相關的四個步驟，然后通過條件變量告知渲染線程數據已經準備好。我們也可以使用雙緩存系統，即創建兩個渲染命令緩存，在渲染線程使用一個命令緩存進行渲染的時候，主線程邏輯可以把渲染命令發往另一個緩存。

如果主線程邏輯確實需要OpenGL處理才能得到的一些數據，我們也可以采用一些較為低效的折中方案。主線程通過類似于schedule的方式把命令發往渲染線程，然后等待，渲染線程維持一個這樣的命令隊列，每個周期優先處理這個隊列，處理完成后通知主線程。這種做法不易多用。

說個例子，同步創建紋理并生成sprite的操作，這個生成紋理的部分需要放到渲染線程，這個就可以采用這種方案。而事實上游戲邏輯根本不需要關心這個紋理到底長什么樣，主線程可以不用等到渲染線程處理完成這個紋理再繼續運行，渲染線程再處理完成這個紋理后，通過schedule告知主線程，主線程更新這個texture2d對象的紋理ID即可，大大提高效率。