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的那个开始方法中时这样写的：

- (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#里面这种情况是不会释放掉了。

例子二：在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的作用域!