(0033) iOS 开发之Block 的基础用法及注意事项2

循环引用之String

当在block内部使用成员变量的时候，比如

@interface ViewController : UIViewController { 

    NSString *_string; 

} 

@end 

在block创建中：

 _block = ^(){    

    NSLog(@"string %@", _string); 

}; 

这里的_string相当于是self->_string；那么block是会对内部的对象进行一次retain。也就是说，self会被retain一次。当self释放的时候，需要block释放后才会对self进行释放，但是block的释放又需要等self的dealloc中才会释放。如此一来变形成了循环引用，导致内存泄露。

 

修改方案是新建一个__block修饰的局部变量，并把self赋值给它，而在block内部则使用这个局部变量来进行取值。因为__block标记的变量是不会被自动retain的。

__block ViewController *controller = self; 

_block = ^(){ 

    NSLog(@"string %@", controller->_string); 

}; 

【原】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:1 target:self    selector:@selector(handleTimer:) userInfo:nil repeats:YES];

   }

  return  self;

}

- (void)handleTimer:(id)sender

{

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

}

- (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_NOW, 5*NSEC_PER_SEC), dispatch_get_main_queue(), ^{

        [f release];

      });

我们所期待的结果是，初始化5秒后，f对象被release，f的dealloc方法被调用，在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_NOW, 5*NSEC_PER_SEC), 

dispatch_get_main_queue(), ^{

   [f cleanTimer];

   [f release];

});

=======================================

（2）block

block：在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对象无法被析构：

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

由此我们知道了，即使在你的block代码中没有显式地出现"self"，也会出现循环引用！只要你在block里用到了self所拥有的东西！但对于这种情况，我们无法通过加__weak声明或者__block声明去禁止block对self进行强引用或者强制增加引用计数。但我们可以通过其他指针来避免循环引用，具体是这么做的：

 __weak typeof(self) weakSelf = self;

self.blkA = ^{

       __strong typeof(weakSelf) strongSelf = weakSelf;  //  加一下强引用，避免weakSelf被释放掉

       NSLog(@"%@", strongSelf->_xxView);    //  不会导致循环引用.

};

 

对于self.arr的情况，我们要分两种环境去解决：

1)ARC环境下：ARC环境下可以通过使用_weak声明一个代替self的新变量代替原先的self，我们可以命名为weakSelf。通过这种方式告诉block，不要在block内部对self进行强制strong引用

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

__weak typeof(self) weakSelf=self;

self.block = ^(NSString *name){

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

};

 

=========================================================

（3）委托delegate

在委托问题上出现循环引用一字诀：声明delegate时请用assign(MRC)或者weak(ARC)，千万别手贱玩一下retain或者strong！

iOS循环引用 委托 （实例说明）

如何避免循环引用造成的内存泄漏呢：

　　以delegate模式为例(viewcontroller和view之间就是代理模式，viewcontroller有view的使用权，viewcontroller同时也是view的代理(处理view中的事件))：

#import UserWebService.h

// 定义一个ws完成的delegate

@protocol WsCompleteDelegate

@required

-(void) finished;// 需要实现的方法

@end

@interface UserWebService:NSObject

{

     id delegate;//一个id类型的dategate对象

}

@property (assign) id delegate;

- (id)initWithUserData:(User *)user;

- (void)connectionDidFinishLoading:(NSURLConnection *)connection;

@end

UserWebService.m:

@systhesize delegate;//同步这个delegate对象

@implementation UserWebService

- (void)connectionDidFinishLoading:(NSURLConnection *)connection

{

      [delegate finished]

}

@end

LoginViewController.h:

#import "UserWebService.h" //包含含有委托的头文件

@interface LoginViewController:UIViewController

- (void)submit;

@end

　　

LoginViewController.m:

@implementation LoginViewController

 - (void) submit

  {

　　User *user = [[User alloc]init];

　　[user setUserId:@"username"];

　   [user setPassword:@"password"];

　　ws = [[UserWebService alloc] initWithUserData:user];

　　ws.delegate = self;//设置委托的收听对象

　　[user release];

   　[ws send];

 }

　　// 实现委托中的方法

 - (void) finished

  {

　  　NSAttry *users = [ws users];

　}

　@end

@property (assign) id delegate; 可以看到，delegate声明为assign：

你的工程是叫Sections吧？

这就是你的抛异常的地方：

4 Sections 0x000030eb -[BIDViewController searchDisplayController:didLoadSearchResultsTableView:] + 171

关于堆栈报告，简单介绍它里面的内容是什么含义：

比如：4 Sections 0x000030eb -[BIDViewController searchDisplayController:didLoadSearchResultsTableView:] + 171

一共包括了5部分：分别是4/Sections/0x000030eb/-[BIDVi...ew:]/171

第1部分：堆栈输出序列号，序号越大表示代码越早被调用；
第2部分：调用的方法所属框架（库/工程），例如Sections就是楼主您的工程；
第3部分：调用方法的内存地址，即0x000030eb
第4部分：调用方法名，这个非常重要，即-[BIDViewController searchDisplayController:didLoadSearchResultsTableView:]
第5部分：调用方法编译之后的代码偏移量，这里再次强调不是行号，只是编译后的代码偏移量，但是基本上和字符数差不多，你可以通过一些文本工具，通过统计你的方法的字符偏移量大致的估计出错的行，一般误差在3~5行内。