iOS 循环引用

2017-06-27  本文已影响179人  nero_i

介绍:

在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();

上一篇下一篇

猜你喜欢

热点阅读