** WeRead團(tuán)隊(duì)博客
原文 http://wereadteam.github.io/2016/02/22/MLeaksFinder/

平常我們都會(huì)用 Instrument 的 Leaks / Allocations 或其他一些開(kāi)源庫(kù)進(jìn)行內(nèi)存泄露的排查，但它們都存在各種問(wèn)題和不便，我們逐個(gè)來(lái)看這些工具的使用和存在的問(wèn)題。

Leaks

先看看 Leaks，從蘋(píng)果的開(kāi)發(fā)者文檔里可以看到，一個(gè) app 的內(nèi)存分三類(lèi)：

1.Leaked memory: Memory unreferenced by your application that cannot be used again or freed (also detectable by using the Leaks instrument).
2.Abandoned memory: Memory still referenced by your application that has no useful purpose.
3.Cached memory: Memory still referenced by your application that might be used again for better performance.

其中 Leaked memory 和 Abandoned memory 都屬于應(yīng)該釋放而沒(méi)釋放的內(nèi)存，都是內(nèi)存泄露，而 Leaks 工具只負(fù)責(zé)檢測(cè) Leaked memory，而不管 Abandoned memory。在 MRC 時(shí)代 Leaked memory 很常見(jiàn)，因?yàn)楹苋菀淄苏{(diào)用 release，但在 ARC 時(shí)代更常見(jiàn)的內(nèi)存泄露是循環(huán)引用導(dǎo)致的 Abandoned memory，Leaks 工具查不出這類(lèi)內(nèi)存泄露，應(yīng)用有限。

Allocations

對(duì)于 Abandoned memory，可以用 Instrument 的 Allocations 檢測(cè)出來(lái)。檢測(cè)方法是用 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è)最簡(jiǎn)單的例子：
我們可以不斷重復(fù) push 和 pop 同一個(gè) UIViewController，理論上來(lái)說(shuō)，push 之前跟 pop 之后，app 會(huì)回到相同的狀態(tài)。因此，在 push 過(guò)程中新分配的內(nèi)存，在 pop 之后應(yīng)該被 dealloc 掉，除了前幾次 push 可能有預(yù)熱數(shù)據(jù)和 cache 數(shù)據(jù)的情況。如果在數(shù)次 push 跟 pop 之后，內(nèi)存還不斷增長(zhǎng)，則有內(nèi)存泄露。因此，我們?cè)诿炕?push 之前跟 pop 之后，都 Mark Generation 一下，以此觀察內(nèi)存是不是無(wú)限制增長(zhǎng)。這個(gè)方法在 WWDC 的視頻里： Session 311 - Advanced Memory Analysis with Instruments ，以及蘋(píng)果的開(kāi)發(fā)者文檔： Finding Abandoned Memory 里有介紹。
用這種方法來(lái)發(fā)現(xiàn)內(nèi)存泄露還是很不方便的：
首先，你得打開(kāi) Allocations
其次，你得一個(gè)個(gè)場(chǎng)景去重復(fù)的操作
無(wú)法及時(shí)得知泄露，得專(zhuān)門(mén)做一遍上述操作，十分繁瑣

開(kāi)源庫(kù)

在 GitHub 上有一些內(nèi)存泄露檢測(cè)相關(guān)的項(xiàng)目，例如 HeapInspector-for-iOS 和 MSLeakHunter 。
HeapInspector-for-iOS 可以說(shuō)是 Allocations 的改進(jìn)。它通過(guò) hook 掉 alloc，dealloc，retain，release 等方法，來(lái)記錄對(duì)象的生命周期。具體的檢測(cè)內(nèi)存泄露的方法和原理，與 Instrument 的 Allocations 一致。然而它跟 Allocations 一樣，存在的問(wèn)題是，你需要一個(gè)個(gè)場(chǎng)景去重復(fù)的操作，還有檢測(cè)不及時(shí)。
MSLeakHunter 就簡(jiǎn)單得多，它只檢測(cè) UIViewController 和 UIView，通過(guò) hook 掉 UIViewController 的 -viewDidDisappear:
方法，并認(rèn)為 -viewDidDisappear:
后，UIViewController 將很快被釋放，如果 UIViewController 沒(méi)有被釋放，則打個(gè)建議日志。這種做法其實(shí)不是很好， -viewDidDisappear:
被調(diào)用可能是因?yàn)橛?push 進(jìn)來(lái)一個(gè)新的 ViewController，把當(dāng)前的 ViewController 擋住了，所以可能有很多錯(cuò)誤的建議，需要結(jié)合你實(shí)際的操作去具體地分析日志。

MLeaksFinder

