近期在研究Cocos引擎的渲染流程。在这里将其整个渲染流程进行一下梳理：
梳理之前我们要知道一些东西，就是我们的Cocos引擎是通过使用OpenGL的一些API来进行渲染绘制的，所以假设我们要彻底理解Cocos引擎的渲染流程并想改动引擎底层渲染的相关内容，熟悉OpenGL是非常有必要的。
这里先简单说一下大概流程，Cocos3.x版本号的渲染是将全部须要渲染的node先通过各种RenderCommand封装起来，你先不用管RenderCommand是什么，仅仅须要记住它把我们要渲染的node封装起来了即可。然后引擎把这些RenderCommand加入到了一个队列中存了起来，这个队列叫CommandQueue，加入的时候顺便对这些RenderCommand设置了一些參数。最后在每一帧结束时调用进行渲染，渲染前会依据ID对RenderCommand进行排序，然后再进行渲染。
好了接下来我们来開始梳理引擎整个的渲染流程了：
首先。整个project的渲染流程的入口在哪里呢？
我们打开project文件文件夹，在platform\win32文件文件夹下找到CCApplication-win3类文件，这里要注意不同平台的不一样，比方mac平台下是platform\mac文件夹下的CCApplication-mac文件，依据我们公布的project平台的不同。这个CCApplication类文件也不同。整个渲染流程就在这个CCApplication类文件run()方法中開始。代码例如以下：
int Application::run(){ ...... director->mainLoop();//进入引擎的主循环...... return 0;}
这里我们要了解一个概念，就是cocos2dx整个project是执行在一个单线程里的。也就是我们常常说的主线程，在主线程里完毕渲染、相关的定时器等等处理。
注意Application::run()中的这句：
director->mainLoop();
这句代码就是进入cocos2d-x的主循环了，这个主循环mainLoop()由导演负责维护。主线程mainloop()会不停地运行。理想状态下每秒会调用60次。
那我们看看CCDirector类里的mainLoop()方法详细做了些什么：
void DisplayLinkDirector::mainLoop(){if (_purgeDirectorInNextLoop)//进入下一个主循环，也就是结束这次的主循环，就净化。也就是一些后期处理 {_purgeDirectorInNextLoop = false;purgeDirector();}else if (_restartDirectorInNextLoop){_restartDirectorInNextLoop = false;restartDirector();}else if (! _invalid){drawScene();//绘制屏幕PoolManager::getInstance()->getCurrentPool()->clear();//释放一些没实用的对象，主要保件内存的合理管理 }}
最開始我还疑惑为什么mainLoop()方法的类是DisplayLinkDirector而不是CCDirector。可是在CCDirector.cpp中我们会找到例如以下代码：
static DisplayLinkDirector *s_SharedDirector = nullptr;Director* Director::getInstance(){if (!s_SharedDirector){s_SharedDirector = new (std::nothrow) DisplayLinkDirector();CCASSERT(s_SharedDirector, "FATAL: Not enough memory");s_SharedDirector->init();}return s_SharedDirector;}
我们能够看到Director类返回的单例对象是一个DisplayLinkDirector类型的。所以这个导演实例要运行mainLoop()方法，这种方法自然是DisplayLinkDirector类里的方法啦。
可是这是不是说明Director类就是DisplayLinkDirector类或继承自DisplayLinkDirector类呢？千万不要这样想！这两个类没有半毛钱关系，我们在CCDirector.h中看到例如以下代码：
class CC_DLL Director : public Ref
能够看出Director类是继承自Ref类的，仅仅是通过getInstance()方法返回的导演类的实例对象是DisplayLinkDirector类型的，CCDisplayLinkDirector类是CCDisplay的子类。从命名就应该能够非常清晰的知道它的用处。这里尽管有点绕。但不要混淆哈！
好了，回过头来，在DisplayLinkDirector::mainLoop()方法中我能够看到这句代码：
void DisplayLinkDirector::mainLoop(){......drawScene();......}
mainloop()假设运行会调用drawScene()，通过drawScene()代码就能够实现场景的绘制了。
那我们继续看看drawScene()详细做了些什么：
void Director::drawScene(){......if (_notificationNode){_notificationNode->visit(_renderer, Mat4::IDENTITY, 0);}......_renderer->render();}
Director::drawScene()做了好多事情。其它的先不看。我们主要关注这两句：
1._notificationNode->visit(_renderer, Mat4::IDENTITY, 0);
2._renderer->render();
先看第一句。这句_notificationNode->visit(_renderer,Mat4::IDENTITY,0),这句事实上是进入了一个循环调用。详细要看CCNode.cpp：
void Node::visit(Renderer* renderer, const Mat4 &parentTransform, uint32_t parentFlags){...... for( ; i < _children.size(); i++ ){auto node = _children.at(i);if (node && node->_localZOrder < 0)node->visit(renderer, _modelViewTransform, flags);elsebreak;}......this->draw(renderer, _modelViewTransform, flags);......}
这个函数有一个循环调用，我们能够看到autonode=_children.at(i);和node->visit(renderer,_modelViewTransform,flags);。这段代码的意思是先获取子节点。然后递归调用节点的visit()函数，到了没有子节点的节点，运行了这句this->draw(renderer,_modelViewTransform,flags)。開始调用draw()函数，那么我们接着看draw()函数代码：
void Node::draw(Renderer* renderer, const Mat4 &transform, uint32_t flags){}
里面什么都没有啊，这是怎么回事？事实上这个draw()函数是个虚函数。所以它运行时运行的是该子节点类的draw()函数。那么我们分别看DrawNode::draw()、Sprite::draw()：
void DrawNode::draw(Renderer *renderer, const Mat4 &transform, uint32_t flags){if(_bufferCount){......renderer->addCommand(&_customCommand);}if(_bufferCountGLPoint){......renderer->addCommand(&_customCommandGLPoint);}if(_bufferCountGLLine){......renderer->addCommand(&_customCommandGLLine);}}
void Sprite::draw(Renderer *renderer, const Mat4 &transform, uint32_t flags){......if(_insideBounds){......renderer->addCommand(&_trianglesCommand);}}
我们能够看到在在这些子类的draw()函数都运行了renderer->addCommand()代码。这是向RenderQueue中加入RenderCommand，在加入时顺便对RenderCommand进行了一些參数设置。当然有的类的draw()不是向RenderQueue中加入RenderCommand，而是直接使用OpenGL的API直接进行渲染。或者做一些其它的事情。
当Director::drawScene()循环调用全然部子节点的visit()方法而且运行完draw()方法，即向RenderQueue中加入完RenderCommand后，我们就看看接下来进行渲染的Renderer::render()函数都做了些什么：
void Renderer::render(){_isRendering = true;if (_glViewAssigned){for (auto &renderqueue : _renderGroups){renderqueue.sort();}visitRenderQueue(_renderGroups[0]);}clean();_isRendering = false;}
看到“renderqueue.sort()"。这是依据ID先对全部RenderCommand进行排序，然后才进行渲染，“visitRenderQueue(_renderGroups[0])”就是来进行渲染的。
那么我们接着看看voidRenderer::visitRenderQueue(constRenderQueue&queue)的代码：
void Renderer::visitRenderQueue(RenderQueue& queue){queue.saveRenderState();const auto& zNegQueue = queue.getSubQueue(RenderQueue::QUEUE_GROUP::GLOBALZ_NEG);if (zNegQueue.size() > 0){if(_isDepthTestFor2D){glEnable(GL_DEPTH_TEST);glDepthMask(true);glEnable(GL_BLEND);RenderState::StateBlock::_defaultState->setDepthTest(true);RenderState::StateBlock::_defaultState->setDepthWrite(true);RenderState::StateBlock::_defaultState->setBlend(true);}else{glDisable(GL_DEPTH_TEST);glDepthMask(false);glEnable(GL_BLEND);RenderState::StateBlock::_defaultState->setDepthTest(false);RenderState::StateBlock::_defaultState->setDepthWrite(false);RenderState::StateBlock::_defaultState->setBlend(true);}for (auto it = zNegQueue.cbegin(); it != zNegQueue.cend(); ++it){processRenderCommand(*it);}flush();}
在visitRenderQueue()方法中我我们看到这一行代码：
processRenderCommand(*it);
这是干什么的呢？这句代码就是进一步进入渲染流程的，我们看一下processRenderCommand()它做了什么：
void Renderer::processRenderCommand(RenderCommand* command){auto commandType = command->getType();if( RenderCommand::Type::TRIANGLES_COMMAND == commandType){......drawBatchedTriangles();......}else if ( RenderCommand::Type::QUAD_COMMAND == commandType ){......drawBatchedQuads();......}else if (RenderCommand::Type::MESH_COMMAND == commandType){......auto cmd = static_cast<MeshCommand*>(command);......cmd->execute();......}......}
我们能够看到，在这里，依据渲染类型的不同。会调用不同的函数。这些函数里有OpenGL的API，没错，这些函数来进行渲染的。比方TRIANGLES_COMMAND类型中调用了drawBatchedTriangles()。QUAD_COMMAND类型中调用了drawBatchedQuads()。MESH_COMMAND类型中调用了MeshCommand::execute()，等等。
举个样例，我们来看下drawBatchedTriangles()方法：
void Renderer::drawBatchedTriangles(){......if (Configuration::getInstance()->supportsShareableVAO()){......}else{......// verticesglVertexAttribPointer(GLProgram::VERTEX_ATTRIB_POSITION, 3, GL_FLOAT, GL_FALSE, kQuadSize, (GLvoid*) offsetof(V3F_C4B_T2F, vertices));// colorsglVertexAttribPointer(GLProgram::VERTEX_ATTRIB_COLOR, 4, GL_UNSIGNED_BYTE, GL_TRUE, kQuadSize, (GLvoid*) offsetof(V3F_C4B_T2F, colors));// tex coordsglVertexAttribPointer(GLProgram::VERTEX_ATTRIB_TEX_COORD, 2, GL_FLOAT, GL_FALSE, kQuadSize, (GLvoid*) offsetof(V3F_C4B_T2F, texCoords));glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, _buffersVBO[1]);glBufferData(GL_ELEMENT_ARRAY_BUFFER, sizeof(_indices[0]) * _filledIndex, _indices, GL_STATIC_DRAW);}......}
能够看到该方法中调用了非常多OpenGL的API，这些方法就是整个渲染流程最后进行渲染的环节。
好了，以上便是Cocos引擎的整个的渲染流程了。
最后用一个流程图对以上内容做一下总结。话说这张图我真的是非常用心画的，改了好多遍最后优化到如今这个样子给大家看，希望对大家有帮助：
以上。
