基础部分 1: 图片内存大小小结 a: 图片:是占用内存的大户,尤其是手机游戏图片资源众多。对图片资源在内存中占用量的计算成为J2ME游戏开发者的经常性工作,CoCoMo来解释一下如何计算图片在内存中的占用量:内存占用量=宽*高*像素字节数,其中像素字节数因机型而异。 b:Xcode中使用instruments 查看图片内存的问题 如果使用的是模拟器那么默认是小屏幕的,所以最大图片是1024 *1024 * 4 = 4 M (1024 是图片的宽高, 4表示的是图片的存储类型为4字节的。也就是 RGBA8888) 如果你加载了图片那么就是使用了4M的内存。如果你需要渲染那么还需要4M的内存。 加载一般都是 **load (NSString *)filename , 渲染一般都是 Node addChild (Node)
引用计数增加的情况 : a: alloc 对象会使得对象引用数 +1 b:调用retain (具体细说一些实例如下) ->比如你是cocos2d用户的会看到 addchild 会使子节点的引用计数+1 ->CCArray 的addObject 也会使元素的引用计数+1 总结一下就是: 凡是添加到结合中的元素或者子节点不需要再去retain ,只需要在建立的时候调用release 减少的情况 : 调用release 使引用计数 -1(具体细说一些实例如下) -> 集合调用remove/removeChildByTag 等等变形的 -> 创建的时候调用autorelease 。注意:如果你的对象是局部对象,而且创建的时候使用的是autorelease, 那么在离开方法的时候如果你没有retain 那么这个对象将被dealloc(引用计数-1了) 官网的介绍: · If you are not the creator of an object, but want to ensure it stays in memory for you to use, you can express an ownership interest in it. 一,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, CCTextureCache CCSpriteFrameCache加载的是一张拼接过的大图,每一个小图只是大图中的一个区域,这些区域信息都在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 512mb iPad/iPod touch3,4/iphone3gs 40-80mb 256mb iPod touch1,2/iPhone3g/iPhone1 25mb 128mb 上述建议内存只是一些人自己测试的结果,可用的RAM不大于最大内存的一半,如果程序超过最大内存的一半,则可能会挂掉。 另外在LEAKS里查看模拟器中和真机总的内存,会有较大出入。在模拟器中的结果与实际更接近一些。 七, 泄漏的情况 我所碰到的主要内存泄露的方式: 实战演练 如何查找内存泄漏 ? 一:对工具的使用来查找 1、首先使用分析编译,Analyze build,查看归类当中的memory警告。 二 ,重载法。 如何修改内存泄漏呢 ? 1、缺啥补啥。缺release的,就补release,缺free的就加个free。
游戏中我遇到的一个非常难查的泄漏这里贡献出来 : 对于cocos2d的用户如果使用了CCMenu ,而且也重写了CCScene中的onExsit 函数来检测离开场景的时候的一些变化。但是忘了去调用super onExsit 这时候CCMenu自己注册了一个事件delegate 就无法释放导致CCMenu一直无法释放。当加载到了其他场景的时候事件总会不对。就是因为这个导致的 解决办法自然是调用super onExsit 。因为在这里他释放了delegate |
|