Android的內存主要表現在：
1. 在Android平臺上，長期保持一些資源的引用，造成一些內存不能釋放，帶來的內存泄露問題很多。比如：Context（下文中提到的Activity都是Context），在一些你需要保持你的首個類對象狀態，並且把狀態傳入其他類對象中時，這樣消除掉首個類對象之前，你必須先把接收類對象釋放掉。需要注意一點的是：因爲在Java或者Android內存機制中，頂點的結點釋放前必須保證其他對象沒有調用才能被系統GC回收釋放。我們來看一段代碼：
@Override
protected void onCreate(Bundlestate) {
super.onCreate(state);
TextViewlabel = new TextView(this);
label.setText("Leaksare bad");
setContentView(label);
}
這個代碼的意思就是我們把一個TextView的實例加載到了我們正在運行的Activity（Context）當中，因此，通過GC回收機制，我們知道，要釋放Context，就必須先釋放掉引用他的一些對象。如果沒有，那在要釋放Context的時候，你會發現會有大量的內存溢出。所以在你不小心的情況下內存溢出是一件非常容易的事情。保存一些對象時，同時也會造成內存泄露。最簡單的比如說位圖（Bitmap），比如說：在屏幕旋轉時，會破壞當前保持的一個Activity狀態，並且重新申請生成新的Activity，直到新的Activity狀態被保存。我們再看一段代碼：
privatestatic DrawablesBackground;
@Override
protected void onCreate(Bundlestate) {
super.onCreate(state);
TextView label = newTextView(this);
label.setText("Leaks arebad");
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 extendsActivity {
@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機制差，而且更好的控制內存，能使我們的手機運行得更流暢