紋理消耗了大量內存

在大部分情況下，是紋理（textures）消耗了遊戲程序大量的內存。因此，紋理是我們首要考慮優化的對象

紋理加載

cocos2d裏面紋理加載分為兩個階段：從圖片文件中創建一個Image對象;以這個創建好的Image對象來創建Texture2D對象.加載紋理的文件io操作和紋理創建都是耗時的，需要避免一幀之內加載大量圖片資源.因為不僅會導致卡頓還會導致內存過高.最好的方式是多線程加載即異步加載.

使用JPG圖片？

cocos2d使用JPG紋理的時候有一個問題,因為JPG紋理在加載的時候，會實時地轉化為PNG格式的紋理，而且JPG紋理將消耗三倍於本身內存占用大小的內存。jpg不論在加載速度和內存消耗方面都很差。所以，千萬不要大量使用JPG大圖.

重視文件圖片大小

圖片文件大小和紋理內存占用是兩碼事，圖片文件大多是壓縮過的，它們被使用的話必須先解壓縮，然後才能會GPU所處理，變成我們熟知的紋理。一個2048*2048的png圖片，采用32位顏色深度編碼，那麽它在磁盤上占用空間只有2MB。但是，如果變成紋理，它將消耗16MB的內存！

使用16-bit紋理

最快速地減少紋理內存占用的辦法就是把它們作為16位顏色深度的紋理來加載。cocos2d默認的紋理像素格式是32位顏色深度。如果把顏色深度減半，那麽內存消耗也就可以減少一半。並且這還會帶來渲染效率的提升，大約提高10%。

你可以使用Texture2D對象的類方法setDefaultAlphaPixelFormat來更改默認的紋理像素格式，代碼如下：

[Texture2D setDefaultAlphaPixelFormat:kCCTexture2DPixelFormat_RGB5A1];

這裏有個問題：首先，紋理像素格式的改變會影響後面加載的所有紋理。因此，如果你想後面加載紋理使用不同的像素格式的話，必須再調用此方法，並且重新設置一遍像素格式。

其次，如果你的CCTexture2D設置的像素格式與圖片本身的像素格式不匹配的話，就會導致顯示嚴重失真。比如顏色不對，或者透明度不對等等。

有哪些比較有用的紋理像素格式呢?

generate 32-bit textures: kCCTexture2DPixelFormat_RGBA8888 (default)
generate 16-bit textures: kCCTexture2DPixelFormat_RGBA4444
generate 16-bit textures: kCCTexture2DPixelFormat_RGB5A1
generate 16-bit textures: kCCTexture2DPixelFormat_RGB565 (no alpha)
 

RGBA8888是默認的格式。對於16位的紋理來說，使用RGB565可以獲得最佳顏色質量，因為16位全部用來顯示顏色：總共有65536總顏色值。但是，這裏有個缺點，除非圖片是矩形的，並且沒有透明像素。所以RBG565格式比較適合背景圖片和一些矩形的用戶控件。

RGB5A1格式使用一位顏色來表示alpha通道，因此圖片可以擁有透明區域。只是，1位似乎有點不夠用，它只能表示32768種可用顏色值。而且圖片要麽只能全部是透明像素，或者全部是不透明的像素。因為一位的alpha通道的緣故，所以沒有中間值。但是你可以使用fade in/out動作來改變紋理的opacity屬性。

如果你的圖片包含有半透明的區域，那麽RBGA4444格式很有用。它允許每一個像素值有127個alpha值，因此透明效率與RGBA8888格式的紋理差別不是很大。但是，由於顏色總量減少至4096，所以，RBGA4444是16位圖片格式裏面顏色質量最差的。

現在，你可以得到16位紋理的不足之處了：它由於顏色總量的減少，有一些圖片顯示起來可能會失真

使16位紋理看起來更棒

幸運的是，我們有TexturePacker.（簡稱TP）

