可行性：

遊戲循環主要包括這幾個部分：1，硬件事件，主要就是指觸屏事件，按鍵事件和鼠標事件；2，遊戲事件，主要指定時器事件和預定義事件，比如schedule；3，遊戲邏輯，對於胖腳本端來說，這個就指的腳本邏輯；4，渲染數據的生成，在引擎裏面就是指node的visit，這裏計算生成所有即將發往OpenGL的數據，包括頂點紋理坐標等attribute數據，變換矩陣紋理等uniform數據，混合模式等渲染狀態；5，通過OpenGL接口把所有數據發往OpenGL。這幾個步驟裏面，只有第五個步驟需要涉及到OpenGL操作，而前面四個步驟都是為第五個步驟做準備，而第五個步驟不用或者很少需要反饋數據給前面四個步驟。這是一個典型的生產者消費者模式，在很低線程同步開銷的情況下課采用多線程處理。

必要性：

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

一些方案：

cocos2d-x3.0之後有一個很大的轉變就是不是在visit裏面渲染，而是在visit裏面生成渲染命令，並把命令發往render類緩存，等待某個時機處理這些命令，即渲染。這是一個典型的命令模式，只要保證這些command的執行處理的數據和主線程（遊戲邏輯的執行線程）不一樣或者通過加鎖做好和主線程的數據互斥，就可以保證線程安全。大多數數據我們都可以在visit（其實是draw）裏面生成一份拷貝，而對於較少個數但是每個都包含大量頂點數據的對象，我們可以通過加鎖做好互斥，比如粒子系統。較少的線程互斥操作也不會造成太大線程通信開銷。遊戲主循環也是先執行遊戲邏輯相關的四個步驟，然後通過條件變量告知渲染線程數據已經準備好。我們也可以使用雙緩存系統，即創建兩個渲染命令緩存，在渲染線程使用一個命令緩存進行渲染的時候，主線程邏輯可以把渲染命令發往另一個緩存。如果主線程邏輯確實需要OpenGL處理才能得到的一些數據，我們也可以采用一些較為低效的折中方案。主線程通過類似於schedule的方式把命令發往渲染線程，然後等待，渲染線程維持一個這樣的命令隊列，每個周期優先處理這個隊列，處理完成後通知主線程。這種做法不易多用。說個例子，同步創建紋理並生成sprite的操作，這個生成紋理的部分需要放到渲染線程，這個就可以采用這種方案。而事實上遊戲邏輯根本不需要關心這個紋理到底長什麽樣，主線程可以不用等到渲染線程處理完成這個紋理再繼續運行，渲染線程再處理完成這個紋理後，通過schedule告知主線程，主線程更新這個texture2d對象的紋理ID即可，大大提高效率。

cocos2d-x多線程渲染的一些探討