和block循环引用说再见

to be block? or to be delegate?

这是一个钻石恒久远的问题。个人在编码中暂时没有发现两者不能通用的地方，习惯上更偏向于block，没有什么很深刻的原因，只是认为block回调写起来更便捷，直接在上下文中写block回调使得代码结构更清晰，可读性更强。而delegate还需要申明protocol接口，设置代理对象，回调方法与上下文环境不能很好契合，维护起来没有block方便。另外初学者很容易会被忘记设置代理对象坑…

然而惯用block是有代价的，最大的风险就是循环引用，这个问题一旦没有处理好就会造成内存泄露，而且问题很难被发现。本篇将以简单的demo谈谈ARC下block循环引用产生的原因以及避免block的循环引用。

ARC场景分析

场景一
来看看最简单的block循环引用的案例。由一个控制器自己申明一个block属性，执行block打印自己的另一个成员变量。上代码：

//MyViewController.mtypedef void(^TestFn)();  //申明block变量类型@interface MyViewController ()@property (strong, nonatomic) NSObject *obj;@property (copy, nonatomic) TestFn testFn;  //申明block属性@end@implementation MyViewController- (void)viewDidLoad {    [super viewDidLoad];    self.obj = [[NSObject alloc]init];    self.testFn = ^(){        NSLog(@"%@",self.obj);    };    self.testFn();}- (void)viewWillAppear:(BOOL)animated{    [super viewWillAppear:animated];    NSLog(@"push to stack");}- (void)viewDidDisappear:(BOOL)animated{    [super viewDidDisappear:animated];    NSLog(@"pop from stack");}- (void)dealloc{    NSLog(@"myViewController dealloc");}@end

事实上，上面代码会给出一个警告 Capturing 'self' strongly in this block is likely to lead to a retain cycle 告诉我们这样写将引发循环引用。

不如亲眼见证一下是否真的会循环引用。将该控制器push到一个导航控制器，然后pop出栈，查看dealloc方法是否被调用，若调用，则说明MyViewController被释放，并没有引起循环引用；若没被调用，则说明MyViewController无法释放，内存泄露。

push后控制台打印

2016-07-17 12:32:40.037 test[83585:2901002] <NSObject: 0x7fa76859ec80>
2016-07-17 12:32:40.038 test[83585:2901002] push to stack

pop后：

2016-07-17 12:32:40.037 test[83585:2901002] <NSObject: 0x7fa76859ec80>
2016-07-17 12:32:40.038 test[83585:2901002] push to stack
2016-07-17 12:33:42.375 test[83585:2901002] pop from stack

dealloc方法并没有被调用，课件控制器没有被释放，而内存泄露正是block造成的。原因在于，block会retain其内部的对象，在上面的代码中会retain self所指向的对象。同时block作为self的成员变量，会被self持有。这就造成了self和block彼此持有，谁都无法释放谁的局面，从而内存泄露。

暂且不说如何避免引用循环。这个例子中，XCode给出了循环引用的警告，方便我们发现捕捉问题。然而实际编码中，很多场景是没有警告的，不谨慎使用很难发现循环引用的存在。

场景二

经常会有点击一个cell上的按钮触发block回调的需求，为简单起见，这里以点击UIView上绑定的按钮触发block回调为例演示。先上代码：

自定义一个UIView对象MyView，暴露block回调属性

//MyView.h#import <UIKit/UIKit.h>typedef void(^XFTestFn)();@interface MyView : UIView@property (nonatomic, copy) XFTestFn testFn;@end//MyView.m#import "MyView.h"@implementation MyView- (instancetype)initWithFrame:(CGRect)frame{    self = [super initWithFrame:frame];    if (self) {        NSLog(@"myview instance created");        UIButton *button = [UIButton buttonWithType:UIButtonTypeCustom];        button.frame = CGRectMake(0, 0, 100, 40);        button.backgroundColor = [UIColor orangeColor];        [button setTitle:@"点击回调" forState:UIControlStateNormal];        [button setTitleColor:[UIColor whiteColor] forState:UIControlStateNormal];        [button addTarget:self action:@selector(actionBack:) forControlEvents:UIControlEventTouchUpInside];        [self addSubview:button];    }    return self;}- (void)actionBack:(UIButton *)sender{    if (self.testFn) {        self.testFn();    }}- (void)dealloc{    NSLog(@"myView dealloc");}@end

创建一个控制器MyViewController作为回调上下文

