一塊兒來看看IOS內存泄漏的一個問題

不少iOS開發的朋友都是比較關心內存泄漏的問題，在實際的開發工做中首先咱們須要知道程序有沒有內存泄露，而後定位究竟是哪行代碼出現內存泄露了，這樣才能將其修復。最簡單的方法固然是藉助於專業的檢測工具，比較有名如BoundsCheck工具,功能很是強大。

　　內存的泄漏是會關係到線上的穩定性和性能。內存泄露將會是致使這樣的狀況發生：

　　1.如果內存資源不足發生難以排查的線上bug

　　2.被泄露對象的存在，將會是致使的一些業務bug，例如是泄露的對象它們是仍在接受全局的一個通知

　　3.一些性能問題，是會致使用戶使用app時愈來愈卡

　　內存泄露發現分紅靜態掃描和運行時檢測，本文主要講運行時檢測。

　　關於靜態掃描

　　經常使用的一些靜態掃描的工具：

　　xcode analyzer

　　OCLint

　　Infer

　　運行時動態檢測

　　由於在靜態掃描不能發現全部的內存泄露問題，所以在運動時檢測，是必不可少的一個操做。

　　Allocation

　　Xcode中的的Allocation是能夠經過比較不一樣時間段的對象，用來是分析出是否發生了一些內存泄露。前提必須是每一個頁面的命名要符合規範，就好比說寶貝詳情頁的全部對象，這些都是應用的前綴+寶貝詳情頁面前綴+具體對象名，當退出頁面的時候纔會是知道相應的對象是否被釋放了，那是由於stack最底部的頁面的對象常常是駐在內存中。

　　Allocation是經過和Monkey配合，當在迴歸測試的時候，會自動運行並經過計算內存佔用率，就能夠判斷出新的開發版本是否發生了內存泄露，可是沒法知道具體是哪一個對象沒有釋放，侷限性就是隻能經過全局的一個判斷。

　　重點是如何排查？

　　當發現了內存泄露後，排查並解決，這纔是最關鍵的一步。開發者是根據泄露的對象，重點的去排查block和兩個以上對象循環引用的最終狀況。

　　發現是ViewController發生內存泄露，就要是重點的去查看一下ViewController裏面的block是否忘記聲明weak了，當ViewController被其餘對象持有的狀況不常見。所以如果用RAC的話，這就要去記得weakly和strongly要成對出現，不然將會是發生內存的泄露。

　　實際上最常發生的是View的內存泄露問題，首先查看是發生內存泄露的view之間是否有delegate的關係，如有，則去看delegate屬性有沒有聲明weak，通常的因爲service或者讀取緩存等異步操做引發的內存泄露問題。

　　解決內存泄漏的問題最主要的仍是在編碼的時候儘可能的作到規範一些，學會利用工具去排查是積累經驗的有效手段，靜態掃描能解決一部分問題，動態掃描是最後的保證。