轉載：http://wereadteam.github.io/2016/02/22/MLeaksFinder
背景
平常我們都會用 Instrument 的 Leaks / Allocations 或其他一些開源庫進行內存泄露的排查绣版，但它們都存在各種問題和不便，我們逐個來看這些工具的使用和存在的問題桩皿。
Leaks
先看看 Leaks纺阔，從蘋果的開發(fā)者文檔里可以看到蘑拯，一個 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 時代更常見的內存泄露是循環(huán)引用導致的 Abandoned memory墩剖，Leaks 工具查不出這類內存泄露猴凹，應用有限。
Allocations
對于 Abandoned memory岭皂，可以用 Instrument 的 Allocations 檢測出來郊霎。檢測方法是用 Mark Generation 的方式，當你每次點擊 Mark Generation 時爷绘，Allocations 會生成當前 App 的內存快照书劝，而且 Allocations 會記錄從上回內存快照到這次內存快照這個時間段內，新分配的內存信息土至。舉一個最簡單的例子：
我們可以不斷重復 push 和 pop 同一個 UIViewController购对，理論上來說，push 之前跟 pop 之后陶因，app 會回到相同的狀態(tài)骡苞。因此，在 push 過程中新分配的內存，在 pop 之后應該被 dealloc 掉解幽，除了前幾次 push 可能有預熱數(shù)據和 cache 數(shù)據的情況贴见。如果在數(shù)次 push 跟 pop 之后，內存還不斷增長躲株，則有內存泄露片部。因此，我們在每回 push 之前跟 pop 之后霜定，都 Mark Generation 一下档悠，以此觀察內存是不是無限制增長。這個方法在 WWDC 的視頻里：Session 311 - Advanced Memory Analysis with Instruments然爆，以及蘋果的開發(fā)者文檔：Finding Abandoned Memory 里有介紹站粟。
用這種方法來發(fā)現(xiàn)內存泄露還是很不方便的：
首先，你得打開 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 模式下）幫助你檢測項目里的內存泄露了迄埃，無需修改任何業(yè)務邏輯代碼，而且只在 debug 下開啟兑障，完全不影響你的 release 包侄非。
當發(fā)生內存泄露時，MLeaksFinder 會中斷言流译，并準確的告訴你哪個對象泄露了逞怨。這里設計為中斷言而不是打日志讓程序繼續(xù)跑，是因為很多人不會去看日志福澡，斷言則能強制開發(fā)者注意到并去修改叠赦，而不是犯拖延癥。
中斷言時革砸，控制臺會有如下提示除秀，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 具備以下優(yōu)點：
使用簡單，不侵入業(yè)務邏輯代碼扒怖，不用打開 Instrument
不需要額外的操作较锡，你只需開發(fā)你的業(yè)務邏輯，在你運行調試時就能幫你檢測
內存泄露發(fā)現(xiàn)及時盗痒，更改完代碼后一運行即能發(fā)現(xiàn)（這點很重要蚂蕴，你馬上就能意識到哪里寫錯了）
精準低散，能準確地告訴你哪個對象沒被釋放
原理
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秒后沒被釋放哺徊，就會中斷言。
在這里乾闰，有幾個問題需要解決：
不入侵開發(fā)代碼
這里使用了 AOP 技術落追，hook 掉 UIViewController 和 UINavigationController 的 pop 跟 dismiss 方法，關于如何 hook涯肩，請參考 Method Swizzling轿钠。
遍歷相關對象
在實際項目中巢钓，我們發(fā)現(xiàn)有時候一個 UIViewController 被釋放了，但它的 view 沒被釋放疗垛，或者一個 UIView 被釋放了症汹，但它的某個 subview 沒被釋放。這種內存泄露的情況很常見继谚，因此烈菌，我們有必要遍歷基于 UIViewController 的整棵 View-ViewController 樹。我們通過 UIViewController 的 presentedViewController 和 view 屬性花履，UIView 的 subviews 屬性等遞歸遍歷芽世。對于某些 ViewController，如 UINavigationController诡壁，UISplitViewController 等济瓢，我們還需要遍歷 viewControllers 屬性。
構建堆棧信息
需要構建 View-ViewController stack 信息以告訴開發(fā)者是哪個對象沒被釋放妹卿。在遞歸遍歷 View-ViewController 樹時旺矾，子節(jié)點的 stack 信息由父節(jié)點的 stack 信息加上子結點信息即可。
例外機制
對于有些 ViewController夺克，在被 pop 或 dismiss 后箕宙，不會被釋放（比如單例），因此需要提供機制讓開發(fā)者指定哪個對象不會被釋放铺纽，這里可以通過重載上面的 -willDealloc
方法柬帕，直接 return NO 即可。
特殊情況
對于某些特殊情況狡门，釋放的時機不大一樣（比如系統(tǒng)手勢返回時陷寝，在劃到一半時 hold 住，雖然已被 pop其馏，但這時還不會被釋放凤跑，ViewController 要等到完全 disappear 后才釋放），需要做特殊處理叛复，具體的特殊處理視具體情況而定仔引。
系統(tǒng)View
某些系統(tǒng)的私有 View，不會被釋放（可能是系統(tǒng) bug 或者是系統(tǒng)出于某些原因故意這樣做的褐奥，這里就不去深究了）咖耘，因此需要建立白名單
手動擴展
MLeaksFinder目前只檢測 ViewController 跟 View 對象。為此抖僵，MLeaksFinder 提供了一個手動擴展的機制，你可以從 UIViewController 跟 UIView 出發(fā)缘揪，去檢測其它類型的對象的內存泄露耍群。如下所示义桂，我們可以檢測 UIViewController 底下的 View Model：
- (BOOL)willDealloc {
if (![super willDealloc]) {
return NO;
}
MLCheck(self.viewModel);
return YES;
}
這里的原理跟上面的是一樣的，宏 MLCheck() 做的事就是為傳進來的對象建立 View-ViewController stack 信息蹈垢，并對傳進來的對象調用 -willDealloc
方法慷吊。
未來
MLeaksFinder 目前還在起步階段，它的內存泄露檢測的想法是很簡單曹抬，很直接的溉瓶。雖然目前只能自動地檢測 UIViewController 和 UIView 相關的對象，然而在我們幾個大的項目中谤民，已經起到很大的作用堰酿，幫助我們發(fā)現(xiàn)很多歷史存在的內存泄露，而且確保新提交的 UI 相關代碼不會引進新的問題张足。MLeaksFinder 會繼續(xù)探索覆蓋更廣的情況触创，提供更全面的檢測，包括網絡層为牍，數(shù)據存儲層等等哼绑。
