可行性：
游戲循環(huán)主要包括這幾個部分：
1、硬件事件，主要就是指觸屏事件，按鍵事件和鼠標(biāo)事件;
2、游戲事件，主要指定時器事件和預(yù)定義事件，比如schedule;
3、游戲邏輯，對于胖腳本端來說，這個就指的腳本邏輯;
4、渲染數(shù)據(jù)的生成，在引擎里面就是指node的visit，這里計(jì)算生成所有即將發(fā)往OpenGL的數(shù)據(jù)，包括頂點(diǎn)紋理坐標(biāo)等attribute數(shù)據(jù)，變換矩陣紋理等uniform數(shù)據(jù)，混合模式等渲染狀態(tài);
5、通過OpenGL接口把所有數(shù)據(jù)發(fā)往OpenGL。
這幾個步驟里面，只有第五個步驟需要涉及到OpenGL操作，而前面四個步驟都是為第五個步驟做準(zhǔn)備，而第五個步驟不用或者很少需要反饋數(shù)據(jù)給前面四個步驟。這是一個典型的生產(chǎn)者消費(fèi)者模式，在很低線程同步開銷的情況下課采用多線程處理。
必要性：
處理游戲邏輯(包括前四個步驟)承擔(dān)了太多cpu運(yùn)算，而發(fā)數(shù)據(jù)到OpenGL也相當(dāng)耗時，尤其涉及到多次的渲染狀態(tài)切換。在多核cpu上面把二者分開可以提高并行性，進(jìn)而提高游戲幀率。
一些方案：
cocos2d-x3.0之后有一個很大的轉(zhuǎn)變就是不是在visit里面渲染，而是在visit里面生成渲染命令，并把命令發(fā)往render類緩存，等待某個時機(jī)處理這些命令，即渲染。
這是一個典型的命令模式，只要保證這些command的執(zhí)行處理的數(shù)據(jù)和主線程(游戲邏輯的執(zhí)行線程)不一樣或者通過加鎖做好和主線程的數(shù)據(jù)互斥，就可以保證線程安全。大多數(shù)數(shù)據(jù)我們都可以在visit(其實(shí)是draw)里面生成一份拷貝，而對于較少個數(shù)但是每個都包含大量頂點(diǎn)數(shù)據(jù)的對象，我們可以通過加鎖做好互斥，比如粒子系統(tǒng)。較少的線程互斥操作也不會造成太大線程通信開銷。
游戲主循環(huán)也是先執(zhí)行游戲邏輯相關(guān)的四個步驟，然后通過條件變量告知渲染線程數(shù)據(jù)已經(jīng)準(zhǔn)備好。我們也可以使用雙緩存系統(tǒng)，即創(chuàng)建兩個渲染命令緩存，在渲染線程使用一個命令緩存進(jìn)行渲染的時候，主線程邏輯可以把渲染命令發(fā)往另一個緩存。
如果主線程邏輯確實(shí)需要OpenGL處理才能得到的一些數(shù)據(jù)，我們也可以采用一些較為低效的折中方案。主線程通過類似于schedule的方式把命令發(fā)往渲染線程，然后等待，渲染線程維持一個這樣的命令隊(duì)列，每個周期優(yōu)先處理這個隊(duì)列，處理完成后通知主線程。這種做法不易多用。
說個例子，同步創(chuàng)建紋理并生成sprite的操作，這個生成紋理的部分需要放到渲染線程，這個就可以采用這種方案。而事實(shí)上游戲邏輯根本不需要關(guān)心這個紋理到底長什么樣，主線程可以不用等到渲染線程處理完成這個紋理再繼續(xù)運(yùn)行，渲染線程再處理完成這個紋理后，通過schedule告知主線程，主線程更新這個texture2d對象的紋理ID即可，大大提高效率。
下載文檔
