編者按：文中有些內容會有所爭議（如下圖評論），各位可以從中吸取有用的內容，以學習交流的態度來閱讀，而不是去以指責的態度去看。

不少人認為JAVA程序，因為有垃圾回收機制，應該沒有內存泄露。其實如果我們一個 程序中，已經不再使用某個對象，但是因為仍然有引用指向它，垃圾回收器就無法回收它，當然該對象占用的內存就無法被使用，這就造成了內存泄露。如果我們的 java運行很久,而這種內存泄露不斷的發生，***就沒內存可用了。當然java的，內存泄漏和C/C++是不一樣的。如果java程序完全結束后，它所 有的對象就都不可達了，系統就可以對他們進行垃圾回收，它的內存泄露僅僅限于它本身，而不會影響整個系統的。C/C++的內存泄露就比較糟糕了，它的內存 泄露是系統級，即使該C/C++程序退出，它的泄露的內存也無法被系統回收，永遠不可用了，除非重啟機器。

Android的一個應用程序的內存泄露對別的應用程序影響不大。為了能夠使得Android應用程序安全且快速的運行，Android的每個應用程序都會使用一個專有的Dalvik虛擬機實例來運行，它是由Zygote服務進程孵化出來的，也就是說每個應用程序都是在屬于自己的進程中運行的。 Android為不同類型的進程分配了不同的內存使用上限，如果程序在運行過程中出現了內存泄漏的而造成應用進程使用的內存超過了這個上限，則會被系統視 為內存泄漏，從而被kill掉，這使得僅僅自己的進程被kill掉，而不會影響其他進程（如果是system_process等系統進程出問題的話，則會 引起系統重啟）。

一、引用沒釋放造成的內存泄露

1.1注冊沒取消造成的內存泄露

這種Android的內存泄露比純java的內存泄露還要嚴重，因為其他一些Android程序可能引用我們的Anroid程序的對象（比如注冊機 制）。即使我們的Android程序已經結束了，但是別的引用程序仍然還有對我們的Android程序的某個對象的引用，泄露的內存依然不能被垃圾回收。

比如示例1:

假設我們希望在鎖屏界面(LockScreen)中，監聽系統中的電話服務以獲取一些信息(如信號強度等)，則可以在LockScreen中定義一個 PhoneStateListener的對象，同時將它注冊到TelephonyManager服務中。對于LockScreen對象，當需要顯示鎖屏界 面的時候就會創建一個LockScreen對象，而當鎖屏界面消失的時候LockScreen對象就會被釋放掉。

但是如果在釋放LockScreen對象的時候忘記取消我們之前注冊的PhoneStateListener對象，則會導致LockScreen無法被 垃圾回收。如果不斷的使鎖屏界面顯示和消失，則最終會由于大量的LockScreen對象沒有辦法被回收而引起OutOfMemory,使得 system_process進程掛掉。

雖然有些系統程序，它本身好像是可以自動取消注冊的（當然不及時），但是我們還是應該在我們的程序中明確的取消注冊，程序結束時應該把所有的注冊都取消掉。

1.2集合中對象沒清理造成的內存泄露

我們通常把一些對象的引用加入到了集合中，當我們不需要該對象時，并沒有把它的引用從集合中清理掉，這樣這個集合就會越來越大。如果這個集合是static的話，那情況就更嚴重了。

二、資源對象沒關閉造成的內存泄露

資源性對象比如（Cursor，File文件等）往往都用了一些緩沖，我們在不使用的時候，應該及時關閉它們，以便它們的緩沖及時回收內存。它們的緩沖 不僅存在于java虛擬機內，還存在于java虛擬機外。如果我們僅僅是把它的引用設置為null,而不關閉它們，往往會造成內存泄露。因為有些資源性對 象，比如SQLiteCursor（在析構函數finalize（）,如果我們沒有關閉它，它自己會調close()關閉），如果我們沒有關閉它，系統在 回收它時也會關閉它，但是這樣的效率太低了。因此對于資源性對象在不使用的時候，應該調用它的close()函數，將其關閉掉，然后才置為null.在我 們的程序退出時一定要確保我們的資源性對象已經關閉。

