1. 一帧一帧载入游戏资源
2. 减少绘制调用，使用“Use CCSpriteBatchNode”
3. 载入纹理时按照从大到小的顺序
4. 避免高峰内存使用
5. 使用载入屏幕预载入游戏资源
6. 需要时释放空闲资源
7. 收到内存警告后释放缓存资源.
8. 使用纹理打包器优化纹理大小、格式、颜色深度等
9. 使用JPG格式要谨慎！
10. 请使用RGB4444颜色深度16位纹理
11. 请使用NPOT纹理，不要使用POT纹理
12. 避免载入超大纹理
13. 推荐1024*1024 NPOT pvr.ccz纹理集，而不要采用RAW PNG纹理

1.通常情况下用PVR格式的文件来进行图片显示的时候，在运行速度和内存消耗方面都要比PNG格式要快和小。一般情况下PVR消耗的内存比PNG消耗的内存小25%左右。PVR格式可以用ZWoptex导出。PVR是apple芯片能直接读取和显示的文件.

2.图片抗锯齿处理。

图片放大时的处理:

图片在放大的时候会出现锯齿。纹理类提供了setAntiAliasTexParameters()函数来处理抗锯齿。当图片放大的时候会使用相邻的四个像素进行混合运算。从而消除锯齿。但是会让图片产生模糊的感觉。

图片纹理优化资源加载方案" src="http://simg.sinajs.cn/blog7style/images/common/sg_trans.gif">

左边使用的就是setAntiAliasTexParameters（）。和右边的图片相比无锯齿，但是有模糊的感觉.右边的图片使用的是setAliasTexParameters()。不模糊，但是有锯齿。

图片缩小时的抗锯齿处理:

使用minmap，缩小时效果会更好，左边使用minmap

图片纹理优化资源加载方案" src="http://simg.sinajs.cn/blog7style/images/common/sg_trans.gif">

3.cocos2d-x的纹理类支持从多种格式的文件加载图片.包括：.png,.jpeg,.pvr,.gz,.webp,.tiff,.ccz等格式的文件 。

4.最大限度的通过一些方法和手段减小纹理对内存消耗.

(1) 通过CCTexture2D来修改纹理的像素格式，可以减少纹理占用的内存大小和渲染的速度。

使用16-bit纹理

最快速地减少纹理内存占用的办法就是把它们作为16位颜色深度的纹理来加载。cocos2d默认的纹理像素格式是32位颜色深度。如果把颜色深度减半，那么内存消耗也就可以减少一半。并且这还会带来渲染效率的提升，大约提高10%。

你可以使用CCTexture2D对象的类方法setDefaultAlphaPixelFormat来更改默认的纹理像素格式，代码如下：

这里有个问题：首先，纹理像素格式的改变会影响后面加载的所有纹理。因此，如果你想后面加载纹理使用不同的像素格式的话，必须再调用此方法，并且重新设置一遍像素格式。

其次，如果你的CCTexture2D设置的像素格式与图片本身的像素格式不匹配的话，就会导致显示严重失真。比如颜色不对，或者透明度不对等等。

有哪些比较有用的纹理像素格式呢?

RGBA8888是默认的格式。对于16位的纹理来说，使用RGB565可以获得最佳颜色质量，因为16位全部用来显示颜色：总共有65536总颜色值。但是，这里有个缺点，除非图片是矩形的，并且没有透明像素。所以RBG565格式比较适合背景图片和一些矩形的用户控件。

RBG5A1格式使用一位颜色来表示alpha通道，因此图片可以拥有透明区域。只是，1位似乎有点不够用，它只能表示32768种可用颜色值。而且图片要么只能全部是透明像素，或者全部是不透明的像素。因为一位的alpha通道的缘故，所以没有中间值。但是你可以使用fade in/out动作来改变纹理的opacity属性。

如果你的图片包含有半透明的区域，那么RBGA4444格式很有用。它允许每一个像素值有127个alpha值，因此透明效率与RGBA8888格式的纹理差别不是很大。但是，由于颜色总量减少至4096，所以，RBGA4444是16位图片格式里面颜色质量最差的。

