##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
複製程式碼