Android的虛擬機器是基於暫存器的Dalvik，它的最大堆大小一般是16M。但是Android採用的是Java語言編寫，所以在很大程度上，Android的記憶體機制等同於Java的記憶體機制，在剛開始開發的時候，記憶體的限制問題會給我們帶來記憶體溢位等嚴重問題。在我們不使用一些記憶體的時候，我們要儘量在Android或者其他平臺上避免在執行其他程式時，儲存必要的狀態，使得一些死程序所帶來的記憶體問題，應該儘量在關閉程式或者儲存狀態的時候釋放掉，這樣能提高系統在執行方面的流暢性。

Android的記憶體主要表現在：

1. 在Android平臺上，長期保持一些資源的引用，造成一些記憶體不能釋放，帶來的記憶體洩露問題很多。比如：Context（下文中提到的Activity都是Context），在一些你需要保持你的首個類物件狀態，並且把狀態傳入其他類物件中時，這樣消除掉首個類物件之前，你必須先把接收類物件釋放掉。需要注意一點的是：因為在Java或者Android記憶體機制中，頂點的結點釋放前必須保證其他物件沒有呼叫才能被系統GC回收釋放。我們來看一段程式碼：

@Override  

protected void onCreate(Bundle state) {  

     super.onCreate(state);  

     TextViewlabel = new TextView(this);  

     label.setText(“Leaksare bad”);  

     setContentView(label);  

}  

這個程式碼的意思就是我們把一個TextView的例項載入到了我們正在執行的Activity（Context）當中，因此，通過GC回收機制，我們知道，要釋放Context，就必須先釋放掉引用他的一些物件。如果沒有，那在要釋放Context的時候，你會發現會有大量的記憶體溢位。所以在你不小心的情況下記憶體溢位是一件非常容易的事情。 儲存一些物件時，同時也會造成記憶體洩露。最簡單的比如說點陣圖（Bitmap），比如說：在螢幕旋轉時，會破壞當前保持的一個Activity狀態，並且重新申請生成新的Activity，直到新的Activity狀態被儲存。我們再看一段程式碼：

privatestatic 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);  

}  

這個程式碼是非常快的同時也是錯誤的。它的記憶體洩露很容易出在螢幕轉移的方向上。雖然我們會發現沒有顯示的儲存Context這個例項，但是當我們把繪製的圖連線到一個檢視的時候，Drawable就會將被View設定為回撥，這就說明，在上述的程式碼中，其實在繪製TextView到活動中的時候，我們已經引用到了這個Activity。連結情況可以表現爲：Drawable->TextView->Context。

所以在想要釋放Context的時候，其實還是儲存在記憶體中，並沒有得到釋放。

如何避免這種情況：主要在於。執行緒最容易出錯。大家不要小看執行緒，在Android裏面執行緒最容易造成記憶體洩露。執行緒產生記憶體洩露的主要原因在於執行緒生命週期的不可控。下面有一段程式碼：

publicclass MyTest extends Activity {  

    @Override  

    publicvoid onCreate(BundlesavedInstanceState) {  

        super.onCreate(savedInstanceState);  

        setContentView(R.layout.main);  

        new MyThread().start();  

    }  

    privateclass MyThread extends Thread{  

        @Override  

        public void run() {  

           super.run();  

           //do somthing  

        }  

    }  

}  

程式碼很簡單，但是在Android上又來新問題了，當我們在切換檢視螢幕的時候（橫豎屏），就會重新建立橫屏或者豎屏的Activity。我們形象的認為之前建立的Activity會被回收，但是事實如何呢？Java機制不會給你同樣的感受，在我們釋放Activity之前，因為run函式沒有結束，這樣MyThread並沒有銷燬，因此引用它的Activity（Mytest）也有沒有被銷燬，因此也帶來的記憶體洩露問題。

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

執行緒問題的改進方式主要有：

l  將執行緒的內部類，改為靜態內部類。

l  在程式中儘量採用弱引用儲存Context。

2. 萬惡的bitmap。。。

Bitmap是一個很萬惡的物件，對於一個記憶體物件，如果該物件所佔記憶體過大，在超出了系統的記憶體限制時候，記憶體洩露問題就很明顯了。。

解決bitmap主要是要解決在記憶體儘量不儲存它或者使得采樣率變小。在很多場合下，因為我們的圖片畫素很高，而對於手機螢幕尺寸來說我們並不用那麼高畫素比例的圖片來載入時，我們就可以先把圖片的取樣率降低在做原來的UI操作。

如果在我們不需要儲存bitmap物件的引用時候，我們還可以用軟引用來做替換。具體的例項程式碼google上面也有很多。

綜上所述，要避免記憶體洩露，主要要遵循以下幾點：

第一：不要為Context長期儲存引用（要引用Context就要使得引用物件和它本身的生命週期保持一致）。

第二：如果要使用到Context，儘量使用ApplicationContext去代替Context，因為ApplicationContext的生命週期較長，引用情況下不會造成記憶體洩露問題

第三：在你不控制物件的生命週期的情況下避免在你的Activity中使用static變數。儘量使用WeakReference去代替一個static。

第四：垃圾回收器並不保證能準確回收記憶體，這樣在使用自己需要的內容時，主要生命週期和及時釋放掉不需要的物件。儘量在Activity的生命週期結束時，在onDestroy中把我們做引用的其他物件做釋放，比如：cursor.close()。

其實我們可以在很多方面使用更少的程式碼去完成程式。比如：我們可以多的使用9patch圖片等。有很多細節地方都可以值得我們去發現、挖掘更多的記憶體問題。我們要是能做到C/C++對於程式的「誰建立，誰釋放」原則，那我們對於記憶體的把握，並不比Java或Android本身的GC機制差，而且更好的控制記憶體，能使我們的手機執行得更流暢。

本文來自新浪部落格