轉自 http://www.cocoachina.com/ios/20160706/16951.html
iOS內存泄漏自動檢測工具PLeakSniffer
背景
前些天讀到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地址：https://github.com/music4kid/PLeakSniffer