//MyViewController.m@interface MyViewController ()@property (strong, nonatomic) NSObject *obj;@end@implementation MyViewController- (void)viewDidLoad {    [super viewDidLoad];    self.obj = [[NSObject alloc]init];    MyView *myView = [[MyView alloc]initWithFrame:CGRectMake(0, 0, self.view.frame.size.width, 300)];    myView.testFn = ^(){        NSLog(@"button callback: %@",self.obj);    };    [self.view addSubview:myView];}- (void)viewWillAppear:(BOOL)animated{    [super viewWillAppear:animated];    NSLog(@"push to stack");}- (void)viewDidDisappear:(BOOL)animated{    [super viewDidDisappear:animated];    NSLog(@"pop from stack");}- (void)dealloc{    NSLog(@"myViewController dealloc");}@end

运行后，push到MyViewController控制器，点击按钮回调，然后pop。控制台打印信息如下：

2016-07-17 17:51:40.298 test[84299:3026143] myview instance created
2016-07-17 17:51:40.299 test[84299:3026143] push to stack
2016-07-17 17:51:41.157 test[84299:3026143] button callback: <NSObject: 0x7fd1ca54b3c0>
2016-07-17 17:51:42.269 test[84299:3026143] pop from stack

发现myView的dealloc和myViewController的dealloc方法都被调用，可见上面代码同样产生了循环引用，尽管XCode没有给出警告。下图可以表明产生循环引用的原因：

场景三

将场景二中myViewController.m代码替换如下：

//MyViewController.m@implementation MyViewController- (void)viewDidLoad {    [super viewDidLoad];        MyView *myView = [[MyView alloc]initWithFrame:CGRectMake(0, 0, self.view.frame.size.width, 300)];    myView.testFn = ^(){        myView.backgroundColor = [UIColor purpleColor];    };    [self.view addSubview:myView];}- (void)viewWillAppear:(BOOL)animated{    [super viewWillAppear:animated];    NSLog(@"push to stack");}- (void)viewDidDisappear:(BOOL)animated{    [super viewDidDisappear:animated];    NSLog(@"pop from stack");}- (void)dealloc{    NSLog(@"myViewController dealloc");}@end

运行一趟打印如下：

2016-07-17 18:05:24.529 test[84327:3032859] myview instance created
2016-07-17 18:05:24.530 test[84327:3032859] push to stack
2016-07-17 18:05:28.563 test[84327:3032859] pop from stack
2016-07-17 18:05:28.563 test[84327:3032859] myViewController dealloc

可以看到，myViewController被释放了，然而myView的dealloc方法并没有调用。原因同样是因为产生了循环引用，元凶则是myView自己。myView持有自己的成员变量block，block在执行时对myView做了操作，因此retain了一下myView。这样，myView与block互相强引用，彼此无法释放。

打破循环引用

分析一下上面3个产生循环引用的场景，原因可以概括为：block中使用了持有或间接持有block的变量，所谓的持有就是强引用。因此要想打破循环引用，只要打破其中任意一个强引用即可。外部变量必然会copy一份block，那么只能对block中用到的变量做手脚，以使block不持有这个变量所指的对象。以场景二为例，在block外面添加一行代码：

