轉(zhuǎn)載：http://wereadteam.github.io/2016/02/22/MLeaksFinder

背景
平常我們都會(huì)用 Instrument 的 Leaks / Allocations 或其他一些開源庫進(jìn)行內(nèi)存泄露的排查，但它們都存在各種問題和不便，我們逐個(gè)來看這些工具的使用和存在的問題。
Leaks
先看看 Leaks，從蘋果的開發(fā)者文檔里可以看到，一個(gè) app 的內(nèi)存分三類：
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 都屬于應(yīng)該釋放而沒釋放的內(nèi)存，都是內(nèi)存泄露，而 Leaks 工具只負(fù)責(zé)檢測 Leaked memory，而不管 Abandoned memory。在 MRC 時(shí)代 Leaked memory 很常見，因?yàn)楹苋菀淄苏{(diào)用 release，但在 ARC 時(shí)代更常見的內(nèi)存泄露是循環(huán)引用導(dǎo)致的 Abandoned memory，Leaks 工具查不出這類內(nèi)存泄露，應(yīng)用有限。
Allocations
對于 Abandoned memory，可以用 Instrument 的 Allocations 檢測出來。檢測方法是用 Mark Generation 的方式，當(dāng)你每次點(diǎn)擊 Mark Generation 時(shí)，Allocations 會(huì)生成當(dāng)前 App 的內(nèi)存快照，而且 Allocations 會(huì)記錄從上回內(nèi)存快照到這次內(nèi)存快照這個(gè)時(shí)間段內(nèi)，新分配的內(nèi)存信息。舉一個(gè)最簡單的例子：
我們可以不斷重復(fù) push 和 pop 同一個(gè) UIViewController，理論上來說，push 之前跟 pop 之后，app 會(huì)回到相同的狀態(tài)。因此，在 push 過程中新分配的內(nèi)存，在 pop 之后應(yīng)該被 dealloc 掉，除了前幾次 push 可能有預(yù)熱數(shù)據(jù)和 cache 數(shù)據(jù)的情況。如果在數(shù)次 push 跟 pop 之后，內(nèi)存還不斷增長，則有內(nèi)存泄露。因此，我們在每回 push 之前跟 pop 之后，都 Mark Generation 一下，以此觀察內(nèi)存是不是無限制增長。這個(gè)方法在 WWDC 的視頻里：Session 311 - Advanced Memory Analysis with Instruments，以及蘋果的開發(fā)者文檔：Finding Abandoned Memory 里有介紹。
用這種方法來發(fā)現(xiàn)內(nèi)存泄露還是很不方便的：
首先，你得打開 Allocations
其次，你得一個(gè)個(gè)場景去重復(fù)的操作
無法及時(shí)得知泄露，得專門做一遍上述操作，十分繁瑣

開源庫
在 GitHub 上有一些內(nèi)存泄露檢測相關(guān)的項(xiàng)目，例如 HeapInspector-for-iOS 和 MSLeakHunter。
HeapInspector-for-iOS 可以說是 Allocations 的改進(jìn)。它通過 hook 掉 alloc，dealloc，retain，release 等方法，來記錄對象的生命周期。具體的檢測內(nèi)存泄露的方法和原理，與 Instrument 的 Allocations 一致。然而它跟 Allocations 一樣，存在的問題是，你需要一個(gè)個(gè)場景去重復(fù)的操作，還有檢測不及時(shí)。
MSLeakHunter 就簡單得多，它只檢測 UIViewController 和 UIView，通過 hook 掉 UIViewController 的 -viewDidDisappear:
方法，并認(rèn)為 -viewDidDisappear:
后，UIViewController 將很快被釋放，如果 UIViewController 沒有被釋放，則打個(gè)建議日志。這種做法其實(shí)不是很好，-viewDidDisappear:
被調(diào)用可能是因?yàn)橛?push 進(jìn)來一個(gè)新的 ViewController，把當(dāng)前的 ViewController 擋住了，所以可能有很多錯(cuò)誤的建議，需要結(jié)合你實(shí)際的操作去具體地分析日志。
MLeaksFinder
MLeaksFinder 提供了內(nèi)存泄露檢測更好的解決方案。只需要引入 MLeaksFinder，就可以自動(dòng)在 App 運(yùn)行過程檢測到內(nèi)存泄露的對象并立即提醒，無需打開額外的工具，也無需為了檢測內(nèi)存泄露而一個(gè)個(gè)場景去重復(fù)地操作。MLeaksFinder 目前能自動(dòng)檢測 UIViewController 和 UIView 對象的內(nèi)存泄露，而且也可以擴(kuò)展以檢測其它類型的對象。
MLeaksFinder 的使用很簡單，參照 https://github.com/Zepo/MLeaksFinder，基本上就是把 MLeaksFinder 目錄下的文件添加到你的項(xiàng)目中，就可以在運(yùn)行時(shí)（debug 模式下）幫助你檢測項(xiàng)目里的內(nèi)存泄露了，無需修改任何業(yè)務(wù)邏輯代碼，而且只在 debug 下開啟，完全不影響你的 release 包。
當(dāng)發(fā)生內(nèi)存泄露時(shí)，MLeaksFinder 會(huì)中斷言，并準(zhǔn)確的告訴你哪個(gè)對象泄露了。這里設(shè)計(jì)為中斷言而不是打日志讓程序繼續(xù)跑，是因?yàn)楹芏嗳瞬粫?huì)去看日志，斷言則能強(qiáng)制開發(fā)者注意到并去修改，而不是犯拖延癥。
中斷言時(shí)，控制臺(tái)會(huì)有如下提示，View-ViewController stack 從上往下看，該 stack 告訴你，MyTableViewController 的 UITableView 的 subview UITableViewWrapperView 的 subview MyTableViewCell 沒被釋放。而且，這里我們可以肯定的是 MyTableViewController，UITableView，UITableViewWrapperView 這三個(gè)已經(jīng)成功釋放了。

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)點(diǎn)：
使用簡單，不侵入業(yè)務(wù)邏輯代碼，不用打開 Instrument
不需要額外的操作，你只需開發(fā)你的業(yè)務(wù)邏輯，在你運(yùn)行調(diào)試時(shí)就能幫你檢測
內(nèi)存泄露發(fā)現(xiàn)及時(shí)，更改完代碼后一運(yùn)行即能發(fā)現(xiàn)（這點(diǎn)很重要，你馬上就能意識(shí)到哪里寫錯(cuò)了）
精準(zhǔn)，能準(zhǔn)確地告訴你哪個(gè)對象沒被釋放

