Cocos2d-x的主线程

在游戏开发领域，为游戏对象模型设计并行系统颇具挑战。一方面，游戏对象之间存在大量相互依赖关系，同时游戏对象还可能与多个引擎子系统产生的数据相互依赖。另一方面，游戏对象会与其他游戏对象进行交流，这种交流在更新循环中可能会多次发生，并且交流模式不可预期，还会受到玩家输入的影响。这些因素导致游戏对象在多线程环境下进行更新变得十分困难。

理论上，我们可以设计一些架构来支持游戏对象的并行更新。但从开发者易用性等方面考虑，大多数游戏引擎仍然以单线程为主。不过，在更底层的引擎子系统中，可以实现部分并行化，且不影响上层的游戏对象模型。例如，目前许多游戏引擎将绘制操作从游戏引擎中分离出来，使其能够在不同线程中进行绘制。

Cocos2d-x目前仍是一个单线程的游戏引擎，这使得我们在很大程度上无需考虑游戏对象更新的线程安全性。然而，我们仍需关注一些特殊情形，如网络请求、异步加载文件或异步处理某些逻辑算法等。

一、在主线程执行异步处理结果

有一些方法必须在主线程中执行，例如与GL相关的方法。另外，为了保证如Ref对象引用计数的线程安全，我们也应该在主线程中执行这些操作。Scheduler提供了一种简单的机制，可用于在主线程上执行一个方法：

void Scheduler::performFunctionInCocosThread(const std::function<void()>& function)
{
_performMutex.lock();
_functionsToPerform.push_back(function);
_performMutex.unlock();
}

首先，我们向Scheduler注册一个方法指针。Scheduler会存储一个需要在主线程执行的方法指针数组。在当前帧所有系统或自定义的schedule执行完毕后，Scheduler会检查该数组并执行其中的方法：

void Scheduler::update(float dt)
{
if (!_functionsToPerform.empty()) {
_performMutex.lock();
// fixed #4123: Save the callback functions, they must be invoked after ‘_performMutex.unlock()’, otherwise if new functions are added in callback, it will cause thread deadlock.
auto temp = _functionsToPerform;
_functionsToPerform.clear();
_performMutex.unlock();
for (const auto& function : temp) {
function();
}
}
}

通过这种机制，我们可以将一个方法转移到主线程执行。需要注意的是，这些方法在主线程中执行的时机是在所有系统或自定义的schedule之后，也就是在UI树遍历之前。

二、文件异步加载完成

在上述机制中，所有向Scheduler注册的方法都会在该帧结束时全部执行。对于一些简单的算法，这种方式没有问题，如图左边的function列表所示。但对于一些耗时的计算，为了不影响游戏性能，我们需要将一系列耗时的方法分布在每一帧中执行。

Cocos2d-x纹理的异步加载完成后，需要将纹理上传至GL内存，因此这个传输过程必须在主线程中执行。然而，glTexImage2D命令用于上传纹理，是一个耗时的操作。试想，如果有多个图片同时完成加载，这些纹理要在同一帧上传至GL内存，可能会导致UI界面出现卡顿现象，影响用户体验。

因此，Cocos2d-x的纹理异步加载回调使用了一个自定义的schedule来处理。在该schedule内部，会检查已经完成加载的纹理，每一帧处理一个纹理，直到所有纹理处理完毕，然后注销schedule。最后纹理在主线程执行的情况如图右边的file列表所示：

TextureCache向Scheduler注册一个更新回调addImageAsyncCallBack：

void TextureCache::addImageAsyncCallBack(float dt)
{
// the image is generated in loading thread
std::deque<ImageInfo*>* imagesQueue = _imageInfoQueue;
_imageInfoMutex.lock();
if (imagesQueue->empty()) {
_imageInfoMutex.unlock();
} else {
ImageInfo* imageInfo = imagesQueue->front();
imagesQueue->pop_front();
_imageInfoMutex.unlock();
AsyncStruct* asyncStruct = imageInfo->asyncStruct;
Image* image = imageInfo->image;
const std::string& filename = asyncStruct->filename;
Texture2D* texture = nullptr;
if (image) {
// generate texture in render thread
texture = new Texture2D();
texture->initWithImage(image);
#if CC_ENABLE_CACHE_TEXTURE_DATA
// cache the texture file name
VolatileTextureMgr::addImageTexture(texture, filename);
#endif
// cache the texture. retain it, since it is added in the map
_textures.insert(std::make_pair(filename, texture));
texture->retain();
texture->autorelease();
} else {
auto it = _textures.find(asyncStruct->filename);
if (it != _textures.end())
texture = it->second;
}
asyncStruct->callback(texture);
if (image) {
image->release();
}
delete asyncStruct;
delete imageInfo;
--_asyncRefCount;
if (0 == _asyncRefCount) {
Director::getInstance()->getScheduler()->unschedule(schedule_selector(TextureCache::addImageAsyncCallBack), this);
}
}
}

当向TextureCache发起一个异步文件加载请求时，TextureCache会向Scheduler注册一个更新回调addImageAsyncCallback，然后开启一个新的线程异步加载文件。在新线程中文件加载完毕后，会将其纹理数据存储在_imageInfoQueue中。主线程每帧被更新回调时会检查该队列是否有数据，如果有则将其纹理数据缓存到TextureCache中，并上传纹理至GL内存，然后删除_imageInfoQueue中的数据。最后，当所有文件都加载完毕，会注销更新回调。

三、异步处理的单元测试

在主线程上执行所有逻辑算法，可大大降低程序复杂度，并且可以在某些方面较为自由地使用多线程。然而，Cocos2d-x的这种回调机制使得单元测试变得困难，因为它依赖于Cocos2d-x的主循环。

单元测试通常用于测试一个同步方法，只需执行该方法，就可以知道其运行结果。单元测试甚至可以不依赖过多的上下文，实际上，过多的上下文会使单元测试变得困难。

对于异步方法，人们通过给单元测试加入一个“等待时间”，来监听回调函数对某个布尔变量值的修改，并告知回调完成，从而完成其单元测试方法。通过这种方式可以测试异步方法。

然而，Cocos2d-x中的异步回调需要游戏循环来驱动，单元测试除了监听异步回调，还需要驱动游戏循环才能执行Schedule，这使得单元测试变得困难。在本书最后一章，我们将给出一种解决方案，使其能够测试Cocos2d-x中的“异步回调”。