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;  

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機制差，而且更好的控制記憶體，能使我們的手機運作得更流暢。

本文轉自歡醉部落格園部落格，原文連結http://www.cnblogs.com/zhangs1986/p/3695314.html如需轉載請自行聯系原作者

歡醉