可行性：
游戏循环主要包括这几个部分：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即可，大大提高效率。