iPhone开发内存管理

核心提示：永远不要直接调用dealloc来释放对象，完全依赖引用计数来完成对象的释放，iPhone开发内存管理(2)，有很多类都提供“便利构造函数(convenience constructors)”，它们创建对象但并不增加引用计数，所以要特别小心，一些和内存管理相关的有用内容：Objective-C2.0 号称可以支持Garb

永远不要直接调用dealloc来释放对象，完全依赖引用计数来完成对象的释放。

有很多类都提供“便利构造函数(convenience constructors)”，它们创建对象但并不增加引用计数，意味着不需要调用release来释放所有权。很好辨认，它们的名字中不会有alloc和copy。

只要遵守这些规则，基本上可以消除所有Intrument可以发现的内存泄露问题。

容器

类似NSArray, NSDictionary, NSSet 等类，会在对象加入后引用计数加一获得所有权，在对象被移除或者整个容器对象被释放的时候释放容器内对象的所有权。类似的情况还有UIView对 subview的所有权关系，UINavigationController对其栈上的controller的所有权关系等等。

其他所有权的产生

还有一些用法会让系统拥有对象的所有权。比如NSObject 的performSelector:withObject:afterDelay 。如果有必要，需要显示的调用cancelPreviousPerformRequestsWithTarget:selector:object: ，否则有可能产生内存泄露。

因这种原因产生的泄露因为并不违反任何规则，是Intrument所无法发现的。

循环引用

所有的引用计数系统，都存在循环应用的问题。例如下面的引用关系：

对象a创建并引用到了对象b.

对象b创建并引用到了对象c.

对象c创建并引用到了对象b.

这时候b和c的引用计数分别是2和1。当a不再使用b，调用release释放对b的所有权，因为c还引用了b，所以b的引用计数为1，b不会被释放。b不释放，c的引用计数就是1，c也不会被释放。从此，b和c永远留在内存中。

这种情况，必须打断循环引用，通过其他规则来维护引用关系。比如，我们常见的delegate往往是assign方式的属性而不是retain方式的属性，赋值不会增加引用计数，就是为了防止delegation两端产生不必要的循环引用。如果一个UITableViewController 对象a通过retain获取了UITableView对象b的所有权，这个UITableView对象b的delegate又是a， 如果这个delegate是retain方式的，那基本上就没有机会释放这两个对象了。自己在设计使用delegate模式时，也要注意这点。

因为循环引用而产生的内存泄露也是Instrument无法发现的，所以要特别小心。

一些和内存管理相关的有用内容：

Objective-C2.0 号称可以支持Garbage Collection了， 也就是垃圾回收，