iOS 循环引用解决方案

Posted xujinzhong

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了iOS 循环引用解决方案相关的知识,希望对你有一定的参考价值。

一、BLOCK 循环引用

一般表现为,某个类将block作为自己的属性变量,然后该类在block的方法体里面又使用了该类本身。构成循环引用。

// 定义 block 的时候,会对外部变量做一次 copy,强引用, self自身为强引用。

解决方案如下:

 1 #import "ViewController.h"
 2 #import "NetworkTools.h"
 3 
 4 @interface ViewController ()
 5     @property (nonatomic, strong) NetworkTools *tools;
 6 @end
 7 
 8 @implementation ViewController
 9 // 1. 解除循环引用,需要注意打断引用链条即可!
10 - (void)viewDidLoad {
11     [super viewDidLoad];
12     
13     // 局部变量不会产生循环应用,全局属性会产生循环引用
14     self.tools = [[NetworkTools alloc] init];
15     
16     // 1. 定义 block 的时候,会对外部变量做一次 copy,会对 self 进行强引用
17     
18     // 解除循环引用方法1
19     // __weak 是 ios 5.0 推出的
20     // 如果异步操作没有完成,释放控制器,__weak 本身是弱引用
21     // 当异步执行完毕,进行回调,self 已经被释放,无法访问属性,也无法调用方法
22     // __weak 相当于 weak,不会做强引用,但是如果对象被释放,执行的地址,会指向 nil
23     // __weak 更安全
24     __weak typeof(self) weakSelf = self;
25     
26     // 解除循环引用方法2
27     // __unsafe_unretained 是 iOS 4.0 推出的
28     // MRC 经典错误,EXC_BAD_ACCESS 坏内存访问,野指针
29     // 相当于 assign,不会做强引用,但是如果对象被释放,内存地址保持不变,如果此时再调用,就会出现野指针访问
30     // __unsafe_unretained typeof(self) weakSelf = self;
31     
32     [self.tools loadData:^(NSString *html) {
33         // strongSelf 强引用,对 weakSelf 进行强引用,本意,希望在异步完成后,继续执行回调代码
34         //然而并没有什么作用!!!!!!!!
35         __strong typeof(self) strongSelf = weakSelf;
36         
37         NSLog(@"%@ %@", html, strongSelf.view);
38     }];
39 }
40 
41 - (void)dealloc {
42     NSLog(@"控制器 88");
43 }
44 
45 @end

二、计时器NSTimer循环引用

主要是因为从timer的角度,timer认为调用方self被析构时会进入dealloc,在dealloc可以顺便将timer的计时停掉并且释放内存;但是从self的角度,他认为timer不停止计时不析构,那我永远没机会进入dealloc。循环引用,互相等待,子子孙孙无穷尽也。

例子说明:

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

 1 import <Foundation/Foundation.h>
 2 
 3 interface Friend : NSObject
 4     -(void)cleanTimer;
 5 end
 6 
 7 import "Friend.h"
 8 
 9 interface Friend ()
10     STimer *_timer;
11 end
12 
13 implementation Friend
14 
15 -(id)init
16 {
17     if (self = [super init]) {
18         _timer = [NSTimer scheduledTimerWithTimeInterval:1 target:self selector:@selector(handleTimer:)
19         userInfo:nil repeats:YES];
20     }
21     return self;
22 }
23 
24 - (void)handleTimer:(id)sender
25 {
26     NSLog(@"%@ say: Hi!", [self class]);
27 }
28 
29 - (void)cleanTimer
30 {
31     [_timer invalidate];
32     _timer = nil;
33 }
34 
35 - (void)dealloc
36 {
37     [self cleanTimer];
38     NSLog(@"[Friend class] is dealloced");
39 }
40 
41 @end

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

