背景

平常我們都會用 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 的視訊裡：

用這種方法來發現記憶體洩露還是很不方便的：

• 首先，你得開啟 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 這三個已經成功釋放了。

• 1 2 3 4 5 6 7 8

  *** 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 主要作用是直接中斷言

• 這樣，當我們認為某個物件應該要被釋放了，在釋放前呼叫這個方法，如果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：

• 

這裡的原理跟上面的是一樣的，巨集 MLCheck() 做的事就是為傳進來的物件建立 View-ViewController stack 資訊，並對傳進來的物件呼叫 -willDealloc 方法。

未來

MLeaksFinder 目前還在起步階段，它的記憶體洩露檢測的想法是很簡單，很直接的。雖然目前只能自動地檢測 UIViewController 和 UIView 相關的物件，然而在我們幾個大的專案中，已經起到很大的作用，幫助我們發現很多歷史存在的記憶體洩露，而且確保新提交的 UI 相關程式碼不會引進新的問題。MLeaksFinder 會繼續探索覆蓋更廣的情況，提供更全面的檢測，包括網路層，資料儲存層等等。