【转】如何优化Cocos2d-X游戏的内存

Published on 2013 年 2 月 4 日, by donglin

http://blog.chukong-inc.com/index.php/2013/02/04/%E5%A6%82%E4%BD%95%E4%BC%98%E5%8C%96cocos2d-x%E6%B8%B8%E6%88%8F%E7%9A%84%E5%86%85%E5%AD%98/

在游戏项目优化中都会碰到一个问题，如何既能减少内存又能尽量减少包的大小？在实际项目中有些经验分享一下，事实上2D游戏中最占内存的就是图片资源，一张图片使用不同的纹理格式带来的性能差异巨大，下表是我在IOS平台一个小Demo中的测试结果，该Demo的原始内存占用是7M，测试方法是一次性加载5张2048*2048的图片，使用TexturePacker工具生成图片，内存统计使用Instrument工具，加载时间统计用-X引擎提供的CCTime类，单位是微秒。

图片格式	加载时间	内存占用	备注
png	782080	88M	5张 2048*2048 的PNG
pvr.ccz(POT)	394769	102M	5张 2048*2048 的pvr.ccz(POT：2的整次方)
pvr.ccz(NPOT)	338099	85M	5张 2047*1680 的pvr.ccz(NPOT：非2的整次方，即图的实际大小)
pvr(PVRTC4)	8875	33M	5张 2048*2048 的pvr(PVRTC4：压缩比率为8:1的有损压缩，实际测试发现画质基本没有损失)

结论：

1）比较加载速度：原始PNG是最慢的，使用POT的pvr.ccz大约是原始PNG的50%，使用NPOT的pvr.ccz大约是原始PNG的43%，使用pvr则只要原始PNG的1%；

2）比较内存占用：使用POT的pvr.ccz大约是原始PNG的1.2倍，使用NPOT的pvr.ccz和原始PNG差不多，使用pvr只要原始PNG的40%；

从中可以看到，对于尺寸大的图片，选择纹理格式时，最优先使用的是PVR，其次是NPOT的pvr.ccz，考虑到多平台支持，综合起来，对图片资源的管理方案可以如下（以下所说图片尺寸以iPad高清为标准）：

1）对于1024*1024及以下的小图片，还是使用PNG，因为简单，所有平台都能用；

2）对于1024*1024以上的图片，首选用pvr，它能直接载入到IOS设备的显存里，无需经过内存解析，所以快；但是，遗憾1：安卓设备不支持；遗憾2：TP工具不支持生成2048*2048以上的pvr；

3）如2所述，对于2048*2048以上的图片，及安卓设备，则使用NPOT的pvr.ccz，在Cocos2d-x 2.x引擎里默认已经支持，所有3代（iphone 3GS）以后的ios设置都支持cocos2d 2.x（因为它们支持OpenGL ES2.0），所以也都能支持NPOT纹理；

4）经过测试，安卓设备也支持NPOT，所以方案比较简单，1024*1024及以下的用PNG，1024*1024以上的使用NPOT选项的pvr.ccz；

采用以上方案后，游戏所占内存从90多M降到了60多M，在IOS各种设备跑过了，touch3、touch4、iPad1等低端设备都没问题。

cocos2d-x如何优化内存的应用

原地址:http://cblog.chinadaily.com.cn/blog-942327-4327173.html

注：自身以前也写过cocos2d-x如何优化内存的应用，以及内存不够的情况下怎么样处置惩罚游戏。今天在微博中看到有友好简介了下内存，挺详细的。不晓得是谁写的，我纪录下。

一，IOS与图片内存

在IOS上，图片会被积极缩放到2的N次方大小。例如一张1024*1025的图片，占用的内存与一张1024*2048的图片是一致的。图片占用内存大小的共计的公式是；长*宽*4。何等一张512*512 占用的内存即是 512*512*4 = 1M。其他尺寸以此类推。（ps:IOS上支持的最大尺寸为2048*2048）。

二，cocos2d-x 的图片缓存

Cocos2d-x 在机关一个精灵的时辰会运用spriteWithFile或者spriteWithSpriteFrameName等 岂论用哪类方式，cocos2d-x都会将这张图片加载到缓存中。若是是第一次加载这个图片，那就会先将这张图片加载到缓存，往后从缓存读取。假如缓存中已经存在，则直接从缓存中提取，免去了加载进程。

