在游戏开发中，对游戏对象模型设计并行系统往往是很困难的。一方面，游戏对象之间会存在大量的相互依赖，游戏对象也可能和多个引擎子系统所产生的数据相互依赖。另一方面，游戏对象会与其他游戏对象交流，有时候在更新循环中会多次交流，而交流的模式是不可预期且受玩家输入影响的。这使得游戏对象在多线程中更新变得困难。
虽然，理论上可以设计一些架构来支持并行更新游戏对象。但是从开发者的易用性等角度，大多数游戏引擎仍然是以单线程为主。但是在更底层的引擎子系统中，可以做到部分并行化，使其可以不影响上层的游戏对象模型，例如目前很多游戏引擎都将绘制从游戏引擎分离，使之可以在不同线程绘制。
Cocos2d-x目前仍然是一个单线程的游戏引擎，这使得我们几乎不需要考虑游戏对象更新的线程安全性。然而我们仍然需要关注一些情形如网络请求，异步加载文件，或者异步处理一些逻辑算法等等。
一、在主线程执行异步处理结果
有一些方法必须在主线程执行，例如GL相关的方法。另一些时候，为了保证如Ref对象引用计数的线程安全，我们也应该在主线程去执行这些操作。Scheduler提供了一种简单的机制，使可以在主线程上执行一个方法：
void Scheduler::performFunctionInCocosThread(const std::function &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 *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中的“异步回调”。