现在，你可以得到16位纹理的不足之处了：它由于颜色总量的减少，有一些图片显示起来可能会失真，而且可能会产生“梯度”。

(2)避免一个接一个地加载PNG和JPG纹理（他们之间至少等待一帧）

cocos2d里面纹理加载分为两个阶段：1.从图片文件中创建一个UIImage对象。2.以这个创建好的UIImage对象来创建CCTexture2D对象。这意味着，当一个纹理被加载的时候，在短时候内，它会消耗两倍于它本身内存占用的内存大小。（译注：为什么只是短时间内呢?因为autoRelease pool和引用计数的关系，临时创建的UIImage对象会被回收。）

当你在一个方法体内，接二连三地加载4个纹理的时候，这个内存问题会变得更加糟糕。因为在这个方法还没结束之前，每一个纹理都会消耗两倍于它本身的内存。

我不是很确定，现在的cocos2d是否仍然如此。或者这种情况是否只适用于手工引用计数管理，或许ARC不会如此呢？我习惯于按顺序加载纹理，但是在加载下一个纹理之前要等待一帧。这将会使得任何纹理加载的消耗对内存的压力降低。因为等待一帧，引用计数会把临时的UIImage对象释放掉，减少内存压力。此外，在后续的文章中，如果你想在背景线程中按序加载纹理的话，也可以采用这种方法。

(3)iphone中不要使用jpg来创建纹理对象

cocos2d-iphone使用JPG纹理的时候有一个问题。因为JPG纹理在加载的时候，会实时地转化为PNG格式的纹理。这意味着cocos2d-iphone加载纹理是非常慢的（这里有演示），而且JPG纹理将消耗三倍于本身内存占用大小的内存。

一个2048*2048大小的纹理会消耗16M的内存。当你加载它的时候，在短时间内，它将消耗32MB内存。现在，如果这个图片是JPG格式，你会看到这个数字会达到48MB，因为额外的UIImage对象的创建。虽然，最终内存都会降到16M，但是，那一个时刻的内存飙高，足以让os杀死你的游戏进程，造成crash，影响用户体验。

JPG不论在加载速度和内存消耗方面都很差。所以，千万不要使用JPG！

(4)忽视文件图片大小

这种情况，我见到很多。它乍听起来可能觉得有点荒诞，但事实如此，因为它需要关于文件格式的知识，而这些知识并不是每一个程序员都了解的。我经常听到的论断就是“嘿！我的程序不可能有内存警告，我所有的图片资源加起来还不到30MB！”。

怎么说呢，因为图片文件大小和纹理内存占用是两码事。假设他们是帐篷。图片文件就相当于帐篷被装在行李箱。但是，如果你想要使用帐篷的话，它必须被撑起来，被“膨胀”。

图片文件和纹理的关系与此类似。图片文件大多是压缩过的，它们被使用的话必须先解压缩，然后才能会GPU所处理，变成我们熟知的纹理。一个2048*2048的png图片，采用32位颜色深度编码，那么它在磁盘上占用空间只有2MB。但是，如果变成纹理，它将消耗16MB的内存！

当然，减少纹理占用内存大小是有办法滴。

第一个办法就是：上面的条款(1)，用SetDefaultAlphaPixelFormat()来实现.尽量使用颜色深度为16bit的图片。但是条款 （１）也提到了，如果图片本身的颜色深度如果是３２位。但是用SetDefaultAlphaPixelFormat()设置成16位。则可能让图片失真.图片看起来就很模糊，这当然是有解决的办法，庆幸我们有TexturePacker（TP）工具.

TP有一个特性叫做“抖动”，它可以使得原本由于颜色数量减少而产生的失真问题得到改善。（TP里面有很多抖动算法，关于这些算法，读者可以参考我翻译的另一篇文章）。

特别是在拥有Retina显示的像素密度下，你几乎看不出16位与32位的纹理之间的显示差别。当然，前提是你需要采用“抖动”算法。

第二个办法是:使用NPOT纹理

NOPT是“non power of two”的缩写，译作“不是2的幂”。NPOT stands for “non power of two”. 在cocos2d1.x的时候，你必须在ccConfig.h文件中开启对NPOT的支持，但是，cocos2d 2.x就不需要了，它默认是支持NPOT的。所有3代（iphone 3GS）以后的ios设置都支持cocos2d 2.x（因为它们支持OpenGL ES2.0），所以也都能支持NPOT纹理。

