iOS可能存在的内存泄露：

• block 循环引用。当一个对象有一个block属性，而block属性又引用这个对象本身那么要造成循环引用。这个时候就用___weak声明下对象，用对象的弱引用指针。
• 头文件相互包含。那么先在.h文件用前向引用声明，@class(类名);然后在.m文件导入#import " AHMessageCell"（类头文件）
• 移除通知 [[NSNotificationCenter defaultCenter]removeObserver:self];、
• 移除NSTimer

  [_timer invalidate];
    _timer = nil;

• 移除观察者

//添加观察者
    [self addObserver:<#(nonnull NSObject *)#> forKeyPath:<#(nonnull NSString *)#> options:<#(NSKeyValueObservingOptions)#> context:<#(nullable void *)#>]
//移除观察者
    [self removeObserver:<#(nonnull NSObject *)#> forKeyPath:<#(nonnull NSString *)#>];

** timer，观察者，通知的移除。一般的开发者都是放到dealloc中，但是这样不能保证一定能够移除成功。可以更加实际情况移除，可以在viewWillAppear中添加，viewWillDisappear中移除，也可以强制移除。**

iOS内存泄露测试：可以用xcode自带instrument工具,如：leaks、Analyze、allocation，也可以用第三方工具。

一： leaks

打开Xcode7自带的Instruments

打开Instruments

按上面操作，build成功后跳出Instruments工具，选择Leaks选项

选择之后界面如下图:

打开leaks

到这里之后,我们前期的准备工作做完啦，下面开始正式的测试!

• 1.选中Xcode先把程序（command + R）运行起来

• 2.再选中Xcode，按快捷键（command + control + i）运行起来,此时Leaks已经跑起来了

• 3.由于Leaks是动态监测，所以我们需要手动操作APP,一边操作，一边观察Leaks的变化，当出现红色叉时，就监测到了内存泄露，点击右上角的第二个，进行暂停检测(也可继续检测，当多个时暂停，一次处理了多个).如图所示:

• 4.下面就是定位修改了,此时选中有红色柱子的Leaks，下面有个"田"字方格，点开，选中Call Tree显示如下图界面

找到内存泄露位置

• 5.下面就是最关键的一步，在这个界面的右下角有若干选框，选中Invert Call Tree 和Hide System Libraries,（红圈范围内）显示如下：

监测回调函数

到这里就算基本完成啦，这里显示的就是内存泄露代码部分，那么现在还差一步：定位!

• 6.选中显示的若干条中的一条，双击，会自动跳到内存泄露代码处，如图所示
  

  
  
  查看回调函数

• 7.找到了内存泄露的地方，那么我们就可以修改即可。

二：Analyze—静态分析

顾名思义，静态分析不需要运行程序，就能检查到存在内存泄露的地方。

• 使用方法：打开Xcode，command + shift + B；或者Xcode - Product - Analyze；
• 常见的三种泄露情形：
  （1）创建了一个对象，但是并没有使用。Xcode提示信息： Value Stored to 'number' is never read 。翻译一下：存储在'number'里的值从未被读取过。
  （2）创建了一个（指针可变的）对象，且初始化了，但是初始化的值一直没读取过。Xcode提示信息： Value Stored to 'str' during its initialization is never read
  （3）调用了让某个对象引用计数加1的函数，但没有调用相应让其引用计数减1的函数。Xcode提示信息： Potential leak of an object stored into 'subImageRef' 。 翻译一下：subImageRef对象的内存单元有潜在的泄露风险。
• 贴上Demo代码：

/**
 * 情 形 一：创建了一个对象，但是并没有使用。
 * 提示信息：Value Stored to 'number' is never read
 * 翻译一下：存储在'number'里的值从未被读取过，
 */
- (void)leakOne {
    NSString *str1 = [NSString string];
    NSNumber *number;
    number = @(str1.length);
    /*
     说我们没有读取过它，那就读取一下，比如打开下面这句代码，对它发送class消息，就不再会有这个提示了。
     当然最好的方法还是将有关number的代码都删掉，因为，你只对number赋值，又不使用，那干嘛创建出来呢。
     这是一个比较常见和典型的错误，也很容易检查出来
     */
    // [number class];
}

/**
 * 情 形 二：创建了一个（指针可变的）对象，且初始化了，但是初始化的值一直没读取过。
 * 提示信息：Value Stored to 'str' during its initialization is never read
 */
- (void)leakTwo {
    NSString *str = [NSString string]; // 创建并初始化str，此时已经有一个内存单元保存str初始化的值
    // NSString *str; // 这样就内存不泄露，因为str是可变的，只需要先声明就行。
    // printf("str前 = %p\n",str);
    str = @"ceshi";             // str被改变了，指向了"ceshi"所在的地址，指针改变了，但之前保存初始化值的内存空间还未释放，保存str初始化值的内存单元泄露了。
    // printf("str后 = %p\n",str); // 指针改变了
    [str class];
    
    // 再举两个例子，同理
    
    NSArray *arr = [NSArray array];
    // printf("arr前 = %p\n",arr);
    // NSArray *arr;            // 这样就内存不泄露
    arr = @[@"1",@"2"];
    // printf("arr后 = %p\n",arr); // 指针改变了
    [arr class];
    
    CGRect rect = self.view.frame;
    // CGRect rect = CGRectZero; // 这样就内存不泄露
    rect = CGRectMake(0, 0, 0, 0);
    NSLog(@"rect = %@",NSStringFromCGRect(rect));
}

/**
 * 情 形 三：调用了让某个对象引用计数加1的函数，但没有调用相应让其引用计数减1的函数。
 * 提示信息：Potential leak of an object stored into 'subImageRef'
 * 翻译一下：subImageRef对象的内存单元有潜在的泄露风险
 */
- (void)leakThree {
    CGRect rect = CGRectMake(0, 0, 50, 50);
    UIImage *image;
    CGImageRef subImageRef = CGImageCreateWithImageInRect(image.CGImage, rect); // subImageRef 引用计数 + 1;
    
    UIImage* smallImage = [UIImage imageWithCGImage:subImageRef];
    
    // 应该调用对应的函数，让subImageRef的引用计数减1,就不会泄露了
    // CGImageRelease(subImageRef);
    
    [smallImage class];
    UIGraphicsEndImageContext();
}

监测结果：

可能存在内存泄露的地方

三：allocation使用

这个时候我们通过Allocation可以进行内存分析，将Xcode切换为Release状态，通过Product→Profile（Cmd+i）找到Allocations:

代开allocation

• 1.红色的按钮是表示停止和启动应用程序，不要理解成了暂停,Objective-C所有的对象都是在堆上分配的，记得勾选一下All Heap Allocations:
  

  开始监测

• 2.点击All Heap Allocation，勾选Call Tree，同时不查看系统的函数库:
  

  
  
  监测回调函数

• 3.具体方法占用的内存，可以逐级点开，效果如下:
  

  
  
  内存占用

以上是常规的Allocations使用，关于第二张图的有框中的几个选项可以解释一下:
Separate by Thread: 每个线程应该分开考虑，考虑到应用程序中GCD的存在；
Invert Call Tree: 从上倒下跟踪堆栈,这意味着你看到的表中的方法,将已从第0帧开始取样,利用栈的先进后出的特性，我们可以在栈顶看到最近调用的函数；
Hide System Libraries: 勾选此项会显示app的代码,这是非常有用的；
Flatten Recursion: 递归函数, 每个堆栈跟踪一个条目；

左侧有几个比较有用的选项：
All Objects Created
Created & Still Living
Created & Destroyed

内存监测

• 4.Allocation 分析技巧

通过以上方法可以对应用的整体内存使用情况有所了解，但内存不合理使用导致的内存警告往往是部分代码或视图导致的，我们往往要关注于某段时间或操作过程中内存的分配和使用情况，Allocation提供了这种功能。
比如在进入一个视图前或操作前，我们在Allocation面板左侧点击Mark Generation，这时候会产生Generation A节点，显示内存当前的情况：

比较测出内存泄露点

我们可以在进入视图后再点一次Mark Generation，在视图退出后再点一次Mark，这样三次产生的 Generation分别记录了进入前、进入后、关闭后，再最后一个Generation应该内存被合理释放，否则就代表了在这个视图或操作中有泄漏或不合理的地方。
以上只是Allocation的基本运用，设计出一套使用Allocation来合理测试的方案是比较复杂的，后续慢慢介绍。

四：MLeaksFinder

MLeaksFinder 提供了内存泄露检测更好的解决方案。只需要引入 MLeaksFinder pod 'MLeaksFinder'，就可以自动在 App 运行过程检测到内存泄露的对象并立即提醒，无需打开额外的工具，也无需为了检测内存泄露而一个个场景去重复地操作。MLeaksFinder 目前能自动检测 UIViewController 和 UIView 对象的内存泄露，而且也可以扩展以检测其它类型的对象。
MLeaksFinder 的使用很简单，参照 https://github.com/Zepo/MLeaksFinder，基本上就是把 MLeaksFinder 目录下的文件添加到你的项目中，就可以在运行时（debug 模式下）帮助你检测项目里的内存泄露了，无需修改任何业务逻辑代码，而且只在 debug 下开启，完全不影响你的 release 包。
当发生内存泄露时，MLeaksFinder 会中断言，并准确的告诉你哪个对象泄露了。这里设计为中断言而不是打日志让程序继续跑，是因为很多人不会去看日志，断言则能强制开发者注意到并去修改，而不是犯拖延症。
中断言时，控制台会有如下提示，View-ViewController stack 从上往下看，该 stack 告诉你，MyTableViewController 的 UITableView 的 subview UITableViewWrapperView 的 subview MyTableViewCell 没被释放。而且，这里我们可以肯定的是 MyTableViewController，UITableView，UITableViewWrapperView 这三个已经成功释放了。
*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Possibly Memory Leak.In case that MyTableViewCell should not be dealloced, override -willDealloc in MyTableViewCell by returning NO.View-ViewController stack: ( MyTableViewController, UITableView, UITableViewWrapperView, MyTableViewCell)'

从 MLeaksFinder 的使用方法可以看出，MLeaksFinder 具备以下优点：
使用简单，不侵入业务逻辑代码，不用打开 Instrument
不需要额外的操作，你只需开发你的业务逻辑，在你运行调试时就能帮你检测
内存泄露发现及时，更改完代码后一运行即能发现（这点很重要，你马上就能意识到哪里写错了）
精准，能准确地告诉你哪个对象没被释放

原理(http://wereadteam.github.io/2016/02/22/MLeaksFinder/?from=singlemessage&isappinstalled=0#u539F_u7406)
MLeaksFinder 一开始从 UIViewController 入手。我们知道，当一个 UIViewController 被 pop 或 dismiss 后，该 UIViewController 包括它的 view，view 的 subviews 等等将很快被释放（除非你把它设计成单例，或者持有它的强引用，但一般很少这样做）。于是，我们只需在一个 ViewController 被 pop 或 dismiss 一小段时间后，看看该 UIViewController，它的 view，view 的 subviews 等等是否还存在。
具体的方法是，为基类 NSObject 添加一个方法 -willDealloc
方法，该方法的作用是，先用一个弱指针指向 self，并在一小段时间(3秒)后，通过这个弱指针调用 -assertNotDealloc，而 -assertNotDealloc 主要作用是直接中断言。

- (BOOL)willDealloc { __weak id weakSelf = self; dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(3 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{ [weakSelf assertNotDealloc]; }); return YES;}- (void)assertNotDealloc { NSAssert(NO, @“”);}

这样，当我们认为某个对象应该要被释放了，在释放前调用这个方法，如果3秒后它被释放成功，weakSelf 就指向 nil，不会调用到 -assertNotDealloc
方法，也就不会中断言，如果它没被释放（泄露了），-assertNotDealloc
就会被调用中断言。这样，当一个 UIViewController 被 pop 或 dismiss 时（我们认为它应该要被释放了），我们遍历该 UIViewController 上的所有 view，依次调 -willDealloc，若3秒后没被释放，就会中断言。

在这里，有几个问题需要解决：
不入侵开发代码
这里使用了 AOP 技术，hook 掉 UIViewController 和 UINavigationController 的 pop 跟 dismiss 方法，关于如何 hook，请参考 Method Swizzling。

• 遍历相关对象
  在实际项目中，我们发现有时候一个 UIViewController 被释放了，但它的 view 没被释放，或者一个 UIView 被释放了，但它的某个 subview 没被释放。这种内存泄露的情况很常见，因此，我们有必要遍历基于 UIViewController 的整棵 View-ViewController 树。我们通过 UIViewController 的 presentedViewController 和 view 属性，UIView 的 subviews 属性等递归遍历。对于某些 ViewController，如 UINavigationController，UISplitViewController 等，我们还需要遍历 viewControllers 属性。

• 构建堆栈信息
  需要构建 View-ViewController stack 信息以告诉开发者是哪个对象没被释放。在递归遍历 View-ViewController 树时，子节点的 stack 信息由父节点的 stack 信息加上子结点信息即可。

• 例外机制
  对于有些 ViewController，在被 pop 或 dismiss 后，不会被释放（比如单例），因此需要提供机制让开发者指定哪个对象不会被释放，这里可以通过重载上面的 -willDealloc
  方法，直接 return NO 即可。

• 特殊情况
  对于某些特殊情况，释放的时机不大一样（比如系统手势返回时，在划到一半时 hold 住，虽然已被 pop，但这时还不会被释放，ViewController 要等到完全 disappear 后才释放），需要做特殊处理，具体的特殊处理视具体情况而定。

• 系统View
  某些系统的私有 View，不会被释放（可能是系统 bug 或者是系统出于某些原因故意这样做的，这里就不去深究了），因此需要建立白名单

• 手动扩展
  MLeaksFinder目前只检测 ViewController 跟 View 对象。为此，MLeaksFinder 提供了一个手动扩展的机制，你可以从 UIViewController 跟 UIView 出发，去检测其它类型的对象的内存泄露。如下所示，我们可以检测 UIViewController 底下的 View、Model：

- (BOOL)willDealloc { if (![super willDealloc]) { return NO; } MLCheck(self.viewModel); return YES;}

这里的原理跟上面的是一样的，宏 MLCheck() 做的事就是为传进来的对象建立 View-ViewController stack 信息，并对传进来的对象调用 -willDealloc
方法。

五：faceBook提供的内存泄露自动化测试：

FBRetainCycleDetector、FBAllocationTracker、FBMemoryProfiler。

让这工具真正闪光的是，在工程师内部构建的时候，它会连续的、自动的运行。
客户端部分自动化是简单的。我们在定时器上运行循环引用检测器，定期扫描内存去寻找循环引用，虽然这不是完全没有问题。当我们第一次运行分析器的时候，我们意识到它不足以很快的扫描整个内存空间。当它开始检测的时候，我们需要给它提供一组候选对象。
为了更有效的解决这个问题，我们开发了FBAllocationTracker。这个工具会主动跟踪NSObject
子类的创建和释放。它可以以一个很小的性能开销来获取任何类的任何实例。
对于客户端的自动化，只要在NSTimer
上使用FBRetainCycleDetector，再用FBAllocationTracker来抓取实例来配合跟踪就行。
现在，让我们来仔细看看后台会发生什么。
循环引用可以包含任何数量的对象。一个坏的连接会导致很多环的时候，这就复杂了。

所以我们需要给循环引用定义簇组(clusters)，鉴于这些启发，我们写了个算法来找到这些问题。
在给定的时间收集所有的环。
对于每一个环，提取Facebook特定的类名。
对于每一个环，找到包含在环内的被报告的最小的环。
依据上面的最小环，将环添加到组中。
只报告最小环。

最后一部分是找出谁第一时间偶然引入了循环引用。我们可以通过环中的”git/hg责任”的部分代码来猜测最近的变化所导致的问题。最后一个接触这个代码的人将会收到修复代码的任务。
整个系统如下:

生成(Generations)
FBMemoryProfiler的一个很伟大的特性是“生成追踪(generation tracking)”，类似于苹果的Instruments的生成追踪。生成只是简单的在两次标记之间拍摄所有仍然活着的对象的快照。
使用FBMemoryProfiler的界面,我们可以标记生成，例如，分配三个对象。然后我们标记另一个生成，之后继续分配对象。第一个生成包含我们一开始的三个对象。如果任意一个对象被释放了，它会从我们第二个生成中移除。