http://wap.oschina.net/question/565065_79814
在目前的移动平台游戏开发过程中，很多朋友会遇到开发出来的DEMO占用内存过大，导致渲染效率低下的问题。究其原因，是由硬件本身和软件逻辑两方面的因素造成的。在硬件上，移动设备往往可用内存相比于PC还比较小，所以所能使用的内存就少。在软件逻辑上，大量使用大图片导致占用内存过大，以及过多单图片导致渲染时多次切换使用的纹理，也会大大降低渲染效率。本节我将带领大家进入到纹理优化的实际操作中，希望可以抛砖引玉，使大家对于纹理优化有更好的认识。
首先，硬件的内存限制我们是没有办法逾越的。比如当下流行的Iphone 4S 总内存容量为512M，而实际可用的内存大大少于这个数字，所以在你开发一款游戏时，一定要清楚的知道你的程序在运行时的内存需求量，它务必要小于可用内存，而且要越少越好。我们在开发2D游戏时，最多用到的资源就是纹理，一张宽高均为1024大小的格式为RGBA8888的纹理。其占用的内存量至少是4M。所以，你一定要在纹理的优化上下功夫。
纹理的优化，方案有很多。我们逐个来列举。
(1)色深优化
大家先来看一下下面这张对比图：
第一张图是A8R8G8B8格式，第二张图是我转为A1R5G5B5后的PVR图，我以一个一般玩家的视角来看是看不出有什么差别的。但是第一个图每个像素占4字节，而第二张图每个像素占2字节。这意味着看起来几乎相同的图片，占用的内存可以减少一半。
这一方案并不适用于所有情况，你需要对每种图片进行考虑，如果说你的图片的ALPHA通道不是用于镂空，而是用于渲染ALPHA混合。那你转为只占1位的ALPHA通道格式纹理是肯定不行的,你可以试试ARGB4444。而对于无ALPHA通道的图片，如果使用的是RGB888，可以尝试转为RGB565。另外，转换之后一定要由美术人员进行实际观察进行确定。如果转换后的图像有明显的失真，那就算了。
(2)拼图优化
还是先上图吧
首先是一堆小图：
这一堆小图共有20张，都是PNG格式的RGBA8888。其中有15张图大小是85x121,一张52x139,两张是52x200,还有两张是37x37。
下面是拼合后的PNG图，格式与小图一致。使用的是“红孩儿纹理打包器1.1版本”。
下载地址：http://download.****.net/detail/honghaier/4671677
此图大小为512x512，可以看到其仍然有很大一片空白可供继续拼合一些小图。
好吧，我们来对比一下它们所占的内存。
第二张图大小为512x512，所以创建RGBA8888格式纹理需要1M内存来存储像素数据。
前面那一堆小图呢？
15张图大小是85x121。我们知道OpenGL ES在生成纹理时大小会扩展成2的幂次方。那85x121图片所生成的实际纹理大小为128x128，一张128x128大小的RGBA8888格式纹理需要64K内存来存储像素数据。15x64K = 960K。
1张52x139,实际纹理大小为64x256 ，也需要64K
两张是52x200,实际纹理大小为 64x256，需要64K，两张需要128K
还有两张是37x37。实际纹理大小为64x64，两张需要32K
算一算吧，只是存储像素数据总共需要的内存大小为 1184K。还不包括产生的纹理其它信息所占用的内存量，而且我们的拼合图还有很大的空白可供更多的小图进行拼合占用。
这还会导致一个更明显的效率问题，因为在渲染中，使用散图意味着增加切换纹理的开销，如果图片很多，那么纹理的频繁切换会导致你的游戏FPS大大降低。而采用拼合图，你将只需要很少次设定使用纹理，就可以渲染出大量的图形，大大减少了切换纹理的开销。
(3)骨骼动画
也是刚知道Cocos2d-x2.0.3版本已经支持骨骼动画系统。Cocosbuilder2.1版本工具中也可以进行相应的骨骼动画编辑。这对于优化内存是一个很好的方案。
以前做人物动画我们常常使用每一帧画一幅图片的逐帧动画方式。使用骨骼动画可以大大降低图片帧的数量，它只需要很少的图量就可以达到几乎相同的动画效果。但需要做比较复杂的编辑工做，对每一个关健帧的骨骼点进行编辑。
骨骼动画的制做流程一般为:
1.通过设定基础的骨骼点并构建出骨架关系树。将人物按骨架树划分成各个身体部件。
2.按照划定的身体部件来制做人物或动物图片，当然一般是将整个人物或动物图片进行切图命名图块来取得。
3.将身体部件图块绑定到相应的骨骼上。
4.设定关键帧，编辑关键帧上所有骨骼的位置及缩放与旋转变化。
5.播放动画，使骨骼按照时间进行两个关键帧间的变化插值计算，使用插值后的结果来影响身体部件图块绘制时的顶点位置。
骨骼动画的算法关键是对于骨骼动画编辑器的掌握，希望大家多多研究使用。
可参看网友豆奶哥哥的博文：
http://www.cnblogs.com/lovegame/archive/2012/10/15/2722626.html
(4)批次处理
批次，即Batch，也是游戏引擎中一个重要的优化指标。它指的是一次渲染凋用。显而易见，渲染的次数越少则游戏的运行效率越高。
Cocos2d-x是明显懂得这个道理的，举个最明显的栗子。咱们之前讲过的“深入分析Cocos2d-x中的图字原理”中有一个类CCSpriteBatchNode，它就是为了降低渲染批次而创造的一个专门管理精灵的类。这么说吧，我们渲染一段话“你吃了么？”，这里面有五个字，所以要创建五个CCSprite来对应这五个这的图块绘制，但绘制时我们如果一个一个的绘制，那是很恐怖的一件事，你的游戏写的字如果很多，你就可以放弃干其它的事情了，因为渲染调用次数太多而导致效率低下。为了提高渲染效率，专门的类CCSpriteBatchNode就出现了！他在一次渲染中把这所有的CCSprite都绘制了出来。所以，我想说，如果你要提高你的渲染效率，好好分析分析怎么使用CCSpriteBatchNode，将你的游戏中的大量图片精灵尽可能的放在CCSpriteBatchNode中来渲染，一定可以提高FPS的。
Cocos2d-x 2.0之后在左下角加入了渲染批次统计，呵呵，好像借鉴了OGRE的统计方式，为什么要统计渲染批次呢？就是为了让我们在进行优化时有个可以观察的指标。如图所示：
(5)使用压缩纹理
IOS设备用的是PowerVR显示芯片，而PVR格式可以被该显示芯片直接读取，在之前的博文里有分析过PVR格式纹理的源码，大家可以从中了解到PVR格式所支持的多种压缩格式。我们在开发IOS游戏时，也应该尽量使用合适的压缩格式的图片。如“pvr.ccz”。
这部分有个性能小测试，有兴趣的可以参见:
http://blog.sina.com.cn/s/blog_6fbe210701015j7z.html
经过上面的一些优化策略，应该已经可以大大的降低内存使用，并提高渲染效率。如果大家还有什么更好的方案，也欢迎大家随时提出来。下课~