iOS的内存管理机制总结
2014-11-25 11:22
387 查看
纯原理的介绍资料太多,就不去copy他们了,还是记录一些自己在学习过程中的理解和总结沉淀,短但更有力!
首先区分清楚OC代码和C代码的内存机制是不同的:
C代码内存纯手工管理,自己申请自己要负责释放,原生是不支持引用计数的,也没有啥autoreleasepool,所以规则最简单,想玩的精是最难,如果你使用到C/C++代码,注意不要被OC的内存规则给“惯性思维”了。
OC代码内存总的原则:谁申请(包括retain),谁释放,引用计数最终平衡。
OC代码又分MRC和ARC:
MRC:手动管理内存,早期代码都是这个模式,理解了这个模式有助于理解整个OC的内存机制,除了引用计数和autorelease的存在,其他机制和C/C++的基本一样。
ARC: 自动管理内存,新写的代码大多都支持ARC了,有人说有了ARC内存管理更简单了,我觉得不竟然,如果没有很好的理解原理,那么你的内存管理有可能一团糟,内存使用效率会非常差。
理解OC内存管理的关键是理解引用计数和autorelease:
引用计数:对象的内部保存一个数字,表示被引用的次数,使用alloc或者copy(或者new)方法创建一个对象时,其计数器的值为1,调用retain方法,引用次数就+1,调用releas方法就-1,当计数器到0的时候,系统会自动调用alloc方法来释放内存中的对象,需要注意的点就是:
alloc/new/copy 函数创建返回的对象,初始count都是1
retain/strong/copy 修饰的属性,赋值后指向的对象count+1
养成良好习惯,使用引用release后,要把引用置nil,防止出现野指针
autorelease:就是系统自动释放内存,可以简化内存管理代码,系统会自动释放autorelease池中的对象。但是,如果总是使用auterelease,也可能形成内存泄漏(释放延迟),问题在于autorelease池的释放时机,每当执行应用程序时,系统自动创建autorelease池,系统并不是立即释放autorelease池中的对象,而是在一个run
loop之后才释放,一般是微秒级别,本来对象可以立即释放,但是系统很有可能过一些时候才释放autoreleae池中的对象,因此我们建议尽量自己进行内存管理,而不要太依赖autorelease。使用autorelease需要注意:
除了alloc、new或copy之外的方法创建的对象都要被申明autorelease,当然你也可以手动retain来hold住这个对象,防止被马上释放掉。
autorelease的释放是延后的,如果一段同步代码中内存使用过大,需要自己创建autoreleasePool或者手动管理
针对ARC,还是有些注意点:
ARC是编译器在编译期间,将release自动添加到你的代码中的,不是运行时的机制,这点一定要注意,所以不要问系统什么时候会释放这块内存,这是由你自己代码直接决定的。
ARC对内存的管理记住两点:强引用指针置为nil或结束生命周期时会增加release,弱引用指针在内存释放时会被自动置为nil,所以不容易出现野指针。在不需要使用时尽快将指针置为nil,是内存有效使用的关键。
在使用一些老的代码中,对于弱引用的修饰符是assign而不是week,这个时候就要注意了,ARC不会在内存释放的时候自动帮你置nil。
其他的一下注意事项:
MRC下,delegate对象使用week引用(弱引用),禁止使用strong或者retain(强引用),防止循环索引用(Instrument检查不出来)。Delegate对象释放时,在dealloc函数中一定要先将delegate置nil,再release使用delegate的这个对象,ARC下如果你是用assign修饰delegate对象,也要在手动将delegate引用置nil
禁止调用NSObject的new方法,也不要在子类中重载
不要用dealloc方法管理稀缺资源,比如文件、网络链接,因为如果crash,dealloc方法不一定能被调用到
MRC和ARC在block中使用与self相关的api时是需要注意的,使用不当会出现循环引用导致对象不释放(block中引用闭包外的指针,都是强引用)
首先区分清楚OC代码和C代码的内存机制是不同的:
C代码内存纯手工管理,自己申请自己要负责释放,原生是不支持引用计数的,也没有啥autoreleasepool,所以规则最简单,想玩的精是最难,如果你使用到C/C++代码,注意不要被OC的内存规则给“惯性思维”了。
OC代码内存总的原则:谁申请(包括retain),谁释放,引用计数最终平衡。
OC代码又分MRC和ARC:
MRC:手动管理内存,早期代码都是这个模式,理解了这个模式有助于理解整个OC的内存机制,除了引用计数和autorelease的存在,其他机制和C/C++的基本一样。
ARC: 自动管理内存,新写的代码大多都支持ARC了,有人说有了ARC内存管理更简单了,我觉得不竟然,如果没有很好的理解原理,那么你的内存管理有可能一团糟,内存使用效率会非常差。
理解OC内存管理的关键是理解引用计数和autorelease:
引用计数:对象的内部保存一个数字,表示被引用的次数,使用alloc或者copy(或者new)方法创建一个对象时,其计数器的值为1,调用retain方法,引用次数就+1,调用releas方法就-1,当计数器到0的时候,系统会自动调用alloc方法来释放内存中的对象,需要注意的点就是:
alloc/new/copy 函数创建返回的对象,初始count都是1
retain/strong/copy 修饰的属性,赋值后指向的对象count+1
养成良好习惯,使用引用release后,要把引用置nil,防止出现野指针
autorelease:就是系统自动释放内存,可以简化内存管理代码,系统会自动释放autorelease池中的对象。但是,如果总是使用auterelease,也可能形成内存泄漏(释放延迟),问题在于autorelease池的释放时机,每当执行应用程序时,系统自动创建autorelease池,系统并不是立即释放autorelease池中的对象,而是在一个run
loop之后才释放,一般是微秒级别,本来对象可以立即释放,但是系统很有可能过一些时候才释放autoreleae池中的对象,因此我们建议尽量自己进行内存管理,而不要太依赖autorelease。使用autorelease需要注意:
除了alloc、new或copy之外的方法创建的对象都要被申明autorelease,当然你也可以手动retain来hold住这个对象,防止被马上释放掉。
autorelease的释放是延后的,如果一段同步代码中内存使用过大,需要自己创建autoreleasePool或者手动管理
针对ARC,还是有些注意点:
ARC是编译器在编译期间,将release自动添加到你的代码中的,不是运行时的机制,这点一定要注意,所以不要问系统什么时候会释放这块内存,这是由你自己代码直接决定的。
ARC对内存的管理记住两点:强引用指针置为nil或结束生命周期时会增加release,弱引用指针在内存释放时会被自动置为nil,所以不容易出现野指针。在不需要使用时尽快将指针置为nil,是内存有效使用的关键。
在使用一些老的代码中,对于弱引用的修饰符是assign而不是week,这个时候就要注意了,ARC不会在内存释放的时候自动帮你置nil。
其他的一下注意事项:
MRC下,delegate对象使用week引用(弱引用),禁止使用strong或者retain(强引用),防止循环索引用(Instrument检查不出来)。Delegate对象释放时,在dealloc函数中一定要先将delegate置nil,再release使用delegate的这个对象,ARC下如果你是用assign修饰delegate对象,也要在手动将delegate引用置nil
禁止调用NSObject的new方法,也不要在子类中重载
不要用dealloc方法管理稀缺资源,比如文件、网络链接,因为如果crash,dealloc方法不一定能被调用到
MRC和ARC在block中使用与self相关的api时是需要注意的,使用不当会出现循环引用导致对象不释放(block中引用闭包外的指针,都是强引用)
相关文章推荐
- iOS中引用计数内存管理机制分析总结(NSString引用计数为-1的情况)
- iOS 内存管理总结
- 简笔画项目总结: ios绘图机制 & 实现记录笔迹功能
- 黑马程序员_ios基础总结10_内存管理
- iOS开发笔记--解决UITableView中Cell重用机制导致内容出错的方法总结
- ios开发 block 在ARC机制下的内存管理
- java虚拟机内存管理机制(一):JVM内存管理总结【分享】
- 【iOS7的一些总结】5、iOS中的内存管理
- [ios]Objective-C 和 Core Foundation 对象相互转换的内存管理总结 【转】
- ios中的内存管理机制
- IOS回调机制总结
- ios 内存管理总结
- [ios]Objective-C 和 Core Foundation 对象相互转换的内存管理总结 【转】
- java虚拟机内存管理机制(一):JVM内存管理总结【分享】
- iOS中引用计数内存管理机制分析
- IOS内存管理的一点总结
- iOS开发经验总结—内存管理
- 对iOS开发中内存管理的一点总结与理解
- 0天掌握iOS开发之Day2 - 内存管理 (给学生讲解的课件,总结的不错)
- 看操作系统虚拟化原理总结篇——内存管理机制