轉載：http://wereadteam.github.io/2016/02/22/MLeaksFinder
背景
平常我們都會用 Instrument 的 Leaks / Allocations 或其他一些開源庫進行內存泄露的排查，但它們都存在各種問題和不便，我們逐個來看這些工具的使用和存在的問題。
Leaks
先看看 Leaks，從蘋果的開發者文檔里可以看到，一個 app 的內存分三類：
Leaked memory: Memory unreferenced by your application that cannot be used again or freed (also detectable by using the Leaks instrument).
Abandoned memory: Memory still referenced by your application that has no useful purpose.
Cached memory: Memory still referenced by your application that might be used again for better performance.
其中 Leaked memory 和 Abandoned memory 都屬于應該釋放而沒釋放的內存，都是內存泄露，而 Leaks 工具只負責檢測 Leaked memory，而不管 Abandoned memory。在 MRC 時代 Leaked memory 很常見，因為很容易忘了調用 release，但在 ARC 時代更常見的內存泄露是循環引用導致的 Abandoned memory，Leaks 工具查不出這類內存泄露，應用有限。
Allocations
對于 Abandoned memory，可以用 Instrument 的 Allocations 檢測出來。檢測方法是用 Mark Generation 的方式，當你每次點擊 Mark Generation 時，Allocations 會生成當前 App 的內存快照，而且 Allocations 會記錄從上回內存快照到這次內存快照這個時間段內，新分配的內存信息。舉一個最簡單的例子：
我們可以不斷重復 push 和 pop 同一個 UIViewController，理論上來說，push 之前跟 pop 之后，app 會回到相同的狀態。因此，在 push 過程中新分配的內存，在 pop 之后應該被 dealloc 掉，除了前幾次 push 可能有預熱數據和 cache 數據的情況。如果在數次 push 跟 pop 之后，內存還不斷增長，則有內存泄露。因此，我們在每回 push 之前跟 pop 之后，都 Mark Generation 一下，以此觀察內存是不是無限制增長。這個方法在 WWDC 的視頻里：Session 311 - Advanced Memory Analysis with Instruments，以及蘋果的開發者文檔：Finding Abandoned Memory 里有介紹。
用這種方法來發現內存泄露還是很不方便的：
首先，你得打開 Allocations
其次，你得一個個場景去重復的操作
無法及時得知泄露，得專門做一遍上述操作，十分繁瑣
開源庫
在 GitHub 上有一些內存泄露檢測相關的項目，例如 HeapInspector-for-iOS 和 MSLeakHunter。
HeapInspector-for-iOS 可以說是 Allocations 的改進。它通過 hook 掉 alloc，dealloc，retain，release 等方法，來記錄對象的生命周期。具體的檢測內存泄露的方法和原理，與 Instrument 的 Allocations 一致。然而它跟 Allocations 一樣，存在的問題是，你需要一個個場景去重復的操作，還有檢測不及時。
MSLeakHunter 就簡單得多，它只檢測 UIViewController 和 UIView，通過 hook 掉 UIViewController 的 -viewDidDisappear:
方法，并認為 -viewDidDisappear:
后，UIViewController 將很快被釋放，如果 UIViewController 沒有被釋放，則打個建議日志。這種做法其實不是很好，-viewDidDisappear:
被調用可能是因為又 push 進來一個新的 ViewController，把當前的 ViewController 擋住了，所以可能有很多錯誤的建議，需要結合你實際的操作去具體地分析日志。
MLeaksFinder
MLeaksFinder 提供了內存泄露檢測更好的解決方案。只需要引入 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
不需要額外的操作，你只需開發你的業務邏輯，在你運行調試時就能幫你檢測
內存泄露發現及時，更改完代碼后一運行即能發現（這點很重要，你馬上就能意識到哪里寫錯了）
精準，能準確地告訴你哪個對象沒被釋放
原理
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
方法。
未來
MLeaksFinder 目前還在起步階段，它的內存泄露檢測的想法是很簡單，很直接的。雖然目前只能自動地檢測 UIViewController 和 UIView 相關的對象，然而在我們幾個大的項目中，已經起到很大的作用，幫助我們發現很多歷史存在的內存泄露，而且確保新提交的 UI 相關代碼不會引進新的問題。MLeaksFinder 會繼續探索覆蓋更廣的情況，提供更全面的檢測，包括網絡層，數據存儲層等等。
