Android記憶體流失簡介

標籤：

前言

   不少人認為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程式的某個對象的引用，泄露的記憶體依然不能被記憶體回收。

比如

    假設我們希望在鎖定畫面(LockScreen)中，監聽系統中的電話語音以擷取一些資訊(如訊號強度等)，則可以在LockScreen中定義一個PhoneStateListener的對象，同時將它註冊到TelephonyManager服務中。對於LockScreen對象，當需要顯示鎖定畫面的時候就會建立一個LockScreen對象，而當鎖定畫面消失的時候LockScreen對象就會被釋放掉。

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

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

1.2、集合容器物件沒清理造成的記憶體泄露

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

1.3、Context泄漏所謂的Context泄漏，其實更多的是指Activity泄露，這是一個很隱晦的OutOfMemoryError的情況。先看一個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);  }  這段代碼效率很快，但同時又是極其錯誤的； 在第一次螢幕方向切換時它泄露了一開始建立的Activity。當一個Drawable附加到一個 View上時， View會將其作為一個callback設定到Drawable上。上述的程式碼片段，意味著這個靜態Drawable擁有一個TextView的引用， 而TextView又擁有Activity（Context類型）的引用，換句話說，Drawable擁有了更多的對象引用。即使Activity被 銷毀，記憶體仍然不會被釋放。 另外，對Context的引用超過它本身的生命週期，也會導致該Context無法回收，從而導致記憶體流失。所以盡量使用Application這種Context類型。 這種Context擁有和應用程式一樣長的生命週期，並且不依賴Activity的生命週期。如果你打算儲存一個長時間的對象， 並且其需要一個 Context，記得使用Application對象。你可以通過調用Context.getApplicationContext()或 Activity.getApplication()輕鬆得到Application對象。 最近遇到一種情況引起了Context泄漏，就是在Activity銷毀時，裡面有其他線程沒有停。 總結一下避免Context泄漏應該注意的問題： 1.盡量使用Application這種Context類型。 2.注意對Context的引用不要超過它本身的生命週期。 3.謹慎的對Context使用“static”關鍵字。 4.Context裡如果有線程，一定要在onDestroy()裡及時停掉。  1.4、static關鍵字的濫用 當類的成員變數聲明成static後，它是屬於類的而不是屬於對象的，如果我們將很大的資來源物件（Bitmap，context等）聲明成static，那麼這些資源不會隨著對象的回收而回收， 會一直存在，所以在使用static關鍵字定義成員變數的時候要謹慎。 1.5、WebView對象沒有銷毀當我們不要使用WebView對象時，應該調用它的destory()函數來銷毀它，並釋放其佔用的記憶體，否則其佔用的記憶體長期也不能被回收，從而造成記憶體泄露 1.6、GridView的濫用GridView和ListView的實現方式不太一樣。GridView的View不是即時建立的，而是全部儲存在記憶體中的。比如一個GridView有100項，雖然我們只能看到10項，但是其實整個100項都是在記憶體中的。

二、資來源物件沒關閉造成的記憶體泄露

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

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

三、一些不良代碼成記憶體壓力

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

3.1、Bitmap沒調用recycle()

Bitmap對象在不使用時,我們應該先調用recycle()，然後才它設定為null.

雖然Bitmap在被回收時可以通過BitmapFinalizer來回收記憶體。但是調用recycle()是一個良好的習慣

在Android4.0之前，Bitmap的記憶體是分配在Native堆中，調用recycle()可以立即釋放Native記憶體。

從Android4.0開始，Bitmap的記憶體就是分配在dalvik堆中，即JAVA堆中的，調用recycle()並不能立即釋放Native記憶體。但是調用recycle()也是一個良好的習慣。

可以通過dumpsys meminfo命令查看一個進程的記憶體情況。

樣本：adb shell "dumpsys meminfo com.lenovo.robin"

運行結果。

Applications Memory Usage (kB):

Uptime: 18696550 Realtime: 18696541

 

** MEMINFO in pid 7985 [com.lenovo.robin] **

                    native   dalvik    other    total

            size:     4828     5379      N/A    10207

       allocated:     4073     2852      N/A     6925

            free:       10     2527      N/A     2537

           (Pss):      608      317     1603     2528

  (shared dirty):     2240     1896     6056    10192

    (priv dirty):      548       36     1276     1860

 

 Objects

           Views:        0        ViewRoots:        0

     AppContexts:        0       Activities:        0

          Assets:        2    AssetManagers:        2

   Local Binders:        5    Proxy Binders:       11

Death Recipients:        1

 OpenSSL Sockets:        0

 

 SQL

               heap:        0         MEMORY_USED:        0

 PAGECACHE_OVERFLOW:        0         MALLOC_SIZE:        0

關於記憶體統計的更多內容請參考《Android記憶體泄露利器（記憶體統計篇）》

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對象的過程可以查看:

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

範例程式碼：

public View getView(int position, View convertView, ViewGroup parent) {

    View view = new Xxx(...);

    ... ...

    return view;

}

修正範例程式碼：

public View getView(int position, View convertView, ViewGroup parent) {

    View view = null;

    if (convertView != null) {

        view = convertView;

        populate(view, getItem(position));

        ...

    } else {

        view = new Xxx(...);

        ...

    }

    return view;

} 

3.3、ThreadLocal使用不當

如果我們粗暴的把ThreadLocal設定null,而不調用remove()方法或set(null),那麼就可能造成ThreadLocal綁定的對象長期也不能被回收，因而產出記憶體泄露。關於此的更多內容請參考《ThreadLocal的記憶體泄露》 四、JNI代碼的記憶體泄露關於此的詳細內容請參考《JNI引用與記憶體回收》

Android記憶體流失簡介