如果纹理图集（texture atlas）使用NPOT的纹理，它将有一个具大的优势：它允许TP更好地压缩纹理。因此，我们会更少地浪费纹理图集的空白区域。而且，这样的纹理在加载的时候，会少使用1%到49%左右的内存。而且你可以使用TP强制生成NPOT的纹理。(你只需要勾选“allow free size”即可）

为什么要关心NPOT呢？因为苹果的OpenGL驱动有一个bug，导致如果使用POT的纹理，则会产生额外33%的内存消耗。

第三个办法是:默认使用PVR格式的纹理

TP让你可以创建PVR格式的纹理。除了PVR纹理支持NPOT外，它们不仅可以不是2的幂，而且还可以不是方形的。

PVR是最灵活的纹理文件格式。除了支持标准的未压缩的RGB图片格式外，不支持有损压缩的pvrtc格式。另外，未压缩的pvr格式的纹理的内存消耗非常地低。不像png图片那样要消耗2倍于本身内存占用大小的内存，pvr格式只需要消耗纹理本身内存大小再加上一点点处理该图片格式的内存大小。

pvr格式的一个缺点就是，你不能在Mac上面打开查看。但是，如果你安装了TP的话，就可以使用TP自带的pvr图片浏览器来浏览pvr格式的图片了。（强烈建议大家购买TP，支持TP，不要再盗版了）

使用PVR格式的文件几乎没有缺点。此外，它还可以极大地提高加载速度，后面我会解释到。

使用pvr.ccz文件格式

在三种可选用的pvr文件格式中，优先选择pvr.ccz格式。它是专门为cocos2d和TP设计的。在TP里面，这是它生成的最小的pvr文件。而且pvr.ccz格式比其它任何文件格式的加载速度都要快。

当在cocos2d里面使用pvr格式的纹理时，只使用pvr.ccz格式，不要使用其它格式！因为它加载速度超快，而且加载的时候使用更少的内存！

当视觉察觉不出来的时候，可以考虑使用PVRTC压缩

PVR纹理支持PVRTC纹理压缩格式。它主要是采用的有损压缩。如果拿PVRTC图片与JPG图片作对比的话，它只有JPG图片中等质量，但是，最大的好处是可以不用在内存里面解压缩纹理。

这里把32位的png图片（左边）与最佳质量的PVRTC4（4位）图片（点击图片查看完整的大小）作对比：

注意，在一些高对比度的地方，明显有一些瑕疵。有颜色梯度的地方看起来还好一点。

PVRTC肯定不是大部分游戏想要采用的纹理格式。但是，它们对于粒子效果来说，非常适用。因为那些小的粒子在不停地移动、旋转、缩放，所以你很难看出一些视觉瑕疵。

预先加载所有的纹理

就像标题所说，尽你所能，一定要预先加载所有的纹理。如果你的所有的纹理加起来不超过80MB内存消耗的话（指的是拥有Retina显示的设备，非Retina的减半考虑），你可以在第一个loading场景的时候就全部加载进来。

这样做最大的好处在于，你的游戏体验会表现得非常平滑，而且你不需要再担心资源的加载和卸载问题了。

这样也使得你可以让每一个纹理都使用合适的纹理像素格式，而且可以更方便地找出其它与纹理无关的内存问题。因为如果与纹理有关，那么在第一次加载所有的纹理的时候，这个问题就会暴露出来的。如果所有的纹理都加载完毕，这时候再出现内存问题，那么肯定就与纹理无关了，而是其它的问题了。

如果你知道问题与纹理无关的话，那么你查找剩下的内存问题将会变得更加简单。而且你避免了前面说的这种情况：当2048*2048的纹理加载的时候，它本来只需要消耗16MB内存，但是短时间会冲到32MB内存。后面会提出一种方法来解决“间歇性内存飙高”（“译者发明滴”）的方法。（译者：希望下次开发者的对话中“间歇性内存飙高”的说法会出现，呵呵）

按照纹理size从大到小的顺序加载纹理

由于加载纹理时额外的内存消耗问题，所以，采用按纹理size从大到小的方式来加载纹理是一个最佳实践。

假设，你有一个占内存16MB的纹理和四个占用内存4MB的纹理。如果你首先加载4MB的纹理，这个程序将会使用16MB的内存，而当它加载第四张纹理的时候，短时间内会飙到20MB。这时，你要加载16MB的那个纹理了，内存会马上飙到48MB（4*4 + 16*2），然后再降到32MB（4*4 + 16）。

但是，反过来，你先加载16MB的纹理，然后短时候内飙到32MB。然后又降到16MB。这时候，你再依次加载剩下的4个4MB的，这时，最多会彪到（4*3 + 4*2 + 16=36）MB。

在这两种情况下，内存的峰值使用相差12MB，要知道，可能就是这12MB会断送你的游戏进程的小命哦！

避免在收到内存警告消息的时候清除缓存

我有时候看到了一种奇怪的“自己开枪打自己的脚”的行为：纹理已经全部在Loading场景里面加载完毕了，这时候，内存警告发生了，然后cocos2d就会把没有使用的纹理从缓存中释放掉。

听起来不错，没有使用到的纹理都被释放掉了，但是！。。。

你刚刚把所有的纹理都加载进来，还没有进入任何一个场景中（此时所有的纹理都被当作“unused”），但是马上被全部从texture cache中移除出去。可是，你又需要在其它场景中使用它们。怎么办？你需要接着判断，如果有纹理没有加载，就继续加载。但是，一加载，由于“间歇性内存飙高”，又马上收到了内存警告，再释放，再判断，再加载。。。。 我的天，这是一个死循环啊！这也能解释为什么有些童鞋，在loading场景完了之后进入下一个场景 的时候很卡的原因了。

现在，当我收到内存警告的时候，我的做法是----什么也不做。内存警告仍然在发生，但是，它只是在程序刚开始加载的时候。我知道这是为什么，因为“间歇性内存飙高”嘛，所以，我不去管它。（但是，如果是游戏过程中再收到内存警告，你就要注意了，因为这时候可能你有内存泄漏了！！！）

我有时候会想办法改善一下，通过移除掉一些不使用的纹理和一些只有在很特殊的场景才会使用的图片（比如settings界面，玩家是不经常访问的）。然后，不管什么时候，当我需要某张图片的时候，我会首先检查一下该sprite frame是否在cache中，如果没有就加载。你会在后面看到具体的做法。

理解在什么时候、在哪里去清除缓存

不要随机清除缓存，也可以心想着释放一些内存而去移除没有使用的纹理。那不是好的代码设计。有时候，它甚至会增加加载次数，并多次引发“间歇内存飙高”。分析你的程序的内存使用，看看内存里面到底有什么，以及什么应该被清除，然后只清除该清除的。

你可以使用dumpCachedTextureInfo方法来观察哪些纹理被缓存了

这个方法的输出如下：（为了清楚起见，我把那些与-hd后缀有关的信息屏蔽掉了）

上面包含了非常多有用的信息。纹理的大小、颜色深度（bpp）和每一个被缓存的纹理在内存中所占用大小等。这里的“rc”代表纹理的“引用计数”。如果这个引用计数等于1或2的话，那么意味着，这个纹理当前可能不会需要使用了，此时，你可以放心地把它从纹理cache中移除出去。

你只移除你知道在当前场景下不太可能会被使用的纹理（即上面介绍的引用计数为1或2的情况），这是一个明智的做法。另外，只移除那些占用内存大的纹理。如果一个纹理只占几个kb的内存，其它移不移除都没什么太大的影响。（译注：这就和程序优化一样，不要做过多的细节优化，不要过早优化，要找到性能的瓶颈，然后再重点优化，以20%的时间换取80%的效率。过早和过多细节优化对于大多数程序而言，是需要极力避免的）。

SpriteFrames retain textures!

上面提到的例子中，纹理的引用计数可能有点让人看不懂。你会发现，纹理集有很高的retain count，即使你知道这些纹理集中的纹理当前并没有被使用。

你可能忽略了一件事：CCSprteFrame会retain它的纹理。因此，如果你使用了纹理集，你要完全移除它不是那么容易。因为，由这个纹理集产生的sprite frame还是保留在内存中。所以，你必须调用CCSpriteFrameCache的removeSpriteFramesFromTexture方法，能彻底清除纹理缓存中的纹理集。（译注：记住，不是你调用对象的release方法了，对象的内存就会被释放掉，而是引用计数为0了，内存才会被删除）

[[CCSpriteFrameCache sharedSpriteFrameCache] removeSpriteFramesFromTexture:uncachedTexture];

你也可以使用removeSpriteFramesFromFile，并指定一个纹理集的.plist文件来清除缓存起来的精灵帧（spriteframes）.

添加 SpriteFrames 非常耗时,每次都是!

Note:这一点只针对cocos2d v1.0有效，而cocos2d v2.x在加载之前会预先判断。

这样看起来有点无知（innocent）:

[[CCSpriteFrameCache sharedSpriteFrameCache] addSpriteFramesWithFile:@"ui.plist"];

        bg = [CCSprite spriteWithFile:@"introBG.png"];

        // don't cache this texture:
        [[CCTextureCache sharedTextureCache] removeTextureForKey:@"introBG.png"];

        NSArray* highscores = [Achievements sharedAchievements].highscores;
        for (HighscoreData* data in highscores)
        {
            NSString* entry = [NSString stringWithFormat:@"u",data.score];

            CCLabelAtlas* label = [CCLabelAtlas labelWithString:entry 
                                charMapFile:@"pipizahlen.png" 
                                  itemWidth:18
                                 itemHeight:27 
                                   startCharMap:'.'];
            [labelsNode addChild:label z:10];
        }
        
        // don't hold on to this texture:
        [[CCTextureCache sharedTextureCache] removeTextureForKey:@"pipizahlen.png"];

[self performSelectorInBackground:@selector(loadSpriteFrames:) withObject:nil];

-(void) loadSpriteFrames:(id)object
{
    [[CCSpriteFrameCache sharedSpriteFrameCache] addSpriteFramesWithFile:@"hilfe.plist"];
    [[CCSpriteFrameCache sharedSpriteFrameCache] addSpriteFramesWithFile:@"home.plist"];
    [[CCSpriteFrameCache sharedSpriteFrameCache] addSpriteFramesWithFile:@"ui.plist"];
    [[CCSpriteFrameCache sharedSpriteFrameCache] addSpriteFramesWithFile:@"gameover.plist"];
    [[CCSpriteFrameCache sharedSpriteFrameCache] addSpriteFramesWithFile:@"ui-ingame.plist"];
    [[CCSpriteFrameCache sharedSpriteFrameCache] addSpriteFramesWithFile:@"settings.plist"];
    [[CCSpriteFrameCache sharedSpriteFrameCache] addSpriteFramesWithFile:@"digits.plist"];
}

-(void) increaseAssetLoadCount
{
    assetLoadCount++;
    loadingAsset = NO;
}

-(void) loadAssetsThenGotoMainMenu:(ccTime)delta
{
    NSLog(@"load assets %i",assetLoadCount);
    switch (assetLoadCount)
    {
        case 0:
            if (loadingAsset == NO)
            {
                loadingAsset = YES;
                NSLog(@"============= Loading home.png ===============");
                [CCTexture2D setDefaultAlphaPixelFormat:kCCTexture2DPixelFormat_RGB5A1];
                [[CCTextureCache sharedTextureCache] addImageAsync:@"home.png" 
                                                                          target:self 
                                                                        selector:@selector(increaseAssetLoadCount)];
            }
            break;
        case 1:
            if (loadingAsset == NO)
            {
                loadingAsset = YES;
                [self performSelectorInBackground:@selector(loadSpriteFrames:) withObject:nil];
            }
            break;

        // extend with more sequentially numbered cases,as needed

        // the default case runs last,loads the next scene            
        default:
            {
                [self unscheduleAllSelectors];
                MainMenuScene* mainMenuScene = [MainMenuScene node];
                [[CCDirector sharedDirector] replaceScene:mainMenuScene];
            }
            break;
    }
}