內存泄露問(wèn)題是每個(gè)app都必須關(guān)注的問(wèn)題，關(guān)系到線(xiàn)上的穩定性和性能。內存泄露會(huì )導致：

由于內存資源不足發(fā)生難以排查的線(xiàn)上bug

由于被泄露對象的存在導致的一些業(yè)務(wù)bug，比如泄露的對象仍在接受全局通知

性能問(wèn)題，導致用戶(hù)使用app時(shí)越來(lái)越卡

內存泄露發(fā)現分成靜態(tài)掃描和運行時(shí)檢測，本文主要講運行時(shí)檢測。

靜態(tài)掃描

靜態(tài)掃描的工具：

xcode analyzer

OCLint

Infer

運行時(shí)動(dòng)態(tài)檢測

由于靜態(tài)掃描不能發(fā)現所有的內存泄露問(wèn)題，所以運動(dòng)時(shí)檢測是必不可少的。

Allocation

Xcode的Allocation可以通過(guò)比較不同時(shí)間段的對象，分析出是否發(fā)生了內存泄露。但是前提是每個(gè)頁(yè)面的命名要符合規范，比如寶貝詳情頁(yè)的所有對象都是應用前綴+寶貝詳情頁(yè)面前綴+具體對象名，這樣才退出頁(yè)面的時(shí)候才能知道相應的對象是否被釋放了，因為stack最底部的頁(yè)面的對象常駐在內存中。

Allocation通過(guò)和Monkey配合，在回歸測試的時(shí)候，自動(dòng)運行并通過(guò)計算內存占用率可以判斷出新的開(kāi)發(fā)版本是否發(fā)生了內存泄露，但是無(wú)法知道具體是哪個(gè)對象沒(méi)有釋放，只能是全局的判斷。

MLLeaksFinder

非常實(shí)用的內存泄露檢查工具，主要原理是UINavigationController在pop頁(yè)面的時(shí)候，可以預測出被pop的頁(yè)面將被釋放，所以在一段時(shí)間后（3s）對這個(gè)對象進(jìn)行斷言判斷，如果沒(méi)有被釋放的話(huà)程序就會(huì )中斷，還可以?huà)呙鑦iew hierarchy，或者自定義掃描需要的對象。

相比Allocation，最大的好處就是

及時(shí)發(fā)現正在開(kāi)發(fā)的頁(yè)面是否發(fā)生了內存泄露，及時(shí)排查，而不是在回歸測試的時(shí)候才發(fā)現

如果應用中的每個(gè)頁(yè)面都有相應配置的URL scheme的話(huà)，那么把所有頁(yè)面的url寫(xiě)在配置文件中，在回歸測試的時(shí)候，代碼里自動(dòng)push每個(gè)url的頁(yè)面，可以做到完整地回歸所有頁(yè)面，又免去了Allocation手動(dòng)點(diǎn)擊各個(gè)頁(yè)面的繁瑣。

如果嫌MLLeaksFinder代碼太多，可以自己實(shí)現一個(gè)精簡(jiǎn)版的，原理比較簡(jiǎn)單，代碼寫(xiě)起來(lái)很少。

如何排查

上述的各種方法發(fā)現了內存泄露后，排查并解決才是最關(guān)鍵的一步。根據泄露的對象，重點(diǎn)排查block和兩個(gè)以上對象循環(huán)引用的情況。

如果是ViewController發(fā)生內存泄露，重點(diǎn)查看ViewController里面的block是否忘記聲明weak了，因為ViewController被其他對象持有的情況不常見(jiàn)。如果是用RAC的話(huà)，記得weakly和strongly要成對出現，否則會(huì )發(fā)生內存泄露。

最常發(fā)生的是View的內存泄露問(wèn)題，首先查看是發(fā)生內存泄露的view之間是否有delegate的關(guān)系，如果有的話(huà)看看delegate屬性有沒(méi)有聲明weak

由于service或者讀取緩存等異步操作引起的內存泄露問(wèn)題

總結

內存泄露問(wèn)題主要還是靠編碼時(shí)的規范，靜態(tài)掃描能解決一部分問(wèn)題，動(dòng)態(tài)掃描是最后的保證。而排查內存泄露經(jīng)驗很重要。iOS加密也不能忽視，要對重要的數據進(jìn)行加密，根據重要程度選擇安全性可靠的方式。幾維安全編譯器基于LLVM編譯器中間層實(shí)現，加密代碼與業(yè)務(wù)代碼緊密結合，有效阻擋逆向分析，加密過(guò)程不依賴(lài)于特定系統環(huán)境，無(wú)兼容性問(wèn)題。