iOS内存管理策略和实践
转：http://www.cocoachina.com/applenews/devnews/2013/1126/7418.html
- {
- Person *aPerson = [[Person alloc] init];
- // ...
- NSString *name = aPerson.fullName;
- // ...
- [aPerson release];
- }
- - (NSString *)fullName {
- NSString *string = [[[NSString alloc] initWithFormat:@"%@ %@",
- self.firstName, self.lastName] autorelease];
- return string;
- }
- - (NSString *)fullName {
- NSString *string = [NSString stringWithFormat:@"%@ %@",
- self.firstName, self.lastName];
- return string;
- }
- NSString *fileName = <#Get a file name#>;
- NSError *error;
- NSString *string = [[NSString alloc] initWithContentsOfFile:fileName
- encoding:NSUTF8StringEncoding error:&error];
- if (string == nil) {
- // Deal with error...
- }
- // ...
- [string release];
- @interface Person : NSObject
- @property (retain) NSString *firstName;
- @property (retain) NSString *lastName;
- @property (assign, readonly) NSString *fullName;
- @end
- @implementation Person
- // ...
- - (void)dealloc
- [_firstName release];
- [_lastName release];
- [super dealloc];
- }
- @end
- MyClass *myInstance = [MyClass createInstance];
内存管理实践
尽管基本的概念在“内存管理策略”文章中简单得阐述了，但是还有一些实用的步骤让你更容易管理内存；有助于确保你的程序最大限度地减少资源需求的同时，保持可靠和强大。
使用“访问器方法”让内存管理更简单
假如，你的程序有一个对象类型的属性，你必须保证：当你使用的时候，任何的已经赋值了的对象不会被销毁。被赋新值的时候，开发者必须获得对象的所有权，并放弃正在使用对象的所有权。
有时候，这些听起来很老套和繁琐，如果开发者统一使用访问器方法，内存管理有问题的机会大大减少。如果开发者在代码中总是使用retain和release管理实例变量，几乎肯定会做错事，换句话说：访问器是必须的。
来看一个Counter对象
- @interface Counter : NSObject
- @property (nonatomic, retain) NSNumber *count;
- @end;
该属性声明了两个访问器。典型的做法，开发者告诉编译器合成(synthesize)访问器方法。了解访问器是如何实现的对开发者是有好处的。
在get访问器中，开发者只需要返回变量即可，不需要retain和release
- - (NSNumber *)count {
- return _count;
- }
在set访问器方法里，如果每一位开发者都能按照相同的规则，对新的count进行负责，开发者必须通过retain来获得对象的所有权。开发者也需要通过release来放弃旧对象的所有权。（在Objective-c中给对象发送nil消息是允许的，即是_count没有被设置，仍然是安全的。）为了防止两个对象是相同的，开发者需要先调用[newCount retain]（开发者可不希望意外的把对象给销毁）
- - (void)setCount:(NSNumber *)newCount {
- [newCount retain];// retain new object first;
- [_count release];
- // Make the new assignment.
- _count = newCount;
- }
【使用访问器方法设置属性值】
假设你想实现一个重置counter的方法。你有多个选择。
第一种方式：用alloc创建NSNumber实例，然后可以用release释放。
- - (void)reset {
- NSNumber *zero = [[NSNumber alloc] initWithInteger:0];
- [self setCount:zero];
- [zero release];
- }
第二种方法：用便捷构造方法创建NSNumber对象。因此，不用调用retain和release等。
- - (void)reset {
- NSNumber *zero = [NSNumber numberWithInteger:0];
- [self setCount:zero];
- }
注意：以上两种方法都使用访问器方法。
下面将几乎可以肯定，正常的情况下，因为它可能避开访问器方法，这样很诱人。这样做几乎肯定会导致一个错误在某些时候。（比如，当开发者忘记retain或者release，或者将来内存管理机制有变化）
- - (void)reset {
- NSNumber *zero = [[NSNumber alloc] initWithInteger:0];
- [_count release];
- _count = zero;
- }
注意：如果开发者使用key-value observing，上面这种方法也不属于KVO范畴
不要在初始化和dealloc函数中使用访问器方法
唯一不让使用访问器的地方就是initializer和dealloc。为了将counter初始化为零，开发者可以这样实现：
- - init {
- self = [super init];
- if (self) {
- _count = [[NSNumber alloc] initWithInteger:0];
- }
- return self;
- }
为了初始化为非零数据，可以这么实现initWithCount方法：
- - initWithCount:(NSNumber *)startingCount {
- self = [super init];
- if (self) {
- _count = [startingCount copy];
- }
- return self;
- }
既然Counter类有一个类属性，开发者还需要实现dealloc，dealloc通过发送release，将放弃左右对象的所有权，最终dealloc还会调用父类的dealloc函数。
- - (void)dealloc {
- [_count release];
- [super dealloc];
- }
使用弱引用（Weak References）来避免循环retain
对一个对象retain操作是强引用(strong reference)。所有强引用都被release之后对象才被销毁。如果，两个对象有彼此的强引用，就出现众所周知的问题——循环retain。（包括：直接，或通过其他对象强引用链的情况）
对象的关系如图所示，有一个潜在的循环retain。Document对象每一页都有一个Page对象。每个Page对象有一个paragraphs属性，表明该Page在那一Document中。如果Document中的Page是强引用，Page类中的paragraphs属性也是强引用，那个对象都不会被销毁。Document的引用值直到Page对象被释放才变为0，而Page对象直到Document释放才被释放。
解决循环引用的的方法是使用弱引用。弱引用是一种非占有所有权的关系，不对源对象retain，只是引用(reference)。然后，为了保持对象图的完整性，强引用还是必要的（如果只有弱引用，pages和paragraphs将没有任何的所有者，也就不能被释放）Cocoa形成了一个惯例：父对象应该强引用子对象，子变量应该弱引用父对象。所以，在图1中，Document对象强引用page对象，page对象弱引用Document对象。
Cocoa中的弱引用例子包含了(但不限于)table data sources, outline view items, notification observers, and miscellaneous targets and delegates.
开发者给弱引用对象发送消息应小心一些。如果给一个已经销毁的对象发消息，程序将crash。当对象可用的时候，开发者需具备良好的定义条件（You must have well-defined conditions for when the object is valid.）。
大多数情况：弱引用对象知道其他对象弱引用了自己，当自己被销毁的时候，有责任通知其他对象。比如，当开发者用notification center注册一个对象，notification center存储一个弱引用对象，并发送post消息给对象。当对象已经被销毁了。
开发者需从notification center中注销对象，防止notification center发送消息给不存在的对象。同样，当一个delegate对象被销毁后，开发者嘘移除delegate通过发送一个参数为nil的setDelegate消息而这些消息通常从对象的dealloc中发送。
避免销毁正在使用的对象
Cocoa's所有权策略指定接受的对象应该，保证在函数调用范围可用；还可以返回接受的对象，而不用担心被release掉。保证从程序中的gerrer方法中返回实例变量或者计算后的值是没问题的。
问题是，当需要的时候对象仍然有效。偶尔有些例外，主要是下面两种情况：
1.从基础集合类中移除对象
- heisenObject = [array objectAtIndex:n];
- [array removeObjectAtIndex:n];
- // heisenObject could now be invalid.
当对象从基本集合类移除，集合类发送一个release(而不是autorelease)消息。如果集合类是对象的唯一拥有者，被移除的对象(例子中heisenObject)就被立即销毁。
2.父对象被销毁
- id parent = <#create a parent object#>;
- // ...
- heisenObject = [parent child] ;
- [parent release]; // Or, for example: self.parent = nil;
- // heisenObject could now be invalid.
某些情况，开发者从其他对象获得一个对象，直接或见解释放父对象。release父对象导致被销毁，父对象又是子对象的唯一拥有者，子对象将同时被销毁。
防止这些情况，当开发者收到heisenObject时retain，使用完release掉，比如：
- heisenObject = [[array objectAtIndex:n] retain];
- [array removeObjectAtIndex:n];
- // Use heisenObject...
- [heisenObject release];
不要对稀缺资源进行dealloc
不要在dealloc函数中管理file descriptor、network connections、buffer和caches这些资源。通常，开发者不应设计带有dealloc这样的类。dealloc可能延迟调用，要么就成为程序的一个bug或者造成程序崩溃。
相反，如果你有一个稀缺资源的类，你应该这样设计应用程序，例如，你知道当你不再需要的资源的时候，然后可以告诉实例clean up。通常，你会再释放该实例，紧接着调用dealloc，你不会受到额外的问题。
如果您尝试在dealloc中背驮式得资源管理，可能会出现问题。
1.顺序依赖被拆散。虽然开发者可能希望得到一个特定顺序，被拆散的对象图本质上是无序的。如果对象是被autorelease的，被拆散的顺序可能还有变化，也可能导致意想不到的结果。
2.非回收式的稀缺资源。内存泄露是可以修复bug，内存泄露的伤害不是立即致命的。如果稀缺资源在不能释放的时候，被你释放了，你可能会碰到更严重的问题。如果你的应用程序使用文件描述符（file descriptor），可能导致不能写数据。
3.在错误的线程中执行cleanup逻辑。如果一个对象被开发者设置为是autorelease的，它会被任意一个“它正好存在于的”线程的自动释放池给释放掉。这是很容易的致命错误：该资源应该在一个线程中使用和释放。
（If an object is autoreleased at an unexpected time, it will be deallocated on whatever thread’s autorelease pool block it happens to be in. This can easily be fatal for resources that should only be touched from one thread）
集合拥有它所包含的对象
当你添加一个对象到集合(如，array，dictionary和set)，集合获得对象的所有权。对象被移除的时候或者集合本身release的时候，放弃对象的所有权。如果开发者想创建一个带有粒度的array，可以这么搞：
- NSMutableArray *array = <#Get a mutable array#>;
- NSUInteger i;
- // ...
- for (i = 0; i < 10; i++) {
- NSNumber *convenienceNumber = [NSNumber numberWithInteger:i];
- [array addObject:convenienceNumber];
- }
这种情况，开发者没有调用alloc，所以无需掉用release。也没有必要retain新的convenienceNumber。
- NSMutableArray *array = <#Get a mutable array#>;
- NSUInteger i;
- // ...
- for (i = 0; i < 10; i++) {
- NSNumber *allocedNumber = [[NSNumber alloc] initWithInteger:i];
- [array addObject:allocedNumber];
- [allocedNumber release];
- }
这个情况，开发者需要向allocedNumber发送一个release消息在for的作用域之内，来匹配alloc。既然array的addObject方法 retain了allocedNumber，allocedNumber就会被array管理删除。
要像理解这些，把自己当做设计集合类的开发者们。你想保证：即使不在你照看下，集合中的变量能仍然好用，所以，当对象传入的时候，你retain了一次。当对象移除集合类，你需要发送release消息。
对象所有权策略是基于引用计数实现的
对象所有权的策略是通过引用计数——通常叫做retain count实现的。每一个对象有一个retaincount变量。
1.创建对象后，它的retaincount是1
2. retain之后，retain count +1
3.release之后 retain count -1
4.autorelease之后，在自动释放池最后-1
5.对象的retain count减少到0的时候，对象被销毁。
【重要】
不要显式调用对象的retainCount，结果往往具有误导性，作为开发者可能不了解框架式如何对对象retain的。在调试内存管理中，你应该只关注确保你的代码遵循所有权规则。
原文：Practical Memory Management
关于iOS内存管理
应用程序内存管理是：“程序运行时，开辟的内存空间。使用它，释放它”的过程，写的好的程序尽可能少使用内存。在Objective-C中，内存管理被看做是：“在很多数据、代码下，分配受限内存资源所有权方法”。当你依据这个指南完成你的程序时，你将获得“通过显式管理对象的命周期，不使用的时候释放他们，来管理程序内存”的知识。
尽管，典型的内存管理是作用于单个对象，你的目标是通过管理对象图。你想确保：在内存中没有比实际需要的还多的对象。
概述
Objective-C提供两种内存管理的方法：
1.“manual-release”（MRR），需要显式管理内存通过跟踪对象的所有权。MRR基于NSObject类在运行时提供的引用计数实现的。
2.“Automatic Reference Counting”ARC，系统使用相同的引用计数基于MRR，但是在编译时，为开发者适当插入一些内存管理方法。强烈建议开发者在新项目中使用ARC。使用ARC就无需理解本文所描述的内容了。
防止内存相关问题的好的做法
两个主要的内存管理误用问题
1.释放或覆盖正在使用的数据。这将造成内存损坏，造成应用程序崩溃，或者更坏的情况是损坏用户数据。
2.没有释放数据，导致内存泄露。泄漏导致应用程序的内存使用量逐渐增加，这反过来又可能会导致系统性能较差或者应用程序被终止（crash）
引用计数内存管理的角度思考，但是，往往是适得其反，因为你往往会考虑内存管理方面的实现细则，而不是在你的实际目标。相反，你应该想到的内存管理对象所有权和对象图的角度。
1.Cocoa使用简单的命名惯例来指示，是否拥有函数返回的对象。（点击查看内存管理策略）
2.尽管内存管理基本策略很简单，有一些实际的步骤，你可以使内存管理更轻松，有助于确保你的程序仍然可靠和稳定的，而在同一时间最大限度地减少资源需求。（点击查看内存管理实践）
3.Autorelease pool 提供一种机制：让对象延迟release。这个对你想放弃所有权，但又想避免立即释放（比如函数的返回值）。有些时候，你可能会使用自己的autorelease池块。（点击查看自动释放池）。
使用分析工具来调试内存问题
在编译时候找出代码的问题。使用Xcode内嵌的Clang Static Analyzer 。
如果内存管理的问题仍然发生，还有其他的工具和技术，你可以用它来识别和诊断问题。
1.多数工具和技术都在TN2239中有描述，iOS Debugging Magic 特别是NSZombie来帮助找到过度释放对象。
2.使用Instruments来追踪引用计数事件并找到内存泄露。（ 参考 Collecting Data on Your App）