图片的缓存主要由下列两个类来措置：CCSpriteFrameCache， CCTextureCache

CCSpriteFrameCache加载的是一张拼接过的大图，每个小图只不过大图中的一个地域，这些地域信息都在plist文件中生存。用的时辰只重要根据小图的称号便可以加载到这个区域。

CCTextureCache 是寻常的图片缓存，我们所有直接加载的图片都会默许放到这个缓存中，以行进挪用听从。

因而，每次加载一张图片，或者颠末plist加载一张拼接图时，都会将整张图片加载到内存中。假设不去监禁，那就会一直占用着。

三，渲染内存。

不要认为，合计内存时，只算计加载到缓存中的内存便可以了。以一张1024*1024的图片为例。
CCSprite *pSprite = CCSprite::spriteWithFile("a.png");

挪用上边这行代码之后，可以在LEAKS东西中看到，增多了大概4M的内存。而后接着调用
addChild(pSprite);

这时，内存又增进了4M。也便是，一张图片，若是必要渲染的话，那它所占用的内存将要X2。

再看看经过plist加载的图片，例如这张大图尺寸为2048*2048。想要加载此中的一张32*32的小图片
CCSpriteFrameCache::sharedSpriteFrameCache()->addSpriteFramesWithFile("b.plist");

此时内存增加16M （汗）

CCSprite *pSpriteFrame = CCSprite::spriteWithSpriteFrameName("b1.png");
b.png 大小为32*32 ，想着也便是增进一点点内存，可实践情况是增长16M内存。也就是只有渲染了此中的一局部，那末整张图片都要一块儿被加载。

但是环境不是那末的糟糕，这些曾经渲染的图片，假定再次加载的话，内存是不会再持续抬高的，比方又添加了100个b.plist的另一个区域，图片内存照旧共增加16+16 = 32M，而不会继续上升。

四，缓存禁锢

假定游戏有不少场景，在切换场景的时刻可以把前一个场景的内存所有开释，预防总内存过高.

CCTextureCache::sharedTextureCache()->removeAllTextures(); 拘留到今朝为止所有加载的图片

CCTextureCache::sharedTextureCache()->removeUnusedTextures(); 将引用计数为1的图片开释掉CCTextureCache::sharedTextureCache()->removeTexture(); 单独囚系某个图片

CCSpriteFrameCache 与 CCTextureCache 监禁的门径差不久不多。

值得留神的是扣留的机缘，多在切换场景的时刻禁锢资本，假定从A场景切换到B场景，调用的函数顺序为B::init()---->A::exit()---->B::onEnter() 。

可若是使用了切换效果，譬如CTransitionJumpZoom::transitionWithDuration这样的函数，则函数的挪用顺序酿成B::init()---->B::onEnter()---->A::exit() 。

而且第二种方式会有一刹时将两个场景的利润叠加在一起，若是不采用偏激，很可能会由于内存短促而瓦解。

无心强逼监管悉数资源时，会使某个正在履行的动画取得引用而弹出异常，可以挪用CCActionManager::sharedManager()->removeAllActions();来解决。

五，内存优化

优化的心得等于只管即便去拼接图片，使图片边长尽可能的保持2的N次方况且装的很满。但要寄望，有逻辑相干的图片只管即便打包在一张大图里，其他一点就是打包的时辰要思考到层的漫衍。由于为了渲染依顺可能会用到CCSpriteBatchNode;对立个BatchNode里的图片凡是位于一个层级的，是以必须根据各个图片的层级关系，打包到不合的plist里。偶尔内存与依顺不成以兼得，只能只管即便失调了。

六，其他

最后附一个各代IOS设施的内存制约环境
设备                                              倡议内存                   最大内存
iPad2/iPhone4s/iphone4                170-180mb                 512mb
iPad/iPod touch3,4/iphone3gs          40-80mb                  256mb
iPod touch1,2/iPhone3g/iPhone1         25mb                    128mb

上述提倡内存只不过一些人自己测试的事实，可用的RAM不大于最大内存的一半，如果挨次逾越最大内存的一半，则可能会挂掉。
其他在LEAKS里查抄模拟器中与真机总的内存，会有较大收支。在摹拟器中的终归与实践更接近一些。