關於android內存泄漏的研究

博客建了幾個月，都沒有去寫，一是由於當時換工做，而後又是新入職（你懂的，好好表現），比較忙；二是也由於本身沒有寫博客的習慣了。如今還算是比較穩定了，加上這個迭代基本也快結束了，有點時間來寫寫博客。好了，廢話少說，下面進入正題，關於android內存泄漏的研究：

最近參與公司項目的迭代，發現這個幾百萬用戶量的項目通過這麼多的迭代了，仍是一直存在嚴重的內存泄漏的問題，這個其實剛入職的時候就發現了，可是一直沒敢說。如今也算是老員工了，這個迭代我提了出來，正好個人迭代開發工做也基本完成了，因而就是我去查這個問題，開始作的時候我才發現，給本身出了個難題，七，八萬行的代碼，不少的模塊，不少的代碼我都沒接觸過。沒辦法，只能硬着頭皮來了。

android內存泄漏，其實泄漏幾個String，泄漏幾個普通對象，對用戶體驗沒什麼影響，主要問題在於泄漏了跟界面有關的東西，如View，Activity，PopupWidow，和Dialog，和Bitmap。泄漏，不僅是說反覆進入內存是否是一直增大，並且當你的這些界面關閉時，它所佔用的空間會不會被釋放掉。咱們的項目有100多個PopupWindow，Dialog，和自定義View，十幾個Activity，顯然先查Activity是明智的，並且Activity的嚴重程度也比較高，因而找了個最簡單的Activity開始查。

像數據庫遊標用完關閉，以及文件讀取關閉，和全局Bitmap用完釋放，這類的這裏就不詳細說了。

①像這些界面類，釋放不掉，緣由確定是它本身的實例被傳來傳去，最後傳到一個靜態全局變量中，致使其一直釋放不了（由於靜態變量一直不釋放）。或者是界面類的全局變量有引用到它本身，然這個變量可能又被其餘的靜態變量中，一直被引用着，沒有釋放掉。

建議：在要用到Context的時候，儘可能傳Application而不是Activity實例（有一些狀況沒辦法，用完要作好手動釋放）。

在這些界面類中，若是用到了靜態變量引用到這些界面類自己，界面關閉的時候要手動釋放掉。

若是是加入了ArrayList等集合中，那麼界面退出時，要把它從集合中移除。（這個問題大了，不僅是退出沒有釋放的問題，而是每一次操做都會使你的程序的內存增大，很快就會內存溢出）

②關於WebView使用，內存泄漏的問題。

WebView會佔很大的空間，並且用普通的在xml佈局中寫WebView的方法，WebView並不會釋放（查了資料，發現是android的bug），因而咱們要動態加載它，能夠把它放到一個ViewGroup中，在佈局中加一個ViewGroup(RelativeLayout，FrameLayout均可以，其餘的每測)在代碼中new WebView(這裏要傳application，不要傳Activity)，而後把webview加入到ViewGroup中就能夠。可是在界面關閉的時候記得釋放掉：

viewGroup.removeAllViews();
webview.destroy();
webview = null;

就可使其釋放掉了。

關於內存泄漏查找工具，用的Memory Analyzer Tool，多是我不太會用，感受只是對那種每一次執行操做內存都會增大的狀況有用，它就只幫我解決了一個這種問題，狀況是我在每一次切換帳戶時，內存都會增大一些，因而我就不斷的切換，而後用Memory Analyzer Tool去查看，一眼就找到了那個特別大的類，而後看了下代碼，發現一直在往一個List裏面加東西，沒有移除。

這是我在咱們的項目中發現的內存泄漏的相關問題，基本上把內存問題解決了，不過仍是有一些泄漏，有的地方是找不到，有的地方是改動太大，如今不能動。不過問題不大，把全部界面跑一遍，在G1上泄漏了0點幾兆，不會引發內存溢出。第①個看似簡單，實際上是最難找的，尤爲是在特別大的項目中，它們隱藏的會特別深，因此咱們在寫代碼的時候必定要去考慮的內存泄漏的狀況，否則之後再查找起來，要浪費掉好幾倍的時間。

若是還有其餘的內存泄漏的狀況或者有什麼好的建議，但願你們補充，共同探討，共同進步。