优化和调试IOS内存技巧Word文档格式.docx
- 文档编号:846914
- 上传时间:2023-04-29
- 格式:DOCX
- 页数:13
- 大小:24.84KB
优化和调试IOS内存技巧Word文档格式.docx
《优化和调试IOS内存技巧Word文档格式.docx》由会员分享,可在线阅读,更多相关《优化和调试IOS内存技巧Word文档格式.docx(13页珍藏版)》请在冰点文库上搜索。
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.
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,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();
释放到目前为止所有加载的图片
removeUnusedTextures();
将引用计数为1的图片释放掉CCTextureCache:
removeTexture();
单独释放某个图片
CCSpriteFrameCache与CCTextureCache释放的方法差不多。
值得注意的是释放的时机,一般在切换场景的时候释放资源,如果从A场景切换到B场景,调用的函数顺序为B:
init()---->
A:
exit()---->
B:
onEnter()可如果使用了切换效果,比如CTransitionJumpZoom:
transitionWithDuration这样的函数,则函数的调用顺序变为B:
onEnter()---->
exit()而且第二种方式会有一瞬间将两个场景的资源叠加在一起,如果不采取过度,很可能会因为内存吃紧而崩溃。
有时强制释放全部资源时,会使某个正在执行的动画失去引用而弹出异常,可以调用CCActionManager:
sharedManager()->
removeAllActions();
来解决。
五,内存优化
优化的心得就是尽量去拼接图片,使图片边长尽可能的保持2的N次方并且装的很满。
但要注意,有逻辑关系的图片尽量打包在一张大图里,另外一点就是打包的时候要考虑到层的分布。
因为为了渲染效率可能会用到CCSpriteBatchNode;
同一个BatchNode里的图片都是位于一个层级的,因此必须根据各个图片的层级关系,打包到不同的plist里。
有时内存和效率不可以兼得,只能尽量平衡了。
六,其他
最后附一个各代IOS设备的内存限制情况
设备建议内存最大内存
iPad2/iPhone4s/iphone4170-180mb512mb
iPad/iPodtouch3,4/iphone3gs40-80mb256mb
iPodtouch1,2/iPhone3g/iPhone125mb128mb
上述建议内存只是一些人自己测试的结果,可用的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。
打个比方就是应该确定哪个对象是根,哪一个是枝叶,枝叶不用去管理根,只需要知道根在那边就可以了。
所以把那些纯粹是定位用的变量,属性都改成assign方式,例如delegate。
PS:
假如对于Instruments的使用不是很清楚,可以看这个视频
游戏中我遇到的一个非常难查的泄漏这里贡献出来:
对于cocos2d的用户如果使用了CCMenu,而且也重写了CCScene中的onExsit函数来检测离开场景的时候的一些变化。
但是忘了去调用superonExsit
这时候CCMenu自己注册了一个事件delegate就无法释放导致CCMenu一直无法释放。
当加载到了其他场景的时候事件总会不对。
就是因为这个导致的
解决办法自然是调用s基础部分
进行不断的重复
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 优化 调试 IOS 内存 技巧