TP有一個特性叫做“抖動”，它可以使得原本由於顏色數量減少而產生的失真問題得到改善。

特別是在擁有Retina顯示的像素密度下，你幾乎看不出16位與32位的紋理之間的顯示差別。當然，前提是你需要采用“抖動”算法。

使用NPOT紋理

NOPT是“non power of two”的縮寫，譯作“不是2的冪”。NPOT stands for “non power of two”.cocos2dx它默認是支持NPOT的。

如果紋理圖集（texture atlas）使用NPOT的紋理，它將有一個具大的優勢：它允許TP更好地壓縮紋理。因此，我們會更少地浪費紋理圖集的空白區域。而且，這樣的紋理在加載的時候，會少使用1%到49%左右的內存。而且你可以使用TP強制生成NPOT的紋理。(你只需要勾選“allow free size”即可）

默認使用PVR格式的紋理

TP讓你可以創建PVR格式的紋理。除了PVR紋理支持NPOT外，它們不僅可以不是2的冪，而且還可以不是方形的。

PVR是最靈活的紋理文件格式。除了支持標準的未壓縮的RGB圖片格式外，不支持有損壓縮的pvrtc格式。另外，未壓縮的pvr格式的紋理的內存消耗非常地低。不像png圖片那樣要消耗2倍於本身內存占用大小的內存，pvr格式只需要消耗紋理本身內存大小再加上一點點處理該圖片格式的內存大小。

pvr格式的一個缺點就是，你不能在Mac上面打開查看。但是，如果你安裝了TP的話，就可以使用TP自帶的pvr圖片瀏覽器來瀏覽pvr格式的圖片了.

使用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肯定不是大部分遊戲想要采用的紋理格式。但是，它們對於粒子效果來說，非常適用。因為那些小的粒子在不停地移動、旋轉、縮放，所以你很難看出一些視覺瑕疵。

PVRTC壓縮圖片格式

TP提供的PVR格式不僅有上面兩種，還包括TC2和TC4這兩種沒有alpha通道的格式。

這裏的alpha和16位紋理的alpha是一樣的。沒有alpha通道意味著圖片裏面沒有透明像素，但是，更多的顏色位會用來表示顏色，那麽顏色質量看起來也會更好一些。

有時候，PVRTC圖片格式指的是使用4位或者2位顏色值 ，但是，並不完全是那樣。PVRTC圖片格式可以編碼更多的顏色值。

預先加載所有的紋理

定要預先加載所有的紋理，你可以在第一個loading場景的時候就全部加載進來。

這樣做最大的好處在於，你的遊戲體驗會表現得非常平滑，而且你不需要再擔心資源的加載和卸載問題了。

這樣也使得你可以讓每一個紋理都使用合適的紋理像素格式，而且可以更方便地找出其它與紋理無關的內存問題。因為如果與紋理有關，那麽在第一次加載所有的紋理的時候，這個問題就會暴露出來的。如果所有的紋理都加載完畢，這時候再出現內存問題，那麽肯定就與紋理無關了，而是其它的問題了。

按照紋理size從大到小的順序加載紋理

由於加載紋理時額外的內存消耗問題，所以，采用按紋理size從大到小的方式來加載紋理是一個最佳實踐。

假設，你有一個占內存16MB的紋理和四個占用內存4MB的紋理。如果你首先加載4MB的紋理，這個程序將會使用16MB的內存，而當它加載第四張紋理的時候，短時間內會飆到20MB。這時，你要加載16MB的那個紋理了，內存會馬上飆到48MB（44 + 162），然後再降到32MB（4*4 + 16）。

但是，反過來，你先加載16MB的紋理，然後短時候內飆到32MB。然後又降到16MB。這時候，你再依次加載剩下的4個4MB的，這時，最多會彪到（43 + 42 + 16=36）MB。

在這兩種情況下，內存的峰值使用相差12MB，要知道，可能就是這12MB會斷送你的遊戲進程的小命哦！

避免在收到內存警告消息的時候清除緩存

紋理已經全部在Loading場景裏面加載完畢了，這時候，內存警告發生了，然後cocos2d就會把沒有使用的紋理從緩存中釋放掉。

你剛剛把所有的紋理都加載進來，還沒有進入任何一個場景中（此時所有的紋理都被當作“unused”），但是馬上被全部從texture cache中移除出去。可是，你又需要在其它場景中使用它們。在loading場景完了之後進入下一個場景的時候很卡的原因了。cocos2dx 在收到內存警告的時候會自動清理緩存.

理解在什麽時候、在哪裏去清除緩存

不要隨機清除緩存，也可以心想著釋放一些內存而去移除沒有使用的紋理。那不是好的代碼設計。有時候，它甚至會增加加載次數，並多次引發“間歇內存飆高”。分析你的程序的內存使用，看看內存裏面到底有什麽，以及什麽應該被清除，然後只清除該清除的。

你可以使用dumpCachedTextureInfo方法來觀察哪些紋理被緩存了：

[[TextureCache] dumpCachedTextureInfo];

cocos2d: "ingamescorefont.png" rc=9 name=ingamescorefont-hd.png id=13 128 x 64 @ 32 bpp => 32 KB
cocos2d: "ui.png" rc=15 name=ui-hd.png id=5 2048 x 2048 @ 16 bpp => 8192 KB
cocos2d: "ui-ingame.png" rc=36 name=ui-ingame-hd.png id=8 1024 x 1024 @ 16 bpp => 2048 KB
cocos2d: "digits.png" rc=13 name=digits-hd.png id=10 512 x 64 @ 16 bpp => 64 KB
cocos2d: "hilfe.png" rc=27 name=hilfe-hd.png id=6 1024 x 2048 @ 32 bpp => 8192 KB
cocos2d: "settings.png" rc=8 name=settings-hd.png id=9 1024 x 1024 @ 16 bpp => 2048 KB
cocos2d: "blitz_kurz.png" rc=1 name=(null) id=12 50 x 50 @ 32 bpp => 9 KB
cocos2d: "gameover.png" rc=8 name=gameover-hd.png id=7 1024 x 2048 @ 32 bpp => 8192 KB
cocos2d: "home.png" rc=32 name=home-hd.png id=4 2048 x 2048 @ 16 bpp => 8192 KB
cocos2d: "particleTexture.png" rc=2 name=(null) id=11 87 x 65 @ 32 bpp => 22 KB
cocos2d: "stern.png" rc=2 name=(null) id=2 87 x 65 @ 32 bpp => 22 KB
cocos2d: "clownmenu.png" rc=60 name=clownmenu-hd.png id=1 1024 x 2048 @ 32 bpp => 8192 KB
cocos2d: CCTextureCache dumpDebugInfo: 13 textures using 60.1 MB （紋理總共占用的內存大小！！！）

上面包含了非常多有用的信息。紋理的大小、顏色深度（bpp）和每一個被緩存的紋理在內存中所占用大小等。這裏的“rc”代表紋理的“引用計數”。如果這個引用計數等於1或2的話，那麽意味著，這個紋理當前可能不會需要使用了，此時，你可以放心地把它從紋理cache中移除出去。

你只移除你知道在當前場景下不太可能會被使用的紋理（即上面介紹的引用計數為1或2的情況），這是一個明智的做法。另外，只移除那些占用內存大的紋理。如果一個紋理只占幾個kb的內存，其它移不移除都沒什麽太大的影響。

SpriteFrames retain textures

上面提到的例子中，紋理的引用計數可能有點讓人看不懂。你會發現，紋理集有很高的retain count，即使你知道這些紋理集中的紋理當前並沒有被使用。

你可能忽略了一件事：SprteFrame會retain它的紋理。因此，如果你使用了紋理集，你要完全移除它不是那麽容易。因為，由這個紋理集產生的sprite frame還是保留在內存中。所以，你必須調用SpriteFrameCache的removeSpriteFramesFromTexture方法，能徹底清除紋理緩存中的紋理集。

[[CCSpriteFrameCache sharedSpriteFrameCache] removeSpriteFramesFromTexture:uncachedTexture];

你也可以使用 removeSpriteFramesFromFile，並指定一個紋理集的.plist文件來清除緩存起來的精靈幀（spriteframes）.

你可以清除任何緩存（比如animation,sprite frames等），但是請不要輕易清除紋理緩存

cocos2d有許多緩存類，比如紋理緩存、精靈幀緩存，動畫緩存等。

當然，如果你想從內存中移除一個紋理，你也必須移除與之相關的精靈幀(因為精靈幀會retain紋理）。

例外：檢查聲音文件的內存使用！

聲音文件會被緩存起來，然後可以重復播放而不會被中斷。由於聲音文件一般比較大，特別是，我看到有一些開發者使用沒有壓縮的聲音文件作為遊戲的背景音樂，而這些背景音樂文件非常大，它們通常會造成大量的內存消耗。

請使用MP3格式的聲音文件。因為使用沒有壓縮的聲音文件既浪費內存又占用程序大小。當你加載完一些遊戲音效時，在不需要的時候，記得要卸載掉。

如何避免緩存特定的紋理

如果你有一個紋理，你確實不想緩存起來，那怎麽辦呢？比如，在初始的加載場景中的圖片，或者那些用戶很少會在意的圖片--比如你的非常牛比的致謝場景的圖片。

經常容易被誤解的一點是，一個紋理顯示出來了，那麽它就被緩存起來了。如果你從緩存中移除此紋理，那麽此時你再移除精靈就會程序崩潰。這個理解不正確。

TextureCache只不過是對紋理再添加了一次retain函數的調用，這樣，當沒有其它對象（比如sprite）持有紋理的引用的時候，紋理仍然會存在內存之間。基於這一點，我們可以立馬從緩存中移除出去，這樣，當紋理不存需要的時候，馬上就會從內存中釋放掉。如下代碼所示：

        bg = [Sprite spriteWithFile:@"introBG.png"];
        // don‘t cache this texture:
        [[TextureCache ] removeTextureForKey:@"introBG.png"];

當TextureCache中移除一個紋理的時候，cocos2d下一次在調用spriteWithFile的時候，還是會再加載該紋理的--不管是否有沒有一張名字一樣的圖片正在被其它精靈所使用。因此，如果你不夠細心的話，你有可能最後會在內存中加載兩張重復的紋理。

使用一個Loading 場景

如果你不能預先加載所有的紋理的話，你可以使用一個loading場景，同時顯示一個動畫來表明加載的進度。這樣可以在進入下一個場景之前，讓前面一個場景銷毀，同時釋放它所占用的內存資源。

實現起來非常簡單。這個loading場景調度一個selector，然後每一幀（或者0.1秒也可以）執行一個函數，比如update。除非你前面一個場景有內存泄漏，否則的話，每一次update函數執行的時候，都會把一些引用計數為0的內存資源釋放掉。在這個update方法裏面，你可以創建新的場景。

這樣極大地避免了“間歇性內存飆高”的問題，可以極大地減小內存壓力。

在後臺加載紋理

TextureCache類還支持異步加載資源的功能，利用addImageAsync方法。你可以很方面地給addImageAsync方法添加一個回調方法，這樣，當紋理異步加載結束的時候，可以得到通知。

必須等待一個資源加載完畢。否則的話，由於“間歇性內存飆高”，可能會引發下列問題：

1) 程序崩潰
2) 紋理被加載兩次！因為異步加載並不能保證加載順序。

