cocos2d-x中和Android,Windows都一样,如果在主线程中处理一些耗时操作,那么主线程就会出现阻塞现象,表现在界面上就是卡住,未响应等情况。为了避免这种情况的出现,我们需要在后台开辟工作线程进行数据的处理,再采用消息传递或者其他形式来通知主线程进行UI变化。最常见的情况就是游戏进入前的loading。
图片的异步加载
在多线程和同步的第一篇介绍到使用pthread库的时候,讲到由于CCAutoreleasePool不是线程安全的,所以不能在工作线程中引入cocos2d-x相关的API(其实并不是所有的API都不能使用)。但是cocos2d-x显然考虑到这个问题了,所以它本身就帮我们封装好了一个API,避免了还要手动引入pthread库的尴尬。
1
| void CCTextureCache::addImageAsync(const char *path, CCObject *target, SEL_CallFuncO selector)
|
其中path是图片的位置,selector是加载完成时的回调函数。很方便,如果需要加载很多图片的话,对每一个进行回调处理,然后在update中更新UI即可。
plist的异步加载
可是由于内存原因,大部分情况下图片会被合成打包,同时带入plist。这时候如何进行图片的异步加载呢?这个时候就需要对addImageAsync的源码进一步的探究了。
耗时的是什么?
首先要理解的是耗时的动作是什么,只有把耗时的工作真正抓出来丢到工作线程上,异步加载才有意义。我们知道,图片在内存中是以纹理的形式存在的,而图片的加载,通俗来讲也就是纹理的生成,这就是耗时的原因。那CCTexureCache中addImage(同步加载)和addImageAysnc(异步加载)分别做了什么事?
(1)addImage
可以看出addImage使用同步的方式生成了纹理,也就是在主线程中进行了耗时的加载操作。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
| if (! texture) { do { pImage = new CCImage(); CC_BREAK_IF(NULL == pImage); bool bRet = pImage->initWithImageFile(fullpath.c_str(), eImageFormat); CC_BREAK_IF(!bRet); texture = new CCTexture2D(); if( texture && texture->initWithImage(pImage) ) { #if CC_ENABLE_CACHE_TEXTURE_DATA VolatileTexture::addImageTexture(texture, fullpath.c_str(), eImageFormat); #endif m_pTextures->setObject(texture, pathKey.c_str()); texture->release(); } else { CCLOG("cocos2d: Couldn't create texture for file:%s in CCTextureCache", path); } } while (0); }
|
(2)addImageAsync
addImageAsync则是在工作线程中加载图片,然后通过调度器进行纹理的转换。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
| pthread_create(&s_loadingThread, NULL, loadImage, NULL);
CCDirector::sharedDirector()->getScheduler()->scheduleSelector(schedule_selector(CCTextureCache::addImageAsyncCallBack), this, 0, false); void CCTextureCache::addImageAsyncCallBack(float dt) { CCTexture2D *texture = new CCTexture2D(); #if 0 texture->initWithImage(pImage, kCCResolutioniPhone); #else texture->initWithImage(pImage); #endif #if CC_ENABLE_CACHE_TEXTURE_DATA VolatileTexture::addImageTexture(texture, filename, pImageInfo->imageType); #endif }
|
plist加载的原理
之前使用plist是这样子的:
1
| void CCSpriteFrameCache::addSpriteFramesWithFile(const char *pszPlist)
|
在它的实现中,发现了这么一句:
1
| CCTexture2D *pTexture = CCTextureCache::sharedTextureCache()->addImage(texturePath.c_str());
|
原来addSpriteFramesWithFile会先查找是否存在纹理,否则会在.plist的目录下寻找同名图片,然后调用同步的addImage函数来生成纹理。这也就是为什么只加载了plist,而纹理就会存在的原因了。
异步加载plist
知道了这些,那就让addSpriteFramesWithFile调用异步的addImageAsync函数就可以了,当然不需要改源码,因为CCSpriteFrameCache还提供了如下的plist加载方式:
1
| void CCSpriteFrameCache::addSpriteFramesWithFile(const char *pszPlist, CCTexture2D *pobTexture)
|
所以我们可以手动异步生成纹理后,在回调函数中和.plist一起传入addSpriteFramesWithFile,搞定!还记得刚开始的selector么?生成的纹理会作为参数传入这个回调函数中,完美!
注意
只要注意一点的是,在使用任何plist中的小图片时,引擎并不会为每一张小图片生成一个纹理,而是共用了大图片的纹理,同时指定了小图片的坐标和长宽。
示例
其中ui_text.png是大图片,raffle_b_friend.png和raffle_b_diamond.png是两张小图片。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34
| bool CTestLayer::init() { bool bRet=false; do { CC_BREAK_IF(!CCLayer::init()); CCTextureCache::sharedTextureCache()->addImageAsync("ui_text.png",this,callfuncO_selector(CTestLayer::showSprite)); bRet=true; } while (0); return bRet; } void CTestLayer::showSprite(CCObject* obj) { CCTexture2D* texture_ui_text=(CCTexture2D*)obj; CCSpriteFrameCache::sharedSpriteFrameCache()->addSpriteFramesWithFile("ui_text.plist",texture_ui_text); CCSprite* raffle_b_friend=CCSprite::createWithSpriteFrameName("raffle_b_friend.png"); raffle_b_friend->setPosition(ccp(100,100)); this->addChild(raffle_b_friend); CCSpriteFrame* raffle_b_diamond_spriteframe=CCSpriteFrameCache::sharedSpriteFrameCache()->spriteFrameByName("raffle_b_diamond.png"); CCTexture2D* texture=raffle_b_diamond_spriteframe->getTexture(); CCRect rect=raffle_b_diamond_spriteframe->getRect(); CCSprite* raffle_b_diamond=CCSprite::createWithTexture(texture,rect); raffle_b_diamond->setRotation(false); raffle_b_diamond->setPosition(ccp(300,100)); this->addChild(raffle_b_diamond); }
|
效果
使用异步加载plist方式处理:
源码下载
下载地址