新款objective-C內存泄漏自動檢測工具PLeakSniffer遥赚，GitHub地址蚯嫌。
背景
前些天讀到WeRead團隊分享的一款內存泄漏檢測工具MLeaksFinder胁后，恍惚想起早些時候自己也有過編寫這樣一個小工具的想法，不知道由于什么原因把這事給忘記了详恼。在仔細讀過MLeaksFinder源碼默刚，了解實現思路之后，發(fā)現和自己最初的想法并不相同芭毙，終于在上個周末戰(zhàn)勝拖延癥將之前的想法付諸于代碼筋蓖，也就誕生了這款功能類似的內存泄漏檢測工具PLeakSniffer。建議讀者先詳細閱讀下MLeaksFinder這篇博客退敦。
為什么要再造輪子
我在公司的項目里實際試用了MLeaksFinder粘咖，還查處了2處泄漏??。根據MLeaksFinder代碼文件中日期推測侈百，這個項目至少已開始半年有余瓮下，并在微信讀書上得到了實踐驗證，在功能性和穩(wěn)定性上都應該有不錯的表現钝域。
在編寫完PLeakSniffer之后讽坏，查出了與MLeaksFinder相同的內存泄漏，思路迥異的代碼抵達了相同的終點例证，寫代碼的樂趣莫過于此路呜。新的思路或許還能拋磚引玉，如果激發(fā)更多的創(chuàng)意战虏，也算是對iOS開發(fā)社區(qū)的一點小貢獻拣宰。
MLeaksFinder現階段能查處UIViewController和UIView的泄漏党涕，我早先的想法還能遞歸的查出UIViewController之下所有Property的泄漏烦感，并在PLeakSniffer及公司項目中得到了初步的驗證，這算是對MLeaksFinder功能的一個小補充膛堤。
這類工具的意義
在我們討論這類工具的意義之前手趣，我們先得明確一點：
如果不使用Instrument當中的Leak檢測工具，并沒有什么輕易的100%精準的內存泄漏檢測方式。
但這類工具還是有其存在價值的绿渣，內存泄漏的危害不用贅述朝群，如果有一款工具能在80%的場景下檢測出可能的內存泄漏，而且這種檢測并不會帶來任何副作用（不影響生產環(huán)境代碼）中符，為什么不使用它呢姜胖。
大部分人都低估了他們寫代碼時導致意外內存泄漏的可能性。Retain Cycle淀散，Block強引用右莱，NSTimer釋放不當，這些常見的錯誤還是很容易出現在我們的代碼里档插，Instrument每使用一次要費些精力慢蜓，適合做定期的大排查。平常時候就更適合用MLeaksFinder郭膛，PLeakSniffer這類工具來做實時監(jiān)控晨抡，提供免費建議。
PLeakSniffer實現思路
我們絕大部分時候都是在編寫UIViewController则剃，UIViewController就像一個根節(jié)點耘柱，持有并管理著很多的子節(jié)點對象，這些子節(jié)點的生命周期都依賴于Controller棍现，Controller釋放的時候帆谍，他們也隨之釋放。用一張圖簡單的描述他們的關系：
根據各個應用使用的設計模式不同（MVC轴咱，MVP汛蝙，MVVM等），Controller所持有的Property也不相同朴肺。這里我們使用MVP作為例子窖剑，Controller所包含的對象就包括各種View對象，和Presenter戈稿，Model對象西土。當然每個對象又有可能持有更多的子對象。
PLeakSniffer基于這樣一個假設： > 如果Controller被釋放了鞍盗，但其曾經持有過的子對象如果還存在需了，那么這些子對象就是泄漏的可疑目標。
當然這個假設并不是一個100%適用的真理般甲，不同工程師編寫代碼的方式風格差別很大肋乍，有些會把某些UIViewController做成單例（個人覺得這不是個好主意。敷存。）墓造，有些會把某些View緩存起來（即使Controller已被釋放），還會有其他考慮不到的場景。但在80%以上的場景觅闽，我們在Controller結束生命周期之后會將其持有的資源一并釋放帝雇。這時候PLeakSniffer可以發(fā)揮用處，給你一些免費的泄漏建議蛉拙。
那么怎么在Controller被釋放之后尸闸，知道其持有的對象沒有被釋放呢？
一個小技巧可以達成這個目標：子對象（比如view）建立一個對controller的weak引用孕锄，如果Controller被釋放夏伊，這個weak引用也隨之置為nil闹获。那怎么知道子對象沒有被釋放呢呻顽？用一個單例對象每個一小段時間發(fā)出一個ping通知去ping這個子對象敞斋，如果子對象還活著就會一個pong通知。所以結論就是：如果子對象的controller已不存在恼除，但還能響應這個ping通知踪旷，那么這個對象就是可疑的泄漏對象。完整的結構可以用下圖表示：
通知移除需要一個時機豁辉，這里我們使用Associated Object機制給每一個子對象再生成一個Proxy對象令野，在Proxy對象的dealloc里面移除通知。
當然什么時候去判斷一個對象的生命周期開始徽级，什么時候判斷為結束气破，需要一個精挑細選的機制。View餐抢，Controller现使，Property各不相同。
PLeakSniffer采取保守的策略旷痕，通過Objective C的runtime機制碳锈，遞歸的將一個Controller所有強引用的property找出，并安裝proxy監(jiān)聽Ping通知欺抗。在我的測試下售碳，基本上能將property泄漏的場景找出。
PLeakSniffer的使用方式很簡答绞呈，通過Pod安裝后贸人，通過以下代碼激活即可。
#if MY_DEBUG_ENV
[[PLeakSniffer sharedInstance] installLeakSniffer];
[[PLeakSniffer sharedInstance] addIgnoreList:@[@"MySingletonController"]];
#endif
addIgnoreList可以添加一些特殊的忽略名單佃声，比如單例這種無法正確預測泄漏的對象艺智。切記用Debug的宏將上述代碼包住，不要把這些檢測泄漏的代碼帶進線上環(huán)境秉溉。
如果檢測到可疑泄漏力惯，PLeakSniffer會在控制臺打印一條日志：
Controller泄漏：Detect Possible Controller Leak: %@
其他對象泄漏：Detect Possible Leak: %@
更多的細節(jié)請查閱代碼：GitHub地址碗誉。