1 Friend *f = [[Friend alloc] init];
2 dispatch_after(dispatch_time(DISPATCH_TIME_NOW, 5*NSEC_PER_SEC), dispatch_get_main_queue(), ^{
3     [f release];
4 });

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

 1 2015-03-18 18:00:35.300 WZLCodeLibrary[41422:3390529] Friend say: Hi!
 2 2015-03-18 18:00:36.299 WZLCodeLibrary[41422:3390529] Friend say: Hi!
 3 2015-03-18 18:00:37.300 WZLCodeLibrary[41422:3390529] Friend say: Hi!
 4 2015-03-18 18:00:38.299 WZLCodeLibrary[41422:3390529] Friend say: Hi!
 5 2015-03-18 18:00:39.299 WZLCodeLibrary[41422:3390529] Friend say: Hi!//运行了5次后没按照预想的停下来
 6 2015-03-18 18:00:40.299 WZLCodeLibrary[41422:3390529] Friend say: Hi!
 7 2015-03-18 18:00:41.300 WZLCodeLibrary[41422:3390529] Friend say: Hi!
 8 2015-03-18 18:00:42.300 WZLCodeLibrary[41422:3390529] Friend say: Hi!
 9 2015-03-18 18:00:43.299 WZLCodeLibrary[41422:3390529] Friend say: Hi!
10 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的调用者显式地调用来清理现场。如下:

1 Friend *f = [[Friend alloc] init];
2 dispatch_after(dispatch_time(DISPATCH_TIME_NOW, 5*NSEC_PER_SEC), dispatch_get_main_queue(), ^{
3     [f cleanTimer];
4     [f release];
5 });

三、委托delegate

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

上面说的是我们常见的,其实循环引用就是说我们的强引用形成了闭环,还会有很多自己写的代码中会出现,平时还是要注意写法。

不好意思,下面再啰嗦一遍,进一步说明:

循环引用,指的是多个对象相互引用时,使得引用形成一个环形,导致外部无法真正是否掉这块环形内存。其实有点类似死锁。

举个例子:A->B->C->....->X->B ->表示强引用,这样的B的引用计数就是2,假如A被系统释放了,理论上A会自动减小A所引用的资源,就是B,那么这时候B的引用计数就变成了1,所有B无法被释放,然而A已经被释放了,所有B的内存部分就肯定无法再释放再重新利用这部分内存空间了,导致内存泄漏。

情况一:delegate

Delegate是ios中开发中最常遇到的循环引用,一般在声明delegate的时候都要使用弱引用weak或者assign

@property (nonatomic, weak, nullable) id <UITableViewDelegate> delegate;
当然怎么选择使用assign还是weak,MRC的话只能用assign,在ARC的情况下最好使用weak,因为weak修饰的变量在是否后自动为指向nil,防止不安全的野指针存在

情况二:Block

Block也是比较常见的循环引用问题,在Block中使用了self容易出现循环引用,因此很多人在使用block的时候,加入里面有用到self的操作都会声明一个__weak来修饰self。其实便不是这样的,不是所有使用了Block都会出现Self循环引用问题,只有self拥有Block的强引用才会出现这种情况。

所以一般在函数中临时使用Block是不会出现循环应用的,因为这时候Block引用是属于栈的。当栈上的block释放后,block中对self的引用计数也会减掉

当然不一定要Self对Block有直接的引用才会出现,假如self的变量B,B中有个Block变量,就容易出现这种情况,好的是在block出现循环引用的,xcode7会出现警告提示(之前版本不确定)。

情况三:NSTimer

这是一个神奇的NSTimer,当你创建使用NSTimer的时候,NSTimer会默认对当前self有个强引用,所有在self使用完成打算是否的时候,一定要先使用NSTimer的invalidate来停止是否时间控制对self的引用

[_timer invalidate];

 

以上是关于iOS 循环引用解决方案的主要内容,如果未能解决你的问题,请参考以下文章

iOS循环引用常见场景和解决办法

🔥🔥iOS中解决NSTimer循环引用问题

iOS底层探索之Block——如何解决Block循环引用问题?

iOS,AVPlayer - 循环播放 MP3 片段

为啥iOS的Masonry中的self不会循环引用

未解决的对“片段”部分中的符号“”的引用