原理
MLeaksFinder 一開始從 UIViewController 入手。我們知道，當(dāng)一個(gè) UIViewController 被 pop 或 dismiss 后，該 UIViewController 包括它的 view，view 的 subviews 等等將很快被釋放（除非你把它設(shè)計(jì)成單例，或者持有它的強(qiáng)引用，但一般很少這樣做）。于是，我們只需在一個(gè) ViewController 被 pop 或 dismiss 一小段時(shí)間后，看看該 UIViewController，它的 view，view 的 subviews 等等是否還存在。
具體的方法是，為基類 NSObject 添加一個(gè)方法 -willDealloc
方法，該方法的作用是，先用一個(gè)弱指針指向 self，并在一小段時(shí)間(3秒)后，通過這個(gè)弱指針調(diào)用 -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, @“”);}

這樣，當(dāng)我們認(rèn)為某個(gè)對象應(yīng)該要被釋放了，在釋放前調(diào)用這個(gè)方法，如果3秒后它被釋放成功，weakSelf 就指向 nil，不會(huì)調(diào)用到 -assertNotDealloc
方法，也就不會(huì)中斷言，如果它沒被釋放（泄露了），-assertNotDealloc
就會(huì)被調(diào)用中斷言。這樣，當(dāng)一個(gè) UIViewController 被 pop 或 dismiss 時(shí)（我們認(rèn)為它應(yīng)該要被釋放了），我們遍歷該 UIViewController 上的所有 view，依次調(diào) -willDealloc
，若3秒后沒被釋放，就會(huì)中斷言。
在這里，有幾個(gè)問題需要解決：
不入侵開發(fā)代碼
這里使用了 AOP 技術(shù)，hook 掉 UIViewController 和 UINavigationController 的 pop 跟 dismiss 方法，關(guān)于如何 hook，請參考 Method Swizzling。

