可行性：

游戲循環(huán)主要包括這幾個部分：

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

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

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

4、渲染數(shù)據(jù)的生成，在引擎里面就是指node的visit，這里計算生成所有即將發(fā)往OpenGL的數(shù)據(jù)，包括頂點紋理坐標等attribute數(shù)據(jù)，變換矩陣紋理等uniform數(shù)據(jù)，混合模式等渲染狀態(tài);

5、通過OpenGL接口把所有數(shù)據(jù)發(fā)往OpenGL。

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

必要性：

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

一些方案：

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

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

游戲主循環(huán)也是先執(zhí)行游戲邏輯相關(guān)的四個步驟，然后通過條件變量告知渲染線程數(shù)據(jù)已經(jīng)準備好。我們也可以使用雙緩存系統(tǒng)，即創(chuàng)建兩個渲染命令緩存，在渲染線程使用一個命令緩存進行渲染的時候，主線程邏輯可以把渲染命令發(fā)往另一個緩存。

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

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