減少你的程序的大小

把紋理的顏色位深度減少到16位，不僅可以減少內存壓力，還可以有效地減少程序的體積。但是，我們還有其它方法可以更進一步地減少程序的大小。

TexturePacker PNG 圖片優化

如果你有某些原因，讓你堅持要使用PNG文件格式而不是我之前極力向你推薦的pvr.ccz文件格式，那麽TexturePacker有一個選項，叫做“Png Opt Level”(Png優化級別)，可以幫助我們減少png文件的大小

註意，在xcode裏面有一項設置，你可能會把它忽略掉。你需要關閉"Compress PNG files"開關，因為這個選項有可能會使你的png圖片膨脹。xcode會在png文件打包進程序的時候運行自帶的png優化程序。所以，有可能會使我們先前使用TP優化過的png圖片再次膨脹。因此，再次確保這個選項已關閉！

不過即使你沒有禁用此選項，你的程序大小還是會有所減小。因為，你有可能使用一些沒有被TP優化過的png圖片。

檢查你的程序在App Store 裏面的大小

在Xcode裏面，運行Archive build（在菜單中選擇Product->Archive）。當build成功的時候，Xcode的Organizer窗口會打開，然後你會看到一個“Estimate Size”（評估大小）的按鈕，可以用來估算你的應用程序大小：