程序中經常會進行查詢數據庫的操作，但是經常會有使用完畢Cursor后沒有關閉的情況。如果我們的查詢結果集比較小，對內存的消耗不容易被發現，只有在常時間大量操作的情況下才會復現內存問題，這樣就會給以后的測試和問題排查帶來困難和風險。

三、一些不良代碼成內存壓力

有些代碼并不造成內存泄露，但是它們，或是對沒使用的內存沒進行有效及時的釋放，或是沒有有效的利用已有的對象而是頻繁的申請新內存，對內存的回收和分配造成很大影響的，容易迫使虛擬機不得不給該應用進程分配更多的內存，造成不必要的內存開支。

3.1，Bitmap沒調用recycle()

Bitmap對象在不使用時,我們應該先調用recycle()釋放內存，然后才它設置為null.雖然recycle()從源碼上看，調用它應該能立 即釋放Bitmap的主要內存，但是測試結果顯示它并沒能立即釋放內存。但是我它應該還是能大大的加速Bitmap的主要內存的釋放。

3.2，構造Adapter時，沒有使用緩存的 convertView

以構造ListView的BaseAdapter為例，在BaseAdapter中提共了方法：

public View getView(int position, View convertView, ViewGroup parent)來向ListView提供每一個item所需要的view對象。初始時ListView會從BaseAdapter中根據當前的屏幕布局實 例化一定數量的view對象，同時ListView會將這些view對象緩存起來。當向上滾動ListView時，原先位于最上面的list item的view對象會被回收，然后被用來構造新出現的最下面的list item。這個構造過程就是由getView()方法完成的，getView()的第二個形參 View convertView就是被緩存起來的list item的view對象(初始化時緩存中沒有view對象則convertView是null)。

由此可以看出，如果我們不去使用convertView，而是每次都在getView()中重新實例化一個View對象的話，即浪費時間，也造成內存垃 圾，給垃圾回收增加壓力，如果垃圾回收來不及的話，虛擬機將不得不給該應用進程分配更多的內存，造成不必要的內存開支。ListView回收list item的view對象的過程可以查看:

view plaincopy to clipboardprint?

android.widget.AbsListView.java –> void addScrapView(View scrap) 方法。

在android的開發中，要時刻主要內存的分配和垃圾回收，因為系統為每一個dalvik虛擬機分配的內存是有限的，在google的G1中，分配的***堆大小只有 16M，后來的機器一般都為24M，實在是少的可憐。這樣就需要我們在開發過程中要時刻注意。不要因為自己的代碼問題而造成OOM錯誤。

JAVA的內存管理：

大家都知道，android應用層是由java開發的，android的davlik虛擬機與jvm也類似，只不過它是基于寄存器的。因此要了解android的內存管理就必須得了解java的內存分配和垃圾回收機制。

在java中，是通過new關鍵字來為對象分配內存的，而內存的釋放是由垃圾收集器（GC）來回收的，工程師在開發的過程中，不需要顯式的去管理內存。 但是這樣有可能在不知不覺中就會浪費了很多內存，最終導致java虛擬機花費很多時間去進行垃圾回收，更嚴重的是造成JVM的OOM。因此，java工程 師還是有必要了解JAVA的內存分配和垃圾回收機制。

下面列出了存在的問題，點擊detail進去，會列出詳細的，可能會存在問題的代碼：

file:///C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ksohtml/wps_clip_image-32625.png

file:///C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ksohtml/wps_clip_image-21158.png

關于MAT的使用可以參考：http://www.blogjava.net/rosen/ … .html

這位兄弟寫的比較詳細。

總結

不管是java還是android，都應該了解內存分配和垃圾回收機制，工程師要做到寫的代碼中沒有bad code很難，關鍵是在出現問題的時候該怎么去排查Android內存優化

一、 Android的內存機制

