iOS容易造成循环引用的三种场景

 iOS容易造成循环引用的三种场景
  ARC已经出来很久了,自动释放内存的确很方便,但是并非绝对安全绝对不会产生内存泄露。导致iOS对象无法按预期释放的一个无形杀手是——循环引用。循环引用可以简单理解为A引用了B,而B又引用了A,双方都同时保持对方的一个引用,导致任何时候引用计数都不为0,始终无法释放。若当前对象是一个ViewController,则在dismiss或者pop之后其dealloc无法被调用,在频繁的push或者present之后内存暴增,然后APP就duang地挂了。下面列举我们变成中比较容易碰到的三种循环引用的情形。

(1)计时器NSTimer

一方面,NSTimer经常会被作为某个类的成员变量,而NSTimer初始化时要指定self为target,容易造成循环引用。 另一方面,若timer一直处于validate的状态,则其引用计数将始终大于0。先看一段NSTimer使用的例子(ARC模式):

#import <Foundation/Foundation.h>

 @interface Friend : NSObject

 - (void)cleanTimer;

 @end

 #import "Friend.h"

 @interface Friend ()

 {

         NSTimer *_timer;

     }

 @end


 @implementation Friend

 - (id)init

 {

         if (self = [super init]) {

                 _timer = [NSTimer scheduledTimerWithTimeInterval:1target:self selector:@selector(handleTimer:)

                                                                              userInfo:nil repeats:YES];

             }

         return  self;

     }


 - (void)handleTimer:(id)sender

 {

         NSLog(@"%@ say: Hi!", [self class]);

     }

 - (void)cleanTimer

 {

         [_timer invalidate];

         _timer = nil;

     }

 - (void)dealloc

 {

         [self cleanTimer];

         NSLog(@"[Friend class] is dealloced");

     }

在类外部初始化一个Friend对象,并延迟5秒后将friend释放(外部运行在非arc环境下)


         Friend *f = [[Friend alloc] init];

         dispatch_after(dispatch_time(DISPATCH_TIME_NOW5*NSEC_PER_SEC), dispatch_get_main_queue(), ^{

                 [f release];

             });

我们所期待的结果是,初始化5秒后,f对象被releasefdealloc方法被调用,在dealloc里面timer失效,对象被析构。但结果却是如此:
 


2015-03-18 18:00:35.300 WZLCodeLibrary[41422:3390529] Friend say: Hi!
2015-03-18 18:00:36.299 WZLCodeLibrary[41422:3390529] Friend say: Hi!
2015-03-18 18:00:37.300 WZLCodeLibrary[41422:3390529] Friend say: Hi!
2015-03-18 18:00:38.299 WZLCodeLibrary[41422:3390529] Friend say: Hi!
2015-03-18 18:00:39.299 WZLCodeLibrary[41422:3390529] Friend say: Hi! //运行了5次后没按照预想的停下来
2015-03-18 18:00:40.299 WZLCodeLibrary[41422:3390529] Friend say: Hi!
2015-03-18 18:00:41.300 WZLCodeLibrary[41422:3390529] Friend say: Hi!
2015-03-18 18:00:42.300 WZLCodeLibrary[41422:3390529] Friend say: Hi!
2015-03-18 18:00:43.299 WZLCodeLibrary[41422:3390529] Friend say: Hi!
2015-03-18 18:00:44.300 WZLCodeLibrary[41422:3390529] Friend say: Hi!<br>.......根本停不下来.....


 
这是为什么呢?主要是因为从 timer 的角度, timer 认为调用方 (Friend 对象 ) 被析构时会进入 dealloc ,在 dealloc 可以顺便将 timer 的计时停掉并且释放内存;但是从 Friend 的角度,他认为 timer 不停止计时不析构,那我永远没机会进入 dealloc 。循环引用,互相等待,子子孙孙无穷尽也。问题的症结在于 -( void )cleanTimer 函数的调用时机不对,显然不能想当然地放在调用者的 dealloc 中。一个比较好的解决方法是开放这个函数,让 Friend 的调用者显式地调用来清理现场。如下:


Friend *f = [[Friend alloc] init];

dispatch_after(dispatch_time(DISPATCH_TIME_NOW5*NSEC_PER_SEC), dispatch_get_main_queue(), ^{

    [f cleanTimer];

    [f release];

});


2block


blockcopy时都会对block内部用到的对象进行强引用(ARC)或者retainCount1(ARC)。在ARC与非ARC环境下对block使用不当都会引起循环引用问题,一般表现为,某个类将block作为自己的属性变量,然后该类在block的方法体里面又使用了该类本身,简单说就是self.someBlock = ^(Type var){[self dosomething];或者self.otherVar = XXX;或者_otherVar = ...};block的这种循环引用会被编译器捕捉到并及时提醒。举例如下,依旧以Friend类为例子:


#import "Friend.h"


@interface Friend ()

@property (nonatomic) NSArray *arr;

@end


@implementation Friend

- (id)init

{

    if (self = [super init]) {

        self.arr = @[@111@222@333];

        self.block = ^(NSString *name){

            NSLog(@"arr:%@"self.arr);

        };

    }

    return  self;

}

我们看到,在block的实现内部又使用了Friend类的arr属性,xcode给出了warning 运行程序之后也证明了Friend对象无法被析构:

self.arr = @[@111,@222,@333];

self.block = ^(NSString *name){

    NSLog(@"arr:%@",self.arr);

}

网上大部分帖子都表述为"block里面引用了self导致循环引用",但事实真的是如此吗?我表示怀疑,其实这种说法是不严谨的,不一定要显式地出现"self"字眼才会引起循环引用。我们改一下代码,不通过属性self.arr去访问arr变量,而是通过实例变量_arr去访问,如下:
 

_arr = @[@111,@222,@333];

self.block = ^(NSString *name){

    NSLog(@"arr:%@",_arr);

}


由此我们知道了,即使在你的block代码中没有显式地出现"self",也会出现循环引用!只要你在block里用到了self所拥有的东西!但对于这种情况,目前我不知道该如何排除掉循环引用,因为我们无法通过加__weak声明或者__block声明去禁止blockself进行强引用或者强制增加引用计数。对于self.arr的情况,我们要分两种环境去解决:


1)ARC环境下:ARC环境下可以通过使用_weak声明一个代替self的新变量代替原先的self,我们可以命名为weakSelf。通过这种方式告诉block,不要在block内部对self进行强制strong引用:(如果要兼容ios4.3,则用__unsafe_unretained代替__weak,不过目前基本不需考虑这么low的版本)


          self.arr = @[@111@222@333];

         __weak typeof(self) weakSelf=self;

         self.block = ^(NSString *name){

                 NSLog(@"arr:%@", weakSelf.arr);

             };

2)MRC环境下:解决方式与上述基本一致,只不过将__weak关键字换成__block即可,这样的意思是告诉block:小子,不要在内部对self进行retain了!


3)委托delegate


在委托问题上出现循环引用问题已经是老生常谈了,本文也不再细讲,规避该问题的杀手锏也是简单到哭,一字诀:声明delegate时请用assign(MRC)或者weak(ARC),千万别手贱玩一下retain或者strong,毕竟这基本逃不掉循环引用了!


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值