iOS里的内存泄露

前言

要讲关于iOS里的内存泄露，那就需要了解一下iOS的内存管理机制。现在基本上我们使用的是ARC机制，在iOS5之前内存管理是MRC机制。MRC秉承着‘谁创建，谁释放，谁引用，谁管理’的理念来管理内存，所以那个时代的iOS程序员还是比较苦逼的，一不小心就导致内存泄露或过度释放了。

我刚开始学iOS开发的时候，基本上已经过度到了ARC，MRC已经用的很少了，听说现在还有人面试的时候会很深入的考一些MRC的东西，其实我觉得没必要了吧，简单的了解一下就行，不必要考的太深入。恩😊所以这里也不会介绍MRC，反正我也不会。

ARC介绍

ARC我们按照字面意思是自动引用计数，在MRC中使用release，autorelease，retain这些关键字，来保留引用计数或者释放对象。而在ARC中相当于就是系统在编译时就帮你做好了这些事情。

这里有几个ARC的基本原则：

• 强引用指向的对象不会被释放。

• 一个对象没有强引用且在AutoreleasePool drain时会立刻释放。

• 弱引用指向的对象将要释放时自动为空。

strong和weak的本质简单点可以这么理解：

在内存中开辟一块空间，strong应该相当于如果多个指针指向该内存空间时，必须所有指向该内存的指针离开时，该对象才会被释放，而weak是该对象的拥有者的指针（强引用）离开时，其余指向该对象的指针（弱引用）就会自动指向空，防止出现野指针。就像协议一般都是weak类型修饰，防止出现野指针。

在ARC中我们创建的对象默认都是强引用的如：

NSString *string = [NSString stringWithFormat:@"齐滇大圣"];等价于__strong NSString *string = [NSString stringWithFormat:@"齐滇大圣"];

在ARC中系统帮我们做了很多事情，内存管理基本都是自动的了，我们不用太关心什么时候release，retain之类的了。但是我们还是需要了解一下ARC是怎么做的，毕竟人家帮我们做了那么多对吧，那程序运行过程中到底什么时候释放对象呢？

什么时候释放对象

我们来看下面一段代码：

- (void)viewDidLoad{
    [super viewDidLoad];
    
    NSString *string = [NSString stringWithFormat:@"齐滇大圣"];
}

这里[NSString stringWithFormat:@"齐滇大圣"];创建对象时这个对象的引用计数为 1 。当使用局部变量 string 指向这个对象时，这个对象的引用计数 +1 ，变成了 2 。而当 viewDidLoad 方法返回时，局部变量 string 被回收，指向了 nil 。因此，其所指向对象的引用计数 -1 ，变成了 1 。

那么问题来了还有一个引用计数怎么办呢？其实我们的这个对象被系统自动添加到了当前的 autoreleasepool 中，当autoreleasepool drain的时候引用计数就会-1，对象就被释放了。那么aotoreleasepool 什么时候drain呢？答案是在runloop一次迭代结束的时候。

那runloop什么时候迭代结束呢？来现在跟我一起看图说话：

这里我们加入一个__weak的全局变量reference来指向我们的对象。因为__weak引用不持有我们的对象，不会影响所指向对象的生命周期，所以我们用它来输出以判断我们的对象什么时候释放。

我们能看到reference在viewDidLoad和viewWillAppear的时候有输出，而在viewDidAppear的时候为null，说明被释放了。那我们来猜测一下runloop的迭代周期。

viewWillAppear很容易理解是即将进入页面嘛，那runloop肯定是还有事要做的嘛，当viewDidAppear的时候表示已经进入页面了。那就表示没事做了，进入睡眠，等待用户动作的时候再次唤醒。你可能会觉得我口说无凭不靠谱，好那我就拿出证据来，我们来看下面两张图。

断点1和断点2

断点3

我们能看到断点1和断点2 runloop还是在执行的，断点3表示runloop一个迭代已经结束了，即将进入睡眠。这里如果对runloop不了解的话可以看ibireme的这篇深入理解RunLoop。我截取里面的一小段，大家可以看一下。

    //触发 Source0 (非基于port的) 回调。
    __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__(source0);
    //out_to_block表示从block跳出，block执行完毕，即将进入睡眠。
    __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__(block);

