iOS 循环引用

介绍:

在Objective-C的开发中循环引用(retain cycle)是指两个（或多个）对象之间产生了互相强引用而导致这些对象因为引用计数(reference count)始终大于等于1而不会释放，最后导致内存泄漏(memory leak)的状况，可以用下图描述。

情况一:delegate

delegate 是iOS中开发中最常遇到的循环引用，一般在声明delegate的时候都要使用弱引用 weak

或者assign

当然怎么选择使用assign还是weak，MRC的话只能用assign，在ARC的情况下最好使用weak，因为

weak修饰的变量在释放后自动指向nil，防止野指针存在

情况二:block

在OC的开发使用块(block)编程因为简便快捷而越来越常见，而使用block时需要注意的一个重点是避免产生循环引用，原因主要在于：

block常常作为delegate的替代方案使用，声明为一个对象（举例命名为BlockObject）的属性时默认为copy策略，即BlockObject会copy并强引用传入的block

block的特性会对其内部引用的所有对象进行一次强引用

那么如果在controller中引入了BlockObject属性并强引用，而在设置其block属性时传入了controller自身，循环引用也就产生了，这种情况下Xcode编译器会提示警告，如下图。

两个对象直接的循环引用

对于block使用产生的循环引用，解决的办法通常是在block外部创建一个weak指针后再传入block内部，这样循环引用就被断开了。

__weak typeof(self) weakSelf =self;

self.blockObject = [[BlockObject alloc] init];

self.blockObject.block= ^(){      

  [weakSelflog];   

 };

Cell使用block潜在的循环引用

回到标题说的情况，使用UITableViewCell或者UICollectionViewCell的子类定制cell时，会遇到cell上有个独立的按钮事件需要回调，当使用block来实现这个回调的设计时就会发生一个容易忽略的循环引用，Xcode编译器无法发现这类隐形循环引用，没有警告提醒，如下图没有警告，但循环引用已经产生，当该控制器被pop出去时不会销毁dealloc。

分析其原因在于cell实际是tableView的子视图，每个子视图都是会被其父视图的subviews（NSArray *）属性所强引用，即tableView~>subviews~>cell，而cell因为使用block作为回调强引用了block内部的对象，形成了这样的循环引用链条，即controller~>tableView~>cell~>controller，解决的方法同样是使用弱引用传入block，如下图所示。

__weaktypeof(self) weakSelf =self;    

cell.cellBlock = ^(id cell) {    

    [weakSelf iLog];    

};

returncell;

值得注意的是，在这个例子中，即使tableView属性的声明为weak，循环引用仍然会产生，原因在于tableView还是controller的view属性的子视图，强引用链接同样存在，因此最好是在block内部切开强引用链条。

情况三:NSTimer

当你创建使用NSTimer的时候，NSTimer会默认对当前self有个强引用，所以在self使用完成打算

释放的时候，一定要先使用NSTimer的invalidate来停止,释放时间控制对self的引用

[_timer invalidate];

小结

使用block比起使用协议+代理的方式因为可以直接捕获上下文中的变量而简洁方便，但潜在的隐患不能忽视，每次使用block时除了留意编译器的警告外，也要对可能的循环引用进行一番推敲，类似于UITablerHeaderFooterView的 回调 block，以及一些控制器直接/简洁地强引用的对象所持有的 block 处理，都需要保持谨慎。

此外，对于工程内的内存泄漏，Xcode本身提供了检查工具(Leak)，也有第三方的内存泄漏检查工具值得体验。

Tip：一行代码安全调用block

一般调用block调用时都要对其是否为nil进行判断，是处于安全的考虑，如下

if(block) {

block();

}

推荐一个优雅的等效写法

!block ?: block();