移除未使用的資源文件

在開發遊戲的過程中，你會經常添加、移除和替換遊戲資源。所以，你可能會因為某些原因，忘記移除一些不用的圖片資源。所以，你需要額外註意把它們都從項目中移除出去，至少要從程序的target中出去。對於android 的so而言可以做一些選擇，針對多種cpu架構可以選擇一個.

減少聲音文件大小

有時候，我們也會忽視這個問題。如果你不考慮聲音文件的格式，不管是就內存的使用還是程序的大小而言，都是一種極大的浪費。下面是一些方法可以用來減少聲音文件的大小。

立體聲道變單聲道 – 你的mp3文件可以采用立體聲，但是，這樣做值得嗎？如果你聽不出來差別的話，建議還是采用單一聲道。這樣可以把文件大小和內存使用都減少一半。

MP3 比特率 –在iOS設備上面，任何比特率大於192kbps的聲音都是浪費。你可以盡量采用低的比特率來獲得最好的音質效果，這是一個折中。一般來說，96到128kbps對於mp3文件來說夠用了。

采樣率 – 大部分的聲音文件使用11，22，44，或者48kHz采樣率。采樣率越低，聲音文件越小。但是，這樣聲音質量也會越低。44kHz已經達到了CD的音質了，而48kHz會更好（這個差別只有調音師才可以聽出來）

在大部分情況下，44kHz或者更高的比特率都有點浪費。所以，可以嘗試下減小采樣率（在Audacity裏面：Tarck->Resample）。不要只是修改采樣率，因為這樣會改變聲音文件的音高。

Streaming MP3 Files

mp3文件的播放，首先是加載到內存中，然後解碼為未壓縮的聲音buffer，最後再播放。

就我目前所知，CocosDenshion的SimpleAudioEngine的playBackgoundMusic是流式播放mp3文件的。流試處理有兩個優點：1.更小的內存足跡。2.解碼mp3文件采用ios硬件，而不是cpu。但是，硬件一次只能解碼一個文件，如果同時播放多個，那麽只有一個采用的是硬件解碼，其它的都是軟件解碼。

減少Tilemap大小

許多開發者沒有註意到，tilemap大小太大會消耗大量內存。假設你有一個1000*1000的tilemap，這個大概要消耗1M的內存--如果每一個tile消耗一個字節的內存的話。然而，如果每一個tile大概消耗64個字節的話，那麽這個tilemap就會消耗60MB內存。我的天啊！

除了寫一個更優的tilemap渲染器以外，我們唯一可以做的就是減少tilemap的大小了，也可以把地圖一分為二。

cocos2dx內存優化