遍歷相關(guān)對象
在實(shí)際項(xiàng)目中，我們發(fā)現(xiàn)有時(shí)候一個(gè) UIViewController 被釋放了，但它的 view 沒被釋放，或者一個(gè) UIView 被釋放了，但它的某個(gè) subview 沒被釋放。這種內(nèi)存泄露的情況很常見，因此，我們有必要遍歷基于 UIViewController 的整棵 View-ViewController 樹。我們通過 UIViewController 的 presentedViewController 和 view 屬性，UIView 的 subviews 屬性等遞歸遍歷。對于某些 ViewController，如 UINavigationController，UISplitViewController 等，我們還需要遍歷 viewControllers 屬性。

構(gòu)建堆棧信息
需要構(gòu)建 View-ViewController stack 信息以告訴開發(fā)者是哪個(gè)對象沒被釋放。在遞歸遍歷 View-ViewController 樹時(shí)，子節(jié)點(diǎn)的 stack 信息由父節(jié)點(diǎn)的 stack 信息加上子結(jié)點(diǎn)信息即可。

例外機(jī)制
對于有些 ViewController，在被 pop 或 dismiss 后，不會(huì)被釋放（比如單例），因此需要提供機(jī)制讓開發(fā)者指定哪個(gè)對象不會(huì)被釋放，這里可以通過重載上面的 -willDealloc
方法，直接 return NO 即可。

特殊情況
對于某些特殊情況，釋放的時(shí)機(jī)不大一樣（比如系統(tǒng)手勢返回時(shí)，在劃到一半時(shí) hold 住，雖然已被 pop，但這時(shí)還不會(huì)被釋放，ViewController 要等到完全 disappear 后才釋放），需要做特殊處理，具體的特殊處理視具體情況而定。

系統(tǒng)View
某些系統(tǒng)的私有 View，不會(huì)被釋放（可能是系統(tǒng) bug 或者是系統(tǒng)出于某些原因故意這樣做的，這里就不去深究了），因此需要建立白名單

手動(dòng)擴(kuò)展
MLeaksFinder目前只檢測 ViewController 跟 View 對象。為此，MLeaksFinder 提供了一個(gè)手動(dòng)擴(kuò)展的機(jī)制，你可以從 UIViewController 跟 UIView 出發(fā)，去檢測其它類型的對象的內(nèi)存泄露。如下所示，我們可以檢測 UIViewController 底下的 View Model：

- (BOOL)willDealloc { 
if (![super willDealloc]) { 
      return NO; 
  } 

  MLCheck(self.viewModel);
 return YES;
}

這里的原理跟上面的是一樣的，宏 MLCheck() 做的事就是為傳進(jìn)來的對象建立 View-ViewController stack 信息，并對傳進(jìn)來的對象調(diào)用 -willDealloc
方法。
未來
MLeaksFinder 目前還在起步階段，它的內(nèi)存泄露檢測的想法是很簡單，很直接的。雖然目前只能自動(dòng)地檢測 UIViewController 和 UIView 相關(guān)的對象，然而在我們幾個(gè)大的項(xiàng)目中，已經(jīng)起到很大的作用，幫助我們發(fā)現(xiàn)很多歷史存在的內(nèi)存泄露，而且確保新提交的 UI 相關(guān)代碼不會(huì)引進(jìn)新的問題。MLeaksFinder 會(huì)繼續(xù)探索覆蓋更廣的情況，提供更全面的檢測，包括網(wǎng)絡(luò)層，數(shù)據(jù)存儲(chǔ)層等等。