可行性：

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

硬件事件，主要就是指觸屏事件，按鍵事件和鼠標(biāo)事件；

游戲事件，主要指定時(shí)器事件和預(yù)定義事件，比如schedule；

游戲邏輯，對(duì)于胖腳本端來(lái)說(shuō)，這個(gè)就指的腳本邏輯；

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

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

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

必要性：

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

一些方案：

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

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

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

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

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