本文授權轉自MrPeak技術分享（公眾號：MrPeakTech）

新款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安裝後，通過以下代碼激活即可。

#if MY_DEBUG_ENV
[[PLeakSniffer sharedInstance] installLeakSniffer];
[[PLeakSniffer sharedInstance] addIgnoreList:@[@"MySingletonController"]];
#endif

addIgnoreList可以添加一些特殊的忽略名單，比如單例這種無法正確預測洩漏的對象。切記用Debug的宏將上述代碼包住，不要把這些檢測洩漏的代碼帶進線上環境。

如果檢測到可疑洩漏，PLeakSniffer會在控制台打印一條日志：

Controller洩漏：Detect Possible Controller Leak: %@

其他對象洩漏：Detect Possible Leak: %@

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