iOS記憶體洩漏自動檢測工具PLeakSniffer

新款objective-C記憶體洩漏自動檢測工具PLeakSniffer，GitHub地址。

背景

前些天讀到WeRead團隊分享的一款記憶體洩漏檢測工具MLeaksFinder，恍惚想起早些時候自己也有過編寫這樣一個小工具的想法，不知道由於什麼原因把這事給忘記了。在仔細讀過MLeaksFinder原始碼，瞭解實現思路之後，發現和自己最初的想法並不相同，終於在上個週末戰勝拖延症將之前的想法付諸於程式碼，也就誕生了這款功能類似的記憶體洩漏檢測工具PLeakSniffer。建議讀者先詳細閱讀下MLeaksFinder這篇部落格。

為什麼要再造輪子

我在公司的專案裡實際試用了MLeaksFinder，還查處了2處洩漏?。根據MLeaksFinder程式碼檔案中日期推測，這個專案至少已開始半年有餘，並在微信讀書上得到了實踐驗證，在功能性和穩定性上都應該有不錯的表現。

在編寫完PLeakSniffer之後，查出了與MLeaksFinder相同的記憶體洩漏，思路迥異的程式碼抵達了相同的終點，寫程式碼的樂趣莫過於此。新的思路或許還能拋磚引玉，如果激發更多的創意，也算是對iOS開發社群的一點小貢獻。

MLeaksFinder現階段能查處UIViewController和UIView的洩漏，我早先的想法還能遞迴的查出UIViewController之下所有Property的洩漏，並在PLeakSniffer及公司專案中得到了初步的驗證，這算是對MLeaksFinder功能的一個小補充。

這類工具的意義

在我們討論這類工具的意義之前，我們先得明確一點：

如果不使用Instrument當中的Leak檢測工具，並沒有什麼輕易的100%精準的記憶體洩漏檢測方式。

但這類工具還是有其存在價值的，記憶體洩漏的危害不用贅述，如果有一款工具能在80%的場景下檢測出可能的記憶體洩漏，而且這種檢測並不會帶來任何副作用（不影響生產環境程式碼），為什麼不使用它呢。

大部分人都低估了他們寫程式碼時導致意外記憶體洩漏的可能性。Retain Cycle，Block強引用，NSTimer釋放不當，這些常見的錯誤還是很容易出現在我們的程式碼裡，Instrument每使用一次要費些精力，適合做定期的大排查。平常時候就更適合用MLeaksFinder，PLeakSniffer這類工具來做實時監控，提供免費建議。

PLeakSniffer實現思路

我們絕大部分時候都是在編寫UIViewController，UIViewController就像一個根節點，持有並管理著很多的子節點物件，這些子節點的生命週期都依賴於Controller，Controller釋放的時候，他們也隨之釋放。用一張圖簡單的描述他們的關係：

根據各個應用使用的設計模式不同（MVC，MVP，MVVM等），Controller所持有的Property也不相同。這裡我們使用MVP作為例子，Controller所包含的物件就包括各種View物件，和Presenter，Model物件。當然每個物件又有可能持有更多的子物件。

PLeakSniffer基於這樣一個假設：

如果Controller被釋放了，但其曾經持有過的子物件如果還存在，那麼這些子物件就是洩漏的可疑目標。

當然這個假設並不是一個100%適用的真理，不同工程師編寫程式碼的方式風格差別很大，有些會把某些UIViewController做成單例（個人覺得這不是個好主意。。），有些會把某些View快取起來（即使Controller已被釋放），還會有其他考慮不到的場景。但在80%以上的場景，我們在Controller結束生命週期之後會將其持有的資源一併釋放。這時候PLeakSniffer可以發揮用處，給你一些免費的洩漏建議。

那麼怎麼在Controller被釋放之後，知道其持有的物件沒有被釋放呢？

一個小技巧可以達成這個目標：子物件（比如view）建立一個對controller的weak引用，如果Controller被釋放，這個weak引用也隨之置為nil。那怎麼知道子物件沒有被釋放呢？用一個單例物件每個一小段時間發出一個ping通知去ping這個子物件，如果子物件還活著就會一個pong通知。所以結論就是：如果子物件的controller已不存在，但還能響應這個ping通知，那麼這個物件就是可疑的洩漏物件。完整的結構可以用下圖表示：

通知移除需要一個時機，這裡我們使用Associated Object機制給每一個子物件再生成一個Proxy物件，在Proxy物件的dealloc裡面移除通知。

當然什麼時候去判斷一個物件的生命週期開始，什麼時候判斷為結束，需要一個精挑細選的機制。View，Controller，Property各不相同。

PLeakSniffer採取保守的策略，通過Objective C的runtime機制，遞迴的將一個Controller所有強引用的property找出，並安裝proxy監聽Ping通知。在我的測試下，基本上能將property洩漏的場景找出。

PLeakSniffer的使用方式很簡答，通過Pod安裝後，通過以下程式碼啟用即可。

addIgnoreList可以新增一些特殊的忽略名單，比如單例這種無法正確預測洩漏的物件。切記用Debug的巨集將上述程式碼包住，不要把這些檢測洩漏的程式碼帶進線上環境。

如果檢測到可疑洩漏，PLeakSniffer會在控制檯列印一條日誌：

Controller洩漏：Detect Possible Controller Leak: %@

其他物件洩漏：Detect Possible Leak: %@

更多的細節請查閱程式碼：GitHub地址。

打賞支援我寫出更多好文章，謝謝！

打賞作者