MLeaksFinder 提供了內(nèi)存泄露檢測(cè)更好的解決方案。只需要引入 MLeaksFinder，就可以自動(dòng)在 App 運(yùn)行過(guò)程檢測(cè)到內(nèi)存泄露的對(duì)象并立即提醒，無(wú)需打開(kāi)額外的工具，也無(wú)需為了檢測(cè)內(nèi)存泄露而一個(gè)個(gè)場(chǎng)景去重復(fù)地操作。MLeaksFinder 目前能自動(dòng)檢測(cè) UIViewController 和 UIView 對(duì)象的內(nèi)存泄露，而且也可以擴(kuò)展以檢測(cè)其它類(lèi)型的對(duì)象。
MLeaksFinder 的使用很簡(jiǎn)單，參照 https://github.com/Zepo/MLeaksFinder ，基本上就是把 MLeaksFinder 目錄下的文件添加到你的項(xiàng)目中，就可以在運(yùn)行時(shí)（debug 模式下）幫助你檢測(cè)項(xiàng)目里的內(nèi)存泄露了，無(wú)需修改任何業(yè)務(wù)邏輯代碼，而且只在 debug 下開(kāi)啟，完全不影響你的 release 包。
當(dāng)發(fā)生內(nèi)存泄露時(shí)，MLeaksFinder 會(huì)中斷言，并準(zhǔn)確的告訴你哪個(gè)對(duì)象泄露了。這里設(shè)計(jì)為中斷言而不是打日志讓程序繼續(xù)跑，是因?yàn)楹芏嗳瞬粫?huì)去看日志，斷言則能強(qiáng)制開(kāi)發(fā)者注意到并去修改，而不是犯拖延癥。
中斷言時(shí)，控制臺(tái)會(huì)有如下提示，View-ViewController stack 從上往下看，該 stack 告訴你，MyTableViewController 的 UITableView 的 subview UITableViewWrapperView 的 subview MyTableViewCell 沒(méi)被釋放。而且，這里我們可以肯定的是 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)：
使用簡(jiǎn)單，不侵入業(yè)務(wù)邏輯代碼，不用打開(kāi) Instrument
不需要額外的操作，你只需開(kāi)發(fā)你的業(yè)務(wù)邏輯，在你運(yùn)行調(diào)試時(shí)就能幫你檢測(cè)
內(nèi)存泄露發(fā)現(xiàn)及時(shí)，更改完代碼后一運(yùn)行即能發(fā)現(xiàn)（這點(diǎn)很重要，你馬上就能意識(shí)到哪里寫(xiě)錯(cuò)了）
精準(zhǔn)，能準(zhǔn)確地告訴你哪個(gè)對(duì)象沒(méi)被釋放

原理

MLeaksFinder 一開(kāi)始從 UIViewController 入手。我們知道，當(dāng)一個(gè) UIViewController 被 pop 或 dismiss 后，該 UIViewController 包括它的 view，view 的 subviews 等等將很快被釋放（除非你把它設(shè)計(jì)成單例，或者持有它的強(qiáng)引用，但一般很少這樣做）。于是，我們只需在一個(gè) ViewController 被 pop 或 dismiss 一小段時(shí)間后，看看該 UIViewController，它的 view，view 的 subviews 等等是否還存在。
具體的方法是，為基類(lèi) NSObject 添加一個(gè)方法 -willDealloc
方法，該方法的作用是，先用一個(gè)弱指針指向 self，并在一小段時(shí)間(3秒)后，通過(guò)這個(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è)對(duì)象應(yīng)該要被釋放了，在釋放前調(diào)用這個(gè)方法，如果3秒后它被釋放成功，weakSelf 就指向 nil，不會(huì)調(diào)用到 -assertNotDealloc
方法，也就不會(huì)中斷言，如果它沒(méi)被釋放（泄露了）， -assertNotDealloc
就會(huì)被調(diào)用中斷言。這樣，當(dāng)一個(gè) UIViewController 被 pop 或 dismiss 時(shí)（我們認(rèn)為它應(yīng)該要被釋放了），我們遍歷該 UIViewController 上的所有 view，依次調(diào) -willDealloc
，若3秒后沒(méi)被釋放，就會(huì)中斷言。
在這里，有幾個(gè)問(wèn)題需要解決：

不入侵開(kāi)發(fā)代碼

這里使用了 AOP 技術(shù)，hook 掉 UIViewController 和 UINavigationController 的 pop 跟 dismiss 方法，關(guān)于如何 hook，請(qǐng)參考 Method Swizzling 。

遍歷相關(guān)對(duì)象

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

構(gòu)建堆棧信息

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

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

特殊情況

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

系統(tǒng)View

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

手動(dòng)擴(kuò)展

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

-(BOOL)willDealloc { 

 if (![super willDealloc]) {

   return NO;

 }

 MLCheck(self.viewModel);

 return YES;

}

這里的原理跟上面的是一樣的，宏 MLCheck() 做的事就是為傳進(jìn)來(lái)的對(duì)象建立 View-ViewController stack 信息，并對(duì)傳進(jìn)來(lái)的對(duì)象調(diào)用 -willDealloc
方法。

未來(lái)

MLeaksFinder 目前還在起步階段，它的內(nèi)存泄露檢測(cè)的想法是很簡(jiǎn)單，很直接的。雖然目前只能自動(dòng)地檢測(cè) UIViewController 和 UIView 相關(guān)的對(duì)象，然而在我們幾個(gè)大的項(xiàng)目中，已經(jīng)起到很大的作用，幫助我們發(fā)現(xiàn)很多歷史存在的內(nèi)存泄露，而且確保新提交的 UI 相關(guān)代碼不會(huì)引進(jìn)新的問(wèn)題。MLeaksFinder 會(huì)繼續(xù)探索覆蓋更廣的情況，提供更全面的檢測(cè)，包括網(wǎng)絡(luò)層，數(shù)據(jù)存儲(chǔ)層等等。