IOS 内存优化和调试技巧基于cocos2d游戏

基础部分

1：图片内存大小小结

a:图片：是占用内存的大户，尤其是手机游戏图片资源众多。对图片资源在内存中占用量的计算成为J2ME游戏开发者的经常性工作，CoCoMo来解释一下如何计算图片在内存中的占用量：内存占用量=宽*高*像素字节数，其中像素字节数因机型而异。
例如一张64*64的图片在7210上的内存占用量=64*64*1.5=6144(字节)=6K、在S60上的内存占用量=64*64*2=8192(字节)=8K。像素字节数因机型而异，例如

7210是4096色机型，也就是说用12位来表示一个像素，所以乘上1.5，而S60是65536色的机型，用16位来表示一个像素，所以乘上2。

b:Xcode中使用instruments查看图片内存的问题如果使用的是模拟器那么默认是小屏幕的，所以最大图片是1024＊1024＊4＝4M

（1024是图片的宽高，4表示的是图片的存储类型为4字节的。也就是RGBA8888）如果你加载了图片那么就是使用了4M的内存。如果你需要渲染那么还需要4M的内存。加载一般都是**load（NSString＊）filename，渲染一般都是NodeaddChild(Node)
2:

引用计数问题

引用计数增加的情况：a:alloc对象会使得对象引用数＋1

b：调用retain（具体细说一些实例如下）

－>比如你是cocos2d用户的会看到addchild会使子节点的引用计数＋1

－>CCArray的addObject也会使元素的引用计数＋1

总结一下就是：凡是添加到结合中的元素或者子节点不需要再去retain，只需要在建立的时候调用release

减少的情况

：调用release使引用计数-1（具体细说一些实例如下）

－>集合调用remove／removeChildByTag等等变形的

－>创建的时候调用autorelease。注意：如果你的对象是局部对象，而且创建的时候使用的是autorelease，

那么在离开方法的时候如果你没有retain那么这个对象将被dealloc（引用计数－1了）

官网的介绍：

•
Youownanyobjectyoucreatebyallocatingmemoryforitorcopyingit.
Relatedmethods:alloc,allocWithZone:,copy,copyWithZone:,mutableCopy,mutableCopyWithZone:Ifyouarenotthecreatorofanobject,butwanttoensureitstaysinmemoryforyoutouse,youcanexpressanownershipinterestinit.
Relatedmethod:retain
Ifyouownanobject,eitherbycreatingitorexpressinganownershipinterest,youareresponsibleforreleasingitwhenyounolongerneedit.
Relatedmethods:release,autorelease
Conversely,ifyouarenotthecreatorofanobjectandhavenotexpressedanownershipinterest,youmustnotreleaseit.
3：参考文档一，IOS与图片内存在IOS上，图片会被自动缩放到2的N次方大小。比如一张1024*1025的图片，占用的内存与一张1024*2048的图片是一致的。图片占用内存大小的计算的公式是；长*宽*4。这样一张512*512占用的内存就是512*512*4=1M。其他尺寸以此类推。（ps:IOS上支持的最大尺寸为2048*2048）。二，cocos2d-x的图片缓存Cocos2d-x在构造一个精灵的时候会使用spriteWithFile或者spriteWithSpriteFrameName等无论用哪种方式，cocos2d-x都会将这张图片加载到缓存中。如果是第一次加载这个图片，那就会先将这张图片加载到缓存，然后从缓存读取。如果缓存中已经存在，则直接从缓存中提取，免除了加载过程。图片的缓存主要由以下两个类来处理：CCSpriteFrameCache，CCTextureCacheCCSpriteFrameCache加载的是一张拼接过的大图，每一个小图只是大图中的一个区域，这些区域信息都在plist文件中保存。用的时候只需要根据小图的名称就可以加载到这个区域。CCTextureCache是普通的图片缓存，我们所有直接加载的图片都会默认放到这个缓存中，以提高调用效率。因此，每次加载一张图片，或者通过plist加载一张拼接图时，都会将整张图片加载到内存中。如果不去释放，那就会一直占用着。三，渲染内存。不要以为，计算内存时，只计算加载到缓存中的内存就可以了。以一张1024*1024的图片为例。CCSprite*pSprite=CCSprite::spriteWithFile("a.png");调用上边这行代码以后，可以在LEAKS工具中看到，增加了大约4M的内存。然后接着调用addChild(pSprite);这时，内存又增加了4M。也就是，一张图片，如果需要渲染的话，那它所占用的内存将要X2。再看看通过plist加载的图片，比如这张大图尺寸为2048*2048。想要加载其中的一张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次方并且装的很满。但要注意，有逻辑关系的图片尽量打包在一张大图里，另外一点就是打包的时候要考虑到层的分布。因为为了渲染效率可能会用到CCSpriteBatchNode;同一个BatchNode里的图片都是位于一个层级的，因此必须根据各个图片的层级关系，打包到不同的plist里。有时内存和效率不可以兼得，只能尽量平衡了。六，其他最后附一个各代IOS设备的内存限制情况设备

