ARC下的内存泄漏
ARC全称叫 ARC(Automatic Reference Counting)。在编译期间，编译器会判断对象的使用情况，并适当的加上retain和release，使得对象的内存被合理的管理。所以，从本质上说ARC和MRC在本质上是一样的，都是通过引用计数的内存管理方式。ARC 的出现大大节省了程序员手动管理内存的时间成本，But，世上没有完美的事物，我们也不要把任何事想的那么美好，在 ARC 环境下如果不注意的话也会引起内存泄漏。
目前在项目中引入了MLeaksFinder,能比较清晰的找到内存泄漏的位置。
分析一下内存泄漏的主要原因
循环引用（Retain Cycle）
什么是引用循环（retain cycle）
假设我们有两个实例A和B，B是A的一个strong型的property，则B的引用计数是1，当A的需要释放的时候，A则会调用[B release]来释放B，B的引用计数则减为0，释放。
可如果这时候将B的一个strong型property指向A，则A与B互相为强引用，问题就来了。因为B强引用A，A的引用计数永远不会减为0，当A原本的强引用对象被释放以后，A和B成为了一个相互引用的孤岛，永远不会被释放了，这就会引起内存泄漏。
在上面的例子中，就是一种非常普遍的引用循环情况，加入如上代码的VC在dismiss或者pop以后，并不会执行dealloc方法，证明内存泄漏了。而引起泄漏的原因就是在作为self的property的block中，使用self指针导致self被block强引用，形成引用循环。
1、Delegate
我们在使用代理设计模式的时候，一定要注意将 delegate 变量声明为 weak 类型，像这样
@property (nonatomic, weak) id<xxxx> delegate;
如使用strong或别的类型修饰的话将会导致循环引用，导致dealloc()不会被调用。从而触发一些意想不到的后果。
2、Block
目前在项目中出现的内存泄漏大部分是因为block的问题。
在 ARC 下，当 block 获取到外部变量时，由于编译器无法预测获取到的变量何时会被突然释放，为了保证程序能够正确运行，让 block 持有获取到的变量，向系统声明：我要用它，你们千万别把它回收了！然而，也正因 block 持有了变量，容易导致变量和 block 的循环引用，造成内存泄露！
[_sortButton setButtonSpreadPreAction:^BOOL{
if (_resultItems.count == 0) {
[progressHUD showText:@"xxxx"];
return NO;
}
return YES;
}];
这个例子的问题就在于在使用 block 的过程中形成了循环引用：self 持有 sortButton；sortButton 持有 block；block 持有 self。三者形成循环引用，内存泄露。
GCD已经一些系统级的API并不会提示循环引用的警告，但通过测试发现，大部分系统提供block也是需要弱引用的__weak typeof(self) weakSelf = self;
项目中除了AFN的第三方组件在调用block时都是需要弱引用的，如MJRefresh。
3、NSTimer
NSTimer在VC释放前，一定要调用[timer invalidate]，不调用的后果就是NSTimer无法释放其target，如果target正好是self，则会导致引用循环。
这里要补充一点，引用循环不是只能有两个对象，三个四个更多都是可以的，甚至环数也不一定只有一个，所以要养成良好的代码习惯，在NSTimer停用前调用invalidate方法。
关于performSelector:afterDelay的问题
- (void)performSelector:(SEL)aSelector withObject:(id)anArgument afterDelay:(NSTimeInterval)delay
我们还是看看官方文档怎么说的。
This method sets up a timer to perform the aSelector message on the current thread’s run loop. The timer is configured to run in the default mode (NSDefaultRunLoopMode). When the timer fires, the thread attempts to dequeue the message from the run loop and perform the selector. It succeeds if the run loop is running and in the default mode; otherwise, the timer waits until the run loop is in the default mode.
大概意思是系统依靠一个timer来保证延时触发，但是只有在runloop在default mode的时候才会执行成功，否则selector会一直等待run loop切换到default mode。根据我们之前关于timer
的说法，在这里其实调用performSelector:afterDelay:同样会造成系统对target强引用，也即retain住。这样子，如果selector一直无法执行的话（比如runloop不是运行在default model下）,这样子同样会造成target一直无法被释放掉，发生内存泄露。怎么解决这个问题呢？其实很简单，我们在适当的时候取消掉该调用就行了，系统提供了接口:
+ (void)cancelPreviousPerformRequestsWithTarget:(id)aTarget
