Cocos2d-x+Lua游戏的优化总结 - 全是干货！ - 推酷
Cocos2d-x+Lua游戏的优化总结 - 全是干货！
准备出安卓版本，在安卓上的性能表现不佳。经过一周多的优化，在性能上取得了较大的提升。游戏采用 Cocos2d-x3.2+Lua 进行开发，以下将在渲染效率，CPU效率，包大小等方面进行总结。
纹理格式 – 运行效率 内存 包大小
所有的图片都通过一个python脚本（调用TexturePacker的命令行工具）自动转换为 RGBA4444 编码的格式。然后判断当前平台为安卓时，将默认纹理格式转换为RGBA4444。
以上的过程会发现一种比较”反常”的现象，就是转成RGBA4444的图片要比原来的图片要大。所以在脚本中不能单纯的转换，需要对比转换前后的大小，只转换变得更小的图片。
还需要注意性能和表现的平衡。有些图片转成RGBA4444后看起来太糙，严重的影响了游戏的视觉体验。对此需要小心的针对处理。处理方法为，在这些纹理使用前将默认纹理格式设置为RGBA8888，然后当纹理使用后再将设置为之前的默认纹理格式。
左图是没有做处理的游戏截图，可见相当不平滑的光线和背景。 右图是只针对背景和光晕的纹理设为RGBA8888处理，视觉体验一下子就回归了。
压缩成RGBA4444格式的PNG图片，还可以用
工具进一步压缩，而视觉体验肉眼感受几乎没有变化。这样可以进一步的减少包的大小。
RGBA4444的纹理内存使用量要比默认的RGBA8888小一半，所以可以很大的减轻游戏的内存压力。而且和PVR ETC等压缩纹理想比，可以一套代码，完全兼容iOS和Android两大移动平台 。所以我认为性价比还是很高的。
纹理剪裁 – 内存 包大小
游戏采用CocoStudio来制作骨骼动画。CocoStudio导出的骨骼动画导出的图片默认是POT(power of two)大小的。其实会造成很多空白像素的浪费，这些空白像素不仅会让图片变大，还会增加纹理的内存。
具体办法是：将导出的POT图片，经过美术或工具的剪裁掉多余的空白像素，使之变成NPOT(non power of two)，然后修改一下plist文件中 &texture& 中的width和height值。对实际的使用是没有任何影响的。
通过把所有POT格式的图片裁剪为NPOT，不仅可以缩减图片的体积，还能减少纹理的内存占用 。
DrawCall OverDraw
在同事对整个包进行DrawCall和OverDraw分析后发现，消除场景内还保留着天空背景。而这层背景实际是玩家看不到，因为它完全被消除场景挡住了。但是它会带来全屏的绘制造成了全屏范围的OverDraw，而且带来了很多额外不必要的DrawCall。将其隐藏后，FPS在低端机上提升明显。
需要把这些看不到的东西全部隐藏或移除掉 ，否则它们会造成OverDraw和不必要的DrawCall，增加了GPU的负担。
隐藏的办法，有些童鞋喜欢将其透明度设为0，但是这样是不会降低DrawCall的。最好的方法是将其 visble 设为 false 。
还有就是场景内有很多细碎的东西，如果它们都是一张张散图储存的话，会使DrawCall居高不下，从而可能导致FPS下降。
解决办法就是尽可能的 将经常一起出现在屏幕上的小图合并成一张大图 。
避免在循环内做重复的运算 。因为如果计算值在整个循环内都不会变的话，那么每次循环都去计算就是浪费CPU周期，应该将计算结果缓存在循环外部。
想办法 避免开销大的函数 （如：开方函数，三角函数），寻找简单运算的替代方案。如：距离的比较可以不用开方先求出距离，而是直接用平方运算进行比较即可。
尽可能的避免同时多个的 cc.RepeatForever 。在低端机上发现在对较多对象调用 cc.RepeatForever 时，FPS下降显著。原因可能是每帧带来的计算，和因此频繁触发的Lua GC。GC是很一个十分耗费CPU的操作。
优化算法，剪枝，去除冗余的计算 。在游戏内的碰撞系统是这么进行优化的：原来对每一个球，会遍历整个空间的碰撞体和墙壁进行碰撞检测；优化后的算法是取球当前的坐标，转换为格子坐标，然后取格子周边6个格子内的碰撞体和墙壁进行碰撞检测。效率提高了很多倍。
避免频繁的开辟内存，对象最好实现复用。开辟内存也是一项很耗费CPU的操作，尤其是在移动设备上内存紧张时。对象能重用尽量重用（建立对象池）。Lua内的表能初始化大小，尽量先初始化大小，否则rehash的操作很费时。
用效率更高的库来替换，比如用cJson来替换Lua json，用pugixml来替代tinyxml2。或者将效率低的模块尝试用更低级的语言进行重写。
出包时，关掉所有的 print 语句和 cclog 语句。你们都知道输出到缓冲区的log有多卡。
预测即将用到的纹理和资源，将其进行异步加载。这样能在用到时，减少掉纹理加载的时间，感觉上会更流畅一些。 移除不用的库
由于引擎使用的是 Cocos2d-x 3.2 版本，所以没有3.3带来的模块精简的功能。但是我们也可以自己去小心翼翼的移除掉游戏根本不会用到的模块。比如：物理引擎，3d模块，CocosBuilder spine等等。
具体的方法是：通过adt的打包日志，分析有哪些库被编译进最终的so文件中，然后去项目内一个一个搜索这些库的名称。找到其对应的 Android.mk 文件，然后尝试移除掉无用库文件，然后尝试编译，确保游戏能正确运行。
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致cocos2d-x如何优化内存的应用
自身以前也写过cocos2d-x如何优化内存的应用，以及内存不够的情况下怎么样处置惩罚游戏。今天在微博中看到有友好简介了下内存，挺详细的。不晓得是谁写的，我纪录下。
一，与图片内存
在IOS上，图片会被积极缩放到2的N次方大小。例如一张的图片，占用的内存与一张的图片是一致的。图片占用内存大小的共计的公式是；长*宽*4。何等一张512*512 占用的内存即是 512*512*4 = 1M。其他尺寸以此类推。（ps:IOS上支持的最大尺寸为）。
二，cocos2d-x 的图片缓存
Cocos2d-x 在机关一个精灵的时辰会运用spriteWithFile或者spriteWithSpriteFrameName等 岂论用哪类方式，cocos2d-x都会将这张图片加载到缓存中。若是是第一次加载这个图片，那就会先将这张图片加载到缓存，往后从缓存读取。假如缓存中已经存在，则直接从缓存中提取，免去了加载进程。
图片的缓存主要由下列两个类来措置：CCSpriteFrameCache， CCTextureCache
CCSpriteFrameCache加载的是一张拼接过的大图，每个小图只不过大图中的一个地域，这些地域信息都在plist文件中生存。用的时辰只重要根据小图的称号便可以加载到这个区域。
CCTextureCache 是寻常的图片缓存，我们所有直接加载的图片都会默许放到这个缓存中，以行进挪用听从。
因而，每次加载一张图片，或者颠末plist加载一张拼接图时，都会将整张图片加载到内存中。假设不去监禁，那就会一直占用着。
三，渲染内存。
不要认为，合计内存时，只算计加载到缓存中的内存便可以了。以一张的图片为例。
CCSprite *pSprite = CCSprite::spriteWithFile(&a.png&);
挪用上边这行代码之后，可以在LEAKS东西中看到，增多了大概4M的内存。而后接着调用
addChild(pSprite);
这时，内存又增进了4M。也便是，一张图片，若是必要渲染的话，那它所占用的内存将要X2。
再看看经过plist加载的图片，例如这张大图尺寸为。想要加载此中的一张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次方况且装的很满。但要寄望，有逻辑相干的图片只管即便打包在一张大图里，其他一点就是打包的时辰要思考到层的漫衍。由于为了渲染依顺可能会用到CCSpriteBatchN对立个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里查抄模拟器中与真机总的内存，会有较大收支。在摹拟器中的终归与实践更接近一些。
(window.slotbydup=window.slotbydup || []).push({
id: '2467140',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467141',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467142',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467143',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467148',
container: s,
size: '1000,90',
display: 'inlay-fix'cocos2d&内存优化
猴子原创，欢迎转载。转载请注明：&转载自，谢谢！
原文地址:&
注：自己以前也写过cocos2d-x如何优化内存的使用，以及内存不足的情况下怎么处理游戏。今天在微博中看到有朋友介绍了下内存，挺详细的。不知道是谁写的，我记录下。
一，IOS与图片内存
在IOS上，图片会被自动缩放到2的N次方大小。比如一张的图片，占用的内存与一张的图片是一致的。图片占用内存大小的计算的公式是；长*宽*4。这样一张512*512
占用的内存就是 512*512*4 = 1M。其他尺寸以此类推。（ps:IOS上支持的最大尺寸为）。
二，cocos2d-x 的图片缓存
Cocos2d-x 在构造一个精灵的时候会使用spriteWithFile或者spriteWithSpriteFrameName等
无论用哪种方式，cocos2d-x都会将这张图片加载到缓存中。如果是第一次加载这个图片，那就会先将这张图片加载到缓存，然后从缓存读取。如果缓存中已经存在，则直接从缓存中提取，免除了加载过程。
图片的缓存主要由以下两个类来处理：CCSpriteFrameCache， CCTextureCache
CCSpriteFrameCache加载的是一张拼接过的大图，每一个小图只是大图中的一个区域，这些区域信息都在plist文件中保存。用的时候只需要根据小图的名称就可以加载到这个区域。
CCTextureCache 是普通的图片缓存，我们所有直接加载的图片都会默认放到这个缓存中，以提高调用效率。
因此，每次加载一张图片，或者通过plist加载一张拼接图时，都会将整张图片加载到内存中。如果不去释放，那就会一直占用着。
三，渲染内存。
不要以为，计算内存时，只计算加载到缓存中的内存就可以了。以一张的图片为例。
CCSprite *pSprite = CCSprite::spriteWithFile("a.png");
调用上边这行代码以后，可以在LEAKS工具中看到，增加了大约4M的内存。然后接着调用
addChild(pSprite);
这时，内存又增加了4M。也就是，一张图片，如果需要渲染的话，那它所占用的内存将要X2。
再看看通过plist加载的图片，比如这张大图尺寸为。想要加载其中的一张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次方并且装的很满。但要注意，有逻辑关系的图片尽量打包在一张大图里，另外一点就是打包的时候要考虑到层的分布。因为为了渲染效率可能会用到CCSpriteBatchN同一个BatchNode里的图片都是位于一个层级的，因此必须根据各个图片的层级关系，打包到不同的plist里。有时内存和效率不可以兼得，只能尽量平衡了。
最后附一个各代IOS设备的内存限制情况
设备&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
建议内存&&&&&&&&&&&&&&&&&&
iPad2/iPhone4s/iphone4&&&&&&&&&&&&&&&
170-180mb&&&&&&&&&&&&&&&&
touch3,4/iphone3gs&&&&&&&&&
40-80mb&&&&&&&&&&&&&&&&&
touch1,2/iPhone3g/iPhone1&&&&&&&&
25mb&&&&&&&&&&&&&&&&&&&
上述建议内存只是一些人自己测试的结果，可用的RAM不大于最大内存的一半，如果程序超过最大内存的一半，则可能会挂掉。
另外在LEAKS里查看模拟器中和真机总的内存，会有较大出入。在模拟器中的结果与实际更接近一些。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。阅读：1266次
本文由子龙山人翻译，转载请注明原出处！！
前言：从上周发布教程的微博反应情况来看，cocos2der们对于游戏的内存问题还是非常关心的。本文是上一篇博文的续，旨在教大家如何减少cocos2d程序的大小。
全文如下：减少你的程序的大小把纹理的颜色位深度减少到16位，不仅可以减少内存压力，还可以有效地减少程序的体积。但是，我们还有其它方法可以更进一步地减少程序的大小。
&TexturePacker PNG 图片优化如果你有某些原因，让你坚持要使用PNG文件格式而不是我之前极力向你推荐的pvr.ccz文件格式，那么TexturePacker有一个选项，叫做“Png Opt Level”(Png优化级别)，可以帮助我们减少png文件的大小（注意：这样并不会影响图片加载时间）
就我目前的理解来看，最大的优化级别可以生成最小的文件大小。但是，它有一个缺点，就是非常耗时。对于2009年出的27寸的iMac来说，处理尺寸稍大的纹理，需要耗费10-20的时间来处理。由于该优化过程采用了多线程的方式，所以，如果你有机器是四核的，那么速度应该会快一些。
当然，你只有在真正发布应用的时候才需要利用这个优化特性。现在的问题是，它到底可以减少多少文件体积呢？
我最大的一张png图片从2.4MB减少到了2.2MB.小一些的纹理从180kb减至130kb。可能单个文件减少的量并不是很多，可是当你的png图片的总大小有18MB时，它可以使之减少至16MB。
注意，在xcode里面有一项设置，你可能会把它忽略掉。你需要关闭"Compress PNG files"开关，因为这个选项有可能会使你的png图片膨胀。你可以在xcode的build settings里面设置，如下所示：
如果激活此png压缩选项，xcode会在png文件打包进程序的时候运行自带的png优化程序。所以，有可能会使我们先前使用TP优化过的png图片再次膨胀。因此，再次确保这个选项已关闭！
不过即使你没有禁用此选项，你的程序大小还是会有所减小。因为，你有可能使用一些没有被TP优化过的png图片。
&检查你的程序在App Store 里面的大小在Xcode里面，运行Archive build（在菜单中选择Product-&Archive）。当build成功的时候，Xcode的Organizer窗口会打开，然后你会看到一个“Estimate Size”（评估大小）的按钮，可以用来估算你的应用程序大小：
移除未使用的资源文件在开发游戏的过程中，你会经常添加、移除和替换游戏资源。所以，你可能会因为某些原因，忘记移除一些不用的图片资源。所以，你需要额外注意把它们都从项目中移除出去，至少要从程序的target中出去。
尤其是你使用多个target的时候（比如，你同时维护ipad和mac版本），你就极有可能会在一个target里面添加一些错误的资源。
当然，在移除资源之后，你一定要充分测试你的游戏。切记！一定要充分测试。
&减少声音文件大小有时候，我们也会忽视这个问题。如果你不考虑声音文件的格式，不管是就内存的使用还是程序的大小而言，都是一种极大的浪费。下面是一些方法可以用来减少声音文件的大小。我推荐大家使用一款免费的声音。
立体声道变单声道 – 你的mp3文件可以采用立体声，但是，这样做值得吗？如果你听不出来差别的话，建议还是采用单一声道。这样可以把文件大小和内存使用都减少一半。
MP3 比特率 –在iOS设备上面，任何比特率大于192kbps的声音都是浪费。你可以尽量采用低的比特率来获得最好的音质效果，这是一个折中。一般来说，96到128kbps对于mp3文件来说够用了。
采样率 – 大部分的声音文件使用11，22，44，或者48kHz采样率。采样率越低，声音文件越小。但是，这样声音质量也会越低。44kHz已经达到了CD的音质了，而48kHz会更好（这个差别只有调音师才可以听出来）
在大部分情况下，44kHz或者更高的比特率都有点浪费。所以，可以尝试下减小采样率（在Audacity里面：Tarck-&Resample）。不要只是修改采样率，因为这样会改变声音文件的音高。
&Streaming MP3 Filesmp3文件的播放，首先是加载到内存中，然后解码为未压缩的声音buffer，最后再播放。
就我目前所知，CocosDenshion的SimpleAudioEngine的playBackgoundMusic是流式播放mp3文件的。流试处理有两个优点：1.更小的内存足迹。2.解码mp3文件采用ios硬件，而不是cpu。但是，硬件一次只能解码一个文件，如果同时播放多个，那么只有一个采用的是硬件解码，其它的都是软件解码。
&减少Tilemap大小许多开发者没有注意到，tilemap大小太大会消耗大量内存。假设你有一个的tilemap，这个大概要消耗1M的内存--如果每一个tile消耗一个字节的内存的话。然而，如果每一个tile大概消耗64个字节的话，那么这个tilemap就会消耗60MB内存。我的天啊！
除了写一个更优的tilemap渲染器以外，我们唯一可以做的就是减少tilemap的大小了，也可以把地图一分为二。
&就没啦?哈哈，是滴。这次，我把文章变短一些，希望你们都看懂了。
相关文章推荐