建议内存

最大内存iPad2/iPhone4s/iphone4

170-180mb

512mbiPad/iPodtouch3,4/iphone3gs

40-80mb

256mbiPodtouch1,2/iPhone3g/iPhone1

25mb

128mb上述建议内存只是一些人自己测试的结果，可用的RAM不大于最大内存的一半，如果程序超过最大内存的一半，则可能会挂掉。另外在LEAKS里查看模拟器中和真机总的内存，会有较大出入。在模拟器中的结果与实际更接近一些。七，泄漏的情况我所碰到的主要内存泄露的方式：
1、最常见的就是，申请了引用，然后最后忘记释放。具体么就是，使用OC的alloc,retain,copy,new，C的malloc,realloc，C++的new等，然后没有对应的release,free,delete。这是单向泄露。
2、retaincycle，对于OC这种使用计数的方式，可能会存在retaincycle。两个条件，一、就是A中retain了B，B又retain了A，各自给对方计数增加，这个环可以变为很多层，就是A->B,B->C,C->D,....

Z->A，当然假如中间层越多，检测难度就越大。二、计数减少的操作是在dealloc中，而dealloc被调用则需要计数为0。这两个条件相加，导致计数锁定，内存泄露。实战演练如何查找内存泄漏？一：对工具的使用来查找1、首先使用分析编译，Analyzebuild，查看归类当中的memory警告。
这个一般能发现局部变量中忘记release，或者被中途打断release的。
2、然后就是直接使用Instruments中的leak监测。
申请了内存，然后已经没有指向这块内存的指针存在，可以认为是leak了。这个检测一般是检测这个状态。
3、通过Instruments中allocation的markheap。
进行不断的重复操作，在每次场景结束后，标记内存。假如操作场景没有泄露，内存增加应该是0。这个检测是检测标记点之间有哪些对象增加。另外，需要多mark几次才会准确，不要mark两次看到有内存增加就去找问题。
Instruments中都是可以看到其中存在什么对象，调用历史，调用堆栈。这时候大致确定在那个类当中的那个对象泄露了。二，重载法。
虽然知道了哪个类泄露了，但是有时候并不知道具体是那边的计数出现问题。我自己的方法是，假如是自己编写的类，那就重载retain和release方法，然后加断点。以此来监测是什么地方retain了这个对象，却没有对应释放。

如何修改内存泄漏呢？1、缺啥补啥。缺release的，就补release，缺free的就加个free。
2、合理使用autorelease。对于返回给上层使用的；或者alloc对象到release中间有return等打断操作的。建议使用autorelease。
3、合理使用assign。retaincycle，本质就是多余的双向retain。打个比方就是应该确定哪个对象是根，哪一个是枝叶，枝叶不用去管理根，只需要知道根在那边就可以了。所以把那些纯粹是定位用