注意：

上面图中的例子，有一段被注释的代码：

//返回一个自己Alloc申请内存的NSString实例
NSString *string = [[NSString alloc] initWithFormat:@"齐滇大圣"];  

在MRC中alloc创建的实例是需要手动release，而在ARC中alloc创建的实例也没有放入AutoreleasePool。应该是系统在你创建完并有指针指向对象的时候引用计数马上就-1了。所以当viewDidLoad结束的时候，string被回收，引用计数减为0，对象被释放。我们来看一下输出：

2016-04-22 09:29:10.780 test[2001:743463] string: 齐滇大圣
2016-04-22 09:29:11.727 test[2001:743463] string: (null)
2016-04-22 09:29:12.576 test[2001:743463] string: (null)

内存泄露的情况

block下的循环引用

在ARC下基本上不用我们内存管理释放什么的了，但是还是有可能发生内存泄漏的，一个很容易发生的地方就是使用block的时候。block中导致的内存泄漏常常就是因为强引用互相之间持有而发生了循环引用无法释放。

贴上一段AFNetWorking上的经典代码，防止循环引用的。

//创建__weak弱引用，防止强引用互相持有
__weak __typeof(self)weakSelf = self;
AFNetworkReachabilityStatusBlock callback = ^(AFNetworkReachabilityStatus status) {
    //创建局部__strong强引用，防止多线程情况下weakSelf被析构
     __strong __typeof(weakSelf)strongSelf = weakSelf;
    strongSelf.networkReachabilityStatus = status;
    if (strongSelf.networkReachabilityStatusBlock) {
         strongSelf.networkReachabilityStatusBlock(status);
    }
};

这里需要了解__weak和__block的一些概念，推荐一篇个人觉得写的比较好的文章__weak与__block区别。强烈推荐给对这两个概念不太清楚的同学们，这里就简单的总结下面两段：

__weak 本身是可以避免循环引用的问题的，但是其会导致外部对象释放了之后，block 内部也访问不到这个对象的问题，我们可以通过在 block 内部声明一个 __strong 的变量来指向 weakObj，使外部对象既能在 block 内部保持住，又能避免循环引用的问题

__block 本身无法避免循环引用的问题，但是我们可以通过在 block 内部手动把 blockObj 赋值为 nil 的方式来避免循环引用的问题。另外一点就是 __block 修饰的变量在 block 内外都是唯一的，要注意这个特性可能带来的隐患。

DSBlockTestDemo这个是block引起的内存泄漏及解决方法的demo。

NSTimer导致的内存泄露

NSTimer的生命周期问题，我们来看一下我们平时是怎么创建NSTimer的：

NSTimer * timer = [NSTimer scheduledTimerWithTimeInterval:1 target:self selector:@selector(printMessage) userInfo:nil repeats:YES];

Timer 添加到 Runloop 的时候，会被 Runloop 强引用。
Timer 又会有一个对 Target 的强引用。
所以说如果不对Timer进行释放，Timer的targer(self)也一直不会被释放。
有时候我们我们对某个Timer的targer设置了nil。但没设置[timer invalidate]。
其实这个对象还是没被释放的。timer对应的执行方法也一直会在线程中执行。容易造成内存泄露。

那么问题来了：如果我就是想让这个 NSTimer 一直输出，直到 DemoViewController 销毁了才停止，我该如何让它停止呢？

这是大神写的整个思路及解决办法的文章

这是解决方法的NSTimer的封装这个HWWeakTimer不需要你手动的去设置[timer invalidate]，即使你忘记了也不会再发生内存泄露问题了。

如何监测内存泄漏

那我们如何快速的来找出内存泄露呢？以前我们可能会使用Instruments来监测，但是我们会发现使用Instruments特别繁琐，而且不一定能定位到内存泄露。

所以这里伟大的Facebook工程师们开源了一些自动化工具来解决监测内存泄露问题：FBRetainCycleDetector、FBAllocationTracker、FBMemoryProfiler。
原文介绍：Automatic memory leak detection on iOS
中文翻译：在iOS上自动检测内存泄露

参考

__weak与__block区别
黑幕背后的Autorelease