網上看的一篇很好的文章;http://www.gforetell.com/?/question/id-111__uid-focus
不少人認為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) 方法。
示例代碼：
1 public View getView(int position, View convertView, ViewGroup parent) { 2 3 View view = new Xxx(...); 4 5 ... ... 6 7 return view; 8 9 }
修正示例代碼：
Android內存管理
1 public View getView(int position, View convertView, ViewGroup parent) { 2 3 View view = null; 4 5 if (convertView != null) { 6 7 view = convertView; 8 9 populate(view, getItem(position)); 10 11 ... 12 13 } else { 14 15 view = new Xxx(...); 16 17 ... 18 19 } 20 21 return view; 22 23 }
概述：
在android的開發中，要時刻主要內存的分配和垃圾回收，因為系統為每一個dalvik虛擬機分配的內存是有限的，在google的G1中，分配的最大堆大小只有16M，后來的機器一般都為24M，實在是少的可憐。這樣就需要我們在開發過程中要時刻注意。不要因為自己的代碼問題而造成OOM錯誤。
JAVA的內存管理：
大家都知道，android應用層是由java開發的，android的davlik虛擬機與jvm也類似，只不過它是基於寄存器的。因此要了解android的內存管理就必須得了解java的內存分配和垃圾回收機制。
在java中，是通過new關鍵字來為對象分配內存的，而內存的釋放是由垃圾收集器（GC）來回收的，工程師在開發的過程中，不需要顯式的去管理內存。但是這樣有可能在不知不覺中就會浪費了很多內存，最終導致java虛擬機花費很多時間去進行垃圾回收，更嚴重的是造成JVM的OOM。因此，java工程師還是有必要了解JAVA的內存分配和垃圾回收機制。
內存結構 file:///C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ksohtml/wps_clip_image-6926.png 上面這張圖是JVM的結構圖，它主要四個部分組成：Class Loader子系統和執行引擎，運行時方法區和本地方法區，我們主要來看下RUNTIME DATA AREA區，也就是我們常說的JVM內存。從圖中可以看出，RUNTIMEDATA AREA區主要由5個部分組成： · Method Area:被裝載的class的元信息存儲在Method Area中，它是線程共享的 · Heap(堆)：一個java虛擬機實例中只存在一個堆空間，存放一些對象信息，它是線程共享的 · Java棧： java虛擬機直接對java棧進行兩種操作，以幀為單位的壓棧和出棧（非線程共享） · 程序計數器（非線程共享） · 本地方法棧（非線程共享） JVM的垃圾回收（GC） file:///C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ksohtml/wps_clip_image-12485.png JVM的垃圾原理是這樣的，它把對象分為年輕代（Young）、年老代（Tenured）、持久代（Perm），對不同生命周期的對象使用不同的垃圾回收算法。 · 年輕代(Young) 年輕代分為三個區，一個eden區，兩個Survivor區。程序中生成的大部分新的對象都在Eden區中，當Eden區滿時，還存活的對象將被復制到其中一個Survivor區，當此Survivor區的對象占用空間滿了時，此區存活的對象又被復制到另外一個Survivor區，當這個Survivor區也滿了的時候，從第一個Survivor區復制過來的並且此時還存活的對象，將被復制到年老代。 · 年老代（Tenured） 年老代存放的是上面年輕代復制過來的對象，也就是在年輕代中還存活的對象，並且區滿了復制過來的。一般來說，年老代中的對象生命周期都比較長。 · 持久代（Perm） 用於存放靜態的類和方法，持久代對垃圾回收沒有顯著的影響。 Android中內存泄露監測 在了解了JVM的內存管理后，我們再回過頭來看看，在android中應該怎樣來監測內存，從而看在應用中是否存在內存分配和垃圾回收問題而造成內存泄露情況。 在android中，有一個相對來說還不錯的工具，可以用來監測內存是否存在泄露情況：DDMS—Heap file:///C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ksohtml/wps_clip_image-22715.png 使用方法比較簡單： · 選擇DDMS視圖，並打開Devices視圖和Heap視圖 · 點擊選擇要監控的進程，比如：上圖中我選擇的是system_process · 選中Devices視圖界面上的"update heap" 圖標 · 點擊Heap視圖中的"Cause GC" 按鈕（相當於向虛擬機發送了一次GC請求的操作） 在Heap視圖中選擇想要監控的Type，一般我們會觀察dataobject的 total size的變化，正常情況下total size的值會穩定在一個有限的范圍內，也就說程序中的代碼良好，沒有造成程序中的對象不被回收的情況。如果代碼中存在沒有釋放對象引用的情況，那么data object的total size在每次GC之后都不會有明顯的回落，隨着操作次數的增加而total size也在不斷的增加。（說明：選擇好data object后，不斷的操作應用，這樣才可以看出total size的變化）。如果totalsize確實是在不斷增加而沒有回落，說明程序中有沒有被釋放的資源引用。那么我們應該怎么來定位呢？ Android中內存泄露定位 Mat(memory analyzer tools)是我們常用的用來定位內存泄露的工具，如果你使用ADT，並且安裝了MAT的eclipse插件，你需要做的是進入DDMS視圖的Devices視圖： file:///C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ksohtml/wps_clip_image-2165.png 點擊"dump HPROF file"按鈕，然后使用MAT分析下載下來的文件。 file:///C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ksohtml/wps_clip_image-6565.png
下面列出了存在的問題，點擊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的情況最多），這時就要謹慎對待了。
1 public class ClassName { 2 3 private static Context mContext; 4 5 //省略 6 7 }
以上的代碼是很危險的，如果將Activity賦值到么mContext的話。那么即使該Activity已經onDestroy，但是由於仍有對象保存它的引用，因此該Activity依然不會被釋放。
我們舉Android文檔中的一個例子。
private static Drawable sBackground; @Override protected void onCreate(Bundle state) { super.onCreate(state); TextView label = new TextView(this); label.setText("Leaks are bad"); if (sBackground == null) { sBackground = getDrawable(R.drawable.large_bitmap); } label.setBackgroundDrawable(sBackground); setContentView(label); }
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部分。
四、都是線程惹的禍
線程也是造成內存泄露的一個重要的源頭。線程產生內存泄露的主要原因在於線程生命周期的不可控。我們來考慮下面一段代碼。
1 public class MyActivity extends Activity { 2 3 @Override 4 5 public void onCreate(Bundle savedInstanceState) { 6 7 super.onCreate(savedInstanceState); 8 9 setContentView(R.layout.main); 10 11 new MyThread().start(); 12 13 } 14 15 16 private class MyThread extends Thread{ 17 18 @Override 19 20 public void run() { 21 22 super.run(); 23 24 //do somthing 25 26 } 27 28 } 29 30 }
這段代碼很平常也很簡單，是我們經常使用的形式。我們思考一個問題：假設MyThread的run函數是一個很費時的操作，當我們開啟該線程后，將設備的橫屏變為了豎屏，一般情況下當屏幕轉換時會重新創建Activity，按照我們的想法，老的Activity應該會被銷毀才對，然而事實上並非如此。
由於我們的線程是Activity的內部類，所以MyThread中保存了Activity的一個引用，當MyThread的run函數沒有結束時，MyThread是不會被銷毀的，因此它所引用的老的Activity也不會被銷毀，因此就出現了內存泄露的問題。
file:///C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ksohtml/wps_clip_image-6439.png
有些人喜歡用Android提供的AsyncTask，但事實上AsyncTask的問題更加嚴重，Thread只有在run函數不結束時才出現這種內存泄露問題，然而AsyncTask內部的實現機制是運用了ThreadPoolExcutor,該類產生的Thread對象的生命周期是不確定的，是應用程序無法控制的，因此如果AsyncTask作為Activity的內部類，就更容易出現內存泄露的問題。
這種線程導致的內存泄露問題應該如何解決呢？
將線程的內部類，改為靜態內部類。
在線程內部采用弱引用保存Context引用。
解決的模型如下：
1 public abstract class WeakAsyncTask<Params, Progress, Result, WeakTarget> extends 2 AsyncTask<Params, Progress, Result> { 3 protected WeakReference<WeakTarget> mTarget; 4 5 public WeakAsyncTask(WeakTarget target) { 6 mTarget = new WeakReference<WeakTarget>(target); 7 } 8 9 /** {@inheritDoc} */ 10 @Override 11 protected final void onPreExecute() { 12 final WeakTarget target = mTarget.get(); 13 if (target != null) { 14 this.onPreExecute(target); 15 } 16 } 17 18 /** {@inheritDoc} */ 19 @Override 20 protected final Result doInBackground(Params... params) { 21 final WeakTarget target = mTarget.get(); 22 if (target != null) { 23 return this.doInBackground(target, params); 24 } else { 25 return null; 26 } 27 } 28 29 /** {@inheritDoc} */ 30 @Override 31 protected final void onPostExecute(Result result) { 32 final WeakTarget target = mTarget.get(); 33 if (target != null) { 34 this.onPostExecute(target, result); 35 } 36 } 37 38 protected void onPreExecute(WeakTarget target) { 39 // No default action 40 } 41 42 protected abstract Result doInBackground(WeakTarget target, Params... params); 43 44 protected void onPostExecute(WeakTarget target, Result result) { 45 // No default action 46 } 47 }
事實上，線程的問題並不僅僅在於內存泄露，還會帶來一些災難性的問題。由於本文討論的是內存問題，所以在此不做討論。
由於51cto不讓我一次傳完，說我的字數太多了，所以分開傳了。
五、超級大胖子Bitmap
可以說出現OutOfMemory問題的絕大多數人，都是因為Bitmap的問題。因為Bitmap占用的內存實在是太多了，它是一個“超級大胖子”，特別是分辨率大的圖片，如果要顯示多張那問題就更顯著了。
如何解決Bitmap帶給我們的內存問題？
及時的銷毀。
雖然，系統能夠確認Bitmap分配的內存最終會被銷毀，但是由於它占用的內存過多，所以很可能會超過java堆的限制。因此，在用完Bitmap時，要及時的recycle掉。recycle並不能確定立即就會將Bitmap釋放掉，但是會給虛擬機一個暗示：“該圖片可以釋放了”。
設置一定的采樣率。
有時候，我們要顯示的區域很小，沒有必要將整個圖片都加載出來，而只需要記載一個縮小過的圖片，這時候可以設置一定的采樣率，那么就可以大大減小占用的內存。如下面的代碼：
1 private ImageView preview; 2 3 4 BitmapFactory.Options options = new BitmapFactory.Options(); 5 6 7 options.inSampleSize = 2;//圖片寬高都為原來的二分之一，即圖片為原來的四分之一 8 9 Bitmap bitmap = BitmapFactory.decodeStream(cr.openInputStream(uri), null, options); 10 11 12 preview.setImageBitmap(bitmap);
巧妙的運用軟引用（SoftRefrence）
有些時候，我們使用Bitmap后沒有保留對它的引用，因此就無法調用Recycle函數。這時候巧妙的運用軟引用，可以使Bitmap在內存快不足時得到有效的釋放。如下例：
/**本例子為博主隨手一寫，來說明用法，並未驗證*/
1 private class MyAdapter extends BaseAdapter { 2 3 private ArrayList<SoftReference<Bitmap>> mBitmapRefs = new ArrayList<SoftReference<Bitmap>>(); 4 private ArrayList<Value> mValues; 5 private Context mContext; 6 private LayoutInflater mInflater; 7 8 MyAdapter(Context context, ArrayList<Value> values) { 9 mContext = context; 10 mValues = values; 11 mInflater = (LayoutInflater) context.getSystemService(Context.LAYOUT_INFLATER_SERVICE); 12 } 13 public int getCount() { 14 return mValues.size(); 15 } 16 public Object getItem(int i) { 17 return mValues.get(i); 18 } 19 20 public long getItemId(int i) { 21 return i; 22 } 23 24 public View getView(int i, View view, ViewGroup viewGroup) { 25 View newView = null; 26 if(view != null) { 27 newView = view; 28 } else { 29 newView =(View)mInflater.inflate(R.layout.image_view, false); 30 } 31 32 Bitmap bitmap = BitmapFactory.decodeFile(mValues.get(i).fileName); 33 mBitmapRefs.add(new SoftReference<Bitmap>(bitmap)); //此處加入ArrayList 34 ((ImageView)newView).setImageBitmap(bitmap); 35 36 return newView; 37 } 38 }
六、行蹤詭異的Cursor
Cursor是Android查詢數據后得到的一個管理數據集合的類，正常情況下，如果查詢得到的數據量較小時不會有內存問題，而且虛擬機能夠保證Cusor最終會被釋放掉。
然而如果Cursor的數據量特表大，特別是如果里面有Blob信息時，應該保證Cursor占用的內存被及時的釋放掉，而不是等待GC來處理。並且Android明顯是傾向於編程者手動的將Cursor close掉，因為在源代碼中我們發現，如果等到垃圾回收器來回收時，會給用戶以錯誤提示。
所以我們使用Cursor的方式一般如下：
1 Cursor cursor = null; 2 try { 3 cursor = mContext.getContentResolver().query(uri,null, null,null,null); 4 if(cursor != null) { 5 cursor.moveToFirst(); 6 //do something 7 } 8 } catch (Exception e) { 9 e.printStackTrace(); 10 } finally { 11 if (cursor != null) { 12 cursor.close(); 13 } 14 }
有一種情況下，我們不能直接將Cursor關閉掉，這就是在CursorAdapter中應用的情況，但是注意，CursorAdapter在Acivity結束時並沒有自動的將Cursor關閉掉，因此，你需要在onDestroy函數中，手動關閉。
1 protected void onDestroy() { 2 3 if (mAdapter != null && mAdapter.getCurosr() != null) { 4 5 mAdapter.getCursor().close(); 6 7 } 8 9 super.onDestroy(); 10 11 }
CursorAdapter中的changeCursor函數，會將原來的Cursor釋放掉，並替換為新的Cursor，所以你不用擔心原來的Cursor沒有被關閉。
你可能會想到使用Activity的managedQuery來生成Cursor，這樣Cursor就會與Acitivity的生命周期一致了，多么完美的解決方法！然而事實上managedQuery也有很大的局限性。
managedQuery生成的Cursor必須確保不會被替換，因為可能很多程序事實上查詢條件都是不確定的，因此我們經常會用新查詢的Cursor來替換掉原先的Cursor。因此這種方法適用范圍也是很小。
七、其它要說的。
其實，要減小內存的使用，其實還有很多方法和要求。比如不要使用整張整張的圖，盡量使用9path圖片。Adapter要使用convertView等等，好多細節都可以節省內存。這些都需要我們去挖掘，誰叫Android的內存不給力來着。