前言：从上周发布教程的微博反应情况来看，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 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的大小了，也可以把地图一分为二。
就没啦?
哈哈，是滴。这次，我把文章变短一些，希望你们都看懂了。