Android的程序由Java語言編寫，所以Android的內存管理與Java的內存管理相似。程序員通過new為對象分配內存，所有對象在java堆內分配空間；然而對象的釋放是由垃圾回收器來完成的。C／C++中的內存機制是“誰污染，誰治理”，java的就比較人性化了，給我們請了一個專門的清潔工（GC）。

那么GC怎么能夠確認某一個對象是不是已經被廢棄了呢？Java采用了有向圖的原理。Java將引用關系考慮為圖的有向邊，有向邊從引用者指向引用對象。 線程對象可以作為有向圖的起始頂點，該圖就是從起始頂點開始的一棵樹，根頂點可以到達的對象都是有效對象，GC不會回收這些對象。如果某個對象 (連通子圖)與這個根頂點不可達(注意，該圖為有向圖)，那么我們認為這個(這些)對象不再被引用，可以被GC回收。

二、Android的內存溢出

Android的內存溢出是如何發生的?

Android的虛擬機是基于寄存器的Dalvik，它的***堆大小一般是16M，有的機器為24M。因此我們所能利用的內存空間是有限的。如果我們的內存占用超過了一定的水平就會出現OutOfMemory的錯誤。

為什么會出現內存不夠用的情況呢？我想原因主要有兩個：

由于我們程序的失誤，長期保持某些資源（如Context）的引用，造成內存泄露，資源造成得不到釋放。

保存了多個耗用內存過大的對象（如Bitmap），造成內存超出限制。

三、萬惡的static

static是Java中的一個關鍵字，當用它來修飾成員變量時，那么該變量就屬于該類，而不是該類的實例。所以用static修飾的變量，它的生命周期是很長的，如果用它來引用一些資源耗費過多的實例（Context的情況最多），這時就要謹慎對待了。

sBackground是一個靜態的變量，但是我們發現，我們并沒有顯式的保存Contex的引用，但是，當Drawable與View連接之 后，Drawable就將View設置為一個回調，由于View中是包含Context的引用的，所以，實際上我們依然保存了Context的引用。這個 引用鏈如下：

Drawable->TextView->Context

所以，最終該Context也沒有得到釋放，發生了內存泄露。

如何才能有效的避免這種引用的發生呢？

應該盡量避免static成員變量引用資源耗費過多的實例，比如Context。

Context盡量使用Application Context，因為Application的Context的生命周期比較長，引用它不會出現內存泄露的問題。

使用WeakReference代替強引用。比如可以使用WeakReference<Context> mContextRef;

該部分的詳細內容也可以參考Android文檔中Article部分。

四、都是線程惹的禍

線程也是造成內存泄露的一個重要的源頭。線程產生內存泄露的主要原因在于線程生命周期的不可控。我們來考慮下面一段代碼。

有些人喜歡用Android提供的AsyncTask，但事實上 AsyncTask的問題更加嚴重，Thread只有在run函數不結束時才出現這種內存泄露問題，然而AsyncTask內部的實現機制是運用了 ThreadPoolExcutor,該類產生的Thread對象的生命周期是不確定的，是應用程序無法控制的，因此如果AsyncTask作為 Activity的內部類，就更容易出現內存泄露的問題。

事實上，線程的問題并不僅僅在于內存泄露，還會帶來一些災難性的問題 。

五、行蹤詭異的Cursor

Cursor是Android查詢數據后得到的一個管理數據集合的類，正常情況下，如果查詢得到的數據量較小時不會有內存問題，而且虛擬機能夠保證Cusor最終會被釋放掉。

然而如果Cursor的數據量特表大，特別是如果里面有Blob信息時，應該保證Cursor占用的內存被及時的釋放掉，而不是等待GC來處理。并且 Android明顯是傾向于編程者手動的將Cursor close掉，因為在源代碼中我們發現，如果等到垃圾回收器來回收時，會給用戶以錯誤提示。

有一種情況下，我們不能直接將Cursor關閉掉，這就是在CursorAdapter中應用的情況，但是注意，CursorAdapter在Acivity結束時并沒有自動的將Cursor關閉掉，因此，你需要在onDestroy函數中，手動關閉。

轉載請注明：android 開發如何做好內存優化