ARC下的内存泄露

iOS提供了ARC功能,很大程度上简化了内存管理的代码。

但使用ARC并不代表了不会发生内存泄露,使用不当照样会发生内存泄露。

下面列举两种ARC导致内存泄露的情况。

1,循环参照

A有个属性参照B,B有个属性参照A,如果都是strong参照的话,两个对象都无法释放。

这种问题常发生于把delegate声明为strong属性了。

例,

@interface SampleViewController

@property (nonatomic, strong) SampleClass *sampleClass;

@end

@interface SampleClass

@property (nonatomic, strong) SampleViewController *delegate;

@end

 

上例中,解决办法是把SampleClass 的delegate属性的strong改为assing即可。

 

 

2,死循环

如果某个ViewController中有无限循环,也会导致即使ViewController对应的view关掉了,ViewController也不能被释放。

这种问题常发生于animation处理。

例,

比如,

CATransition *transition = [CATransition animation];

transition.duration = 0.5;

tansition.repeatCount = HUGE_VALL;

[self.view.layer addAnimation:transition forKey:"myAnimation"];

 

上例中,animation重复次数设成HUGE_VALL,一个很大的数值,基本上等于无限循环了。

解决办法是,在ViewController关掉的时候,停止这个animation。

-(void)viewWillDisappear:(BOOL)animated {

    [self.view.layer removeAllAnimations];

}

 

内存泄露的情况当然不止以上两种。

即使用了ARC,我们也要深刻理解iOS的内存管理机制,这样才能有效避免内存泄露。

 

arc的程序出现内存泄露怎办

实例一:

用arc和非arc混编,非arc的类在arc里实例化并且使用,在arc里居然出现内存泄露,而且应为是arc,所以无法使用release,autorelease和dealloc去管理内存。正常情况下应该是不会出现这种情况的,某一个类若是ARC,则在这个类里面都应该遵循ARC的用法,而无需关心用到的类是否是ARC的,同样,在非ARC类里面,就需要遵循内存管理原则。


用ARC,只是编译器帮你管理了何时去release,retain,不用ARC就需要你自己去管理,说到底只是谁去管理的问题,所以你再好好看看,可能问题与ARC无关。
如果实在找不到问题,建议你找到泄露的那个对象,将其赋值为nil,因为ARC里面,一旦对象没有指针指向,就会马上被释放。
 

实例二:

最近在学objective-c,我发现创建项目时如果使用了ARC,非常容易内存泄露,经常某个对象已经被释放掉了我还在使用,由于不太了解这个机制,现在我举出两个例子,请经验者帮我分析一下。
例子一:一开始,在AppDelegate.m的那个开始方法中时这样写的:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];    
    // Override point for customization after application launch.
    self.window.backgroundColor = [UIColor whiteColor];
    //
    UITabBarController  tabBarController = [[UITabBarController alloc] init];
    [tabBarController setViewControllers:[self showConnectViewOnWindow]];
    [tabBarController setDelegate:self];
    //
    [[self window] addSubview: [tabBarController view]];
     
    [self.window makeKeyAndVisible];
    return YES;
}

然后,我还做了其他的工作:tabBarController中有tabBarItem,点击会调用一个方法
但是每次一点击,就会报unrecognized selector send to instance的错误,
后来上网一查,说是要把tabBarController定义成全局变量,不然这个方法一结束,tabBarController就被释放掉了,这样点击产生时间的对象都没了,于是我把它定义成全局变量,确实可以了,但我的疑问是,为什么方法一结束他就会释放掉吗,[[self window] addSubview: [tabBarController view]];我这一句不是已经在self window里引用它了吗,他怎么还会被释放,我觉得java和C#里面这种情况是不会释放掉了。

1
2
3
4
5
6
7
8
例子二:在viewdidload方法里面:
    [self.navigationItem setTitle:Title];
     
    leftButton = [[UIBarButtonItem alloc] initWithTitle:Cancel 
                                                  style:UIBarButtonItemStyleBordered 
                                                 target:self 
                                                 action:@selector(CancleButtonClicked)];
    self.navigationItem.leftBarButtonItem = leftButton;

这里我给屏幕上方那个导航条加了一个左边的按钮,然后点击这个按钮后会用方法CancleButtonClicked来响应,但是我运行起来一点击,还是报unrecognized selector send to instances错误了,这里又是哪个对象释放了,leftButton吗?但是self.navigationItem.leftBarButtonItem = leftButton已经引用了啊。

 

解决方法:

 

例子一[[self window] addSubview: [tabBarController view]];
你只引用了tabBarController的view,没有引用tabBarController

例子二,不知道什么原因,看看有没有拼写错误吧。

另外,我感觉局部变量的内存一般只在它的生命周期内有效。出了它所定义的区域,即使不释放,也最好不要用了。

 

 