- (void)viewDidLoad {    [super viewDidLoad];    self.obj = [[NSObject alloc]init];    MyView *myView = [[MyView alloc]initWithFrame:CGRectMake(0, 0, self.view.frame.size.width, 300)];    __weak typeof(self) weakSelf = self;    //创建一个self对象的弱引用变量    myView.testFn = ^(){        NSLog(@"button callback: %@",weakSelf.obj);    };    [self.view addSubview:myView];}

ok，运行一下打印如下：

2016-07-17 18:47:46.208 test[84381:3053425] myview instance created
2016-07-17 18:47:46.209 test[84381:3053425] push to stack
2016-07-17 18:47:48.122 test[84381:3053425] button callback: <NSObject: 0x7ffa6bdd7170>
2016-07-17 18:47:50.030 test[84381:3053425] pop from stack
2016-07-17 18:47:50.030 test[84381:3053425] myViewController dealloc
2016-07-17 18:47:50.031 test[84381:3053425] myView dealloc

surprised!视图和控制器在pop之后都被释放了，说明并没有产生循环引用。原因在于我们创建了一个self对象的弱引用变量，供block内部使用，因此block并不会强引用self对象。对象间的引用关系如下：

循环引用成功打破，我们的目的似乎已经达到了。然而，细心的童鞋会发现，block没有强引用对象，这样可能会产生一个问题：当block回调被执行的时候，其弱引用的对象随时都有可能被外部释放！为避免block在执行过程中相关的对象被释放，修改代码如下：

- (void)viewDidLoad {    [super viewDidLoad];    self.obj = [[NSObject alloc]init];    MyView *myView = [[MyView alloc]initWithFrame:CGRectMake(0, 0, self.view.frame.size.width, 300)];    __weak typeof(self) weakSelf = self;    myView.testFn = ^(){        __strong typeof(self) strongSelf = weakSelf;    //在block内部创建一个strong类型的变量指向self        NSLog(@"button callback: %@",strongSelf.obj);    };    [self.view addSubview:myView];}

上述代码在block开始执行的时候创建了一个变量strongSelf，强引用self对象。绕来少绕，似乎又绕回来了！其实不然，之前block强引用self对象是因为block在执行时copy了self对象的指针，只有当block本身释放时其对self的强引用才会撤销。而此处是在block内部创建了一个指向self的局部变量，是保存在栈上的，一旦block执行作用域结束，该变量就被自动释放了。因此并不会产生循环引用。对象间的关系如下：

@weakify, @strongify

@weakify和@strongify是一对非常好用的用于管理block循环引用的宏，定义于libextobjc框架的EXTScope文件中。对于上面的代码，只需要这样写：

- (void)viewDidLoad {    [super viewDidLoad];    self.obj = [[NSObject alloc]init];    MyView *myView = [[MyView alloc]initWithFrame:CGRectMake(0, 0, self.view.frame.size.width, 300)];    @weakify(self)              //创建一个 self_weak 变量弱引用self对象    myView.testFn = ^(){        @strongify(self)        //创建一个 局部self 变量强引用self对象        NSLog(@"button callback: %@",self.obj);    };    [self.view addSubview:myView];}

@weakify(self) 创建了一个 self_weak_ 变量弱引用self对象。
@strongify(self) 在block内部创建了一个局部变量 self 强引用 self_weak_ 指向的对象，即self对象。

因此这两个宏定义完全等价于：
__weak typeof(self) weakSelf = self;
__strong typeof(self) strongSelf = weakSelf;

不要碰到block就套@weakify, @strongify

@weakify的作用是为了避免block强引用self对象，@strongify的作用的保证block在执行的时候self对象不被外界所释放。然而，并不能保证block在执行之前self对象不被释放。创建下面一个继承自NSObject的类：

//AsynHelper.h@interface AsynHelper : NSObject- (void)doAsyncWork;@end//AsynHelper.m@interface AsynHelper ()@property (nonatomic, strong) NSObject *obj;@end@implementation AsynHelper{    NSObject *_obj;}- (instancetype)init{    self = [super init];    if (self) {        NSLog(@"NetworkHelper instance created!");    }    return self;}- (void)doAsyncWork{    _obj = [[NSObject alloc]init];    @weakify(self)    dispatch_async(dispatch_get_main_queue(), ^{        @strongify(self)        NSLog(@"asyn called:%@",self.obj);    });}- (void)dealloc{    NSLog(@"NetworkHelper instance dealloc");}@end

在控制器中通过init方法实例化一个对象，并调用doAsyncWork方法。

AsynHelper *helper = [[AsynHelper alloc]init];[helper doAsyncWork];

执行后打印如下：
2016-07-21 18:26:02.749 test[37126:4701929] NetworkHelper instance created!
2016-07-21 18:26:02.750 test[37126:4701929] NetworkHelper instance dealloc
2016-07-21 18:26:02.764 test[37126:4701929] asyn called:(null)

可以看到，helper实例是被释放了，但是block执行的打印结果却为null。断点一调，发现当block执行的时候，self变量竟然为nil。揪其原因，全是异步惹的祸。@strongify(self) 是在block执行域创建了有个局部self变量，并把通过 @weakify(self) 创建的 self
_weak_ 变量值赋值给它。 然而block是异步执行的，还没等到他执行，helper示例过了执行域就被释放了（这点通过打印结果也能看出来）,因此当执行 @strongify(self) 时，self_weak_ 已为nil，自然创建的self变量也是nil。

最常见的异步执行block的情况应当是网络请求通过block异步回调了。因此在成对使用 @weakify, @strongify 是应当确保当前对象不会轻易被释放，尤其是在临时创建的cocoa对象（集成字NSObject）中使用异步回调block，不出意外都会出现这个问题。

事实上，上面这段代码根本没有必要套 @weakify(self),@strongify(self)，因为这个执行的block是临时的，当前对象并没有持有block，所以直接在block中使用self不会造成循环引用。那么问题又来了，哪些情况下使用block应当小心循环应用？

哪些场景下的block要当心循环运用

将block简单分类，有下面3种使用场景：

• 临时创建的。包括临时并执行的自定义申明的block类型变量，以及系统的例如数组enumerate遍历用到的block，这些block变量都是临时创建使用的，保存在栈上，出域便会自动释放，不存在引用循环的问题。

• 需要存储在堆上但只调用一次的。例如GCD的异步执行block、UIView动画执行完毕后的回调block等，这些block会在堆上保存。这类block的正确实现应当是block一旦执行完毕就置其为nil，这样就不存在循环引用的问题。

• 需要长期存储的。例如button点击回调block，这类block需要多次执行，需要长期存储。使用这种block要特别当心循环引用的问题。