如何更安全的使用Block

来源：互联网发布：八陆融通网络贷款编辑：程序博客网时间：2024/05/16 04:41

http://www.starfelix.com/blog/2014/10/19/ru-he-geng-an-quan-de-shi-yong-block/

前段时间，在公司的项目中发现了内存泄露。查到最后发现是由于没有正确使用Block导致的内存引用循环。简单的解决方案就是补上关键字__weak。那么问题来了，为何[UIView animateWithDuration:animations:completion:]或者GCD中可以不需要声明__weak呢？

如何选择回调方式

在讲这个问题之前，我们先看看Objcio上是怎么判断使用何种回调方式：
从这张图可以看到选择block的回掉方式的前提条件是sender能保证将callback被设为nil。定这个条件的目的是为了避免内存泄露。为何这样可以避免内存泄露呢？我们先看看通常我们是如何解决由使用block引入的内存引用循环问题。

引用循环

下面是一个内存引用循环的例子

typedef void(^my_completion_block_t)(NSArray* result);@interface UsersViewController : UIViewController@property (nonatomic, copy) my_completion_block_t completion;@property (nonatomic) NSArray* users;@end

这里可以看到，UsersViewController持有一个block的强引用。如果一个不小心，我们会写出下面这样的代码：

self.completion = ^(NSArray* users){    self.users = users;}[self fetchUsers];

self持有了对completion的强引用，而completion的代码块内引用了self会引起对self的强引用，这便是一个经典的引用循环的案例。
在MRC下，__block id x;可以让block不强引用x。在ARC下，__block id x;默认的行为会强引用x。为了在ARC下解决这个问题，你可以使用__unsafe_unretained __block id x;。但是，这样做非常危险，因为当你的block里访问x时，x可能已经被释放了，变成野指针。你有两个更好的解决办法，一是换成使用__weak，二是在block内设置__block值为nil来打破引用循环。
如下：
1.使用__weak来表示对self的弱引用（代码里面不直接使用weakSelf的原因是为了在block里面保持对self的强引用，避免代码运行到一半self被释放）

1234567891011

UsersViewController* __weak weakSelf = self;self.completion = ^(NSArray* users) {    UsersViewController* strongSelf = weakSelf;    if (strongSelf) {        strongSelf.users = users;    }    else {        // the view controller does not exist anymore    }}[usersViewController fetchUsers];

2.使用__block关键字修饰self，然后在block里设置为nil

UsersViewController* __block blockSelf = self;self.completion = ^(NSArray* users) {    blockSelf.users = users;    blockSelf = nil;}[usersViewController fetchUsers];

更友好的方式

这个时候我们的疑问来了，既然都可以解决内存循环引用的问题，为何还会有前面这个条件呢？原因就是这种方式严重依赖调用者的使用方式，在日常使用中带来严重的代码质量隐患。而在苹果的sdk中几个使用block的方法中调用者都不需要特别的处理。下面是一个测试代码：

12345678910

- (void)viewDidLoad{    [super viewDidLoad];    NSString *temp=[[NSString alloc] initWithFormat:@"%@",@"我是temp"];    NSLog(@"%p",temp);    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, 30 * NSEC_PER_SEC), dispatch_get_main_queue(), ^{        NSLog(@"%@",temp);    });    [temp release];}

上面代码的作用是进入一个controller后然后延时30s打印一个log，为了方便分析内存，我们使用的是mrc。使用Instructment分析内存如下：
内存1 从图片我们可以看到，temp是在30s后被释放。从Responsible Caller我们可以得出结论，block被持有，然后在30s触发执行后被释放。block中被capture的变量也被释放。如此也避免了内存问题。把代码修改一下：

1234567891011

- (void)viewDidLoad{    [super viewDidLoad];    NSString *temp=[[NSString alloc] initWithFormat:@"%@",@"我是temp"];    NSLog(@"%p",temp);    __block NSString *temp2=temp;    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, 30 * NSEC_PER_SEC), dispatch_get_main_queue(), ^{        NSLog(@"%@",temp2);    });    [temp release];}

同样使用Instructment分析，结果等到NSLog代码执行的时候代码crash了，内存记录如下：
内存2
这说明，如果我们滥用__block，可能会出现在block运行的时候，访问对象已经被释放，造成访问野指针错误。系统SDK向我们展示的是一种更友好使用block的方式，让调用者不需要担心内存引用循环也不会有访问野指针的风险。

结论

1.block的持有方式必须保证是copy，这样block中capture的对象才会被retain，保证block在执行的时候capture对象不会被提前释放。
2.为了避免引用循环，被copy的block必须保证在某个时刻被释放，以破坏引用循环。使得所有对象能被正常的释放。

Posted by Star Felix Jew Oct 19th, 2014

0 0