自从使用了ARC,代码写起来方便了很多,不需要retain,release,dealloc了,但是也隐藏了一些释放内存的问题。

如果你不打印一下dealloc中的信息,也许你还真的不知道你的controller,view等等资源没有释放。很多问题都可能造成资源不能够及时释放。其中有一个很容易忽略的问题,block会自动retain你的变量。
如果你引用的是一个实例变量,它会直接对self进行retain,这有时候有可能会产生一个引用环(两个或以上的对象之间直接或间接地互相引用)并导致内存泄露。解决的方法是:当需要在Block中访问实例变量的时候,创建一个指向self的指针,并对其使用__block修饰符,这样self不会被自动retain
 
 
说法二
 

BLock的内存泄露

  在我们代码中关于block的使用可以说随处可见,第一次接触block的时候是关于UIView的块动画,那时觉得block的使用好神奇, 再后来分析总结为block其实就是一个c语言函数,只是我们可以在任意处调用此函数。有了这样的理解我开始经常使用block。在做项目以后发现使用 block竟然会引起内存泄露,于是开始自己调试研究block的内存管理问题。

普通的block使用(包括块动画)

这里有一个简单的block使用,在里面我们可以添加任何自己想进行的操作,大部分的使用也是如此

1 void (^Block)(int) = ^(int num){
2    //此处还可添加其他代码 ....
3    NSLog(@"int number is %d",num);
4 };

包括UIView的块动画也是如此使用,在这里我们定义了一个图像视图的位置及透明度的变化

1 [UIView animateWithDuration:2.0 animations:^(void){
2     smallImage.frame = CGRectMake(150, 80, 30, 30);
3 } completion:^(BOOL finished) {
4      smallImage.alpha = 0;

这些block操作中,我一直都认为block中的对象会在block使用后就被释放(但UIView的操作好像是这么做的)

block内存管理初现

  直到我在项目中遇见这样一个情况:我设置有2个控制器first及second,其中second中包含一个block对象,而block的实 现是在first中实现(一般的block传值都是这么做)。而界面的推送是由first控制器push出second控制器。但当我second控制器 pop的时候,问题出现second控制器不走delloc方法,即pop后second控制器还存在没有被销毁(因为当时要做delloc中做一些操 作,才发现这个问题)!block示例代码如下:

first控制器中block的实现

1 SecondViewController *secondVC = [[SecondViewController alloc] init];
2 secondVC .block = ^(NSString *text){
3         self.text = secondVC.text;
4 };

  这么一个简单的传值block使用,居然能引起second控制器无法释放,于是研究其原理,并网上搜索资料,得出一个结论:second控制 器在block中被持有一次才导致其无法释放。因为block本质上是一个函数,而编译器不知道你什么时候会调用block里面的值,所以为了确保编译器 内secondVC不会被释放,编译器会自动对其进行一次持有(在自身类中使用block方法操作自身的成员属性也会使自己的引用计算加1,造成无法释 放)。

其解决办法也简单 在外部添加一个弱引用对象指向需要在block中操作的对象,即__weak typeof(对象名) 别名= 对象名;

1 SecondViewController *secondVC = [[SecondViewController alloc] init];
2 __weak typeof(secondVC) second = secondVC;
3 __weak typeof(self) vc = self;
4 2 secondVC .block = ^(NSString *text){
5 3         vc.text = second.text;
6 4 };

这样就能够有效的防止block使用引起的内存泄露问题。

NSTimer使用问题

另外在还在项目中遇见一个关于NSTimer的使用问题。我们想到在控制器销毁时同时停止NSTimer并置为nil

1 -(void)dealloc {
2     [self.timer invalidate];
3     self.timer = nil;
4     NSLog(@"%@ dealloc", NSStringFromClass([self class]));
5 }

然而控制器被pop后并没有走此方法(又是内存泄露),由于之前出现了Block内存泄露的问题,我就想是不是因为这个_timer加载的时候对self进行了一次持有

_timer = [NSTimer scheduledTimerWithTimeInterval:1.0 target:self selector:@selector(timerUp:) userInfo:nil repeats:YES];

进行调试测验,果然是这里出了问题,因为其对控制器持有了一次。于是我想到既然这样那我干脆就在viewWillDisappear()中做个判 断,如果是pop控制器,我就先设置[self.timer invalidate]操作这样控制器就会走dealloc()方法。后来再网上找资料发现了一个更简单的解决办法,即同Block的内存管理一样使用弱 引用对象

1 __weak typeof(self) vc = self;
2 _timer = [NSTimer scheduledTimerWithTimeInterval:1.0 target:vc selector:@selector(timerUp:) userInfo:nil repeats:YES];

这样的解决办法就要比我之前的要简单多了,唯一需要注意的就是此处vc的作用域!

 

posted on 2016-01-14 17:09  🌞Bob  阅读(210)  评论(0编辑  收藏  举报

导航