Android的內存洩露問題

避免Android的內存洩露

Android應用程序被限制在16MB的堆上運行，至少在T-Mobile G1上是這樣。對於手機來說，這是很大的內存了；但對於一些開發人員來說，這算是較小的了。即使你不打算使用掉所有的內存，但是，你也應該盡可能少地使用內存，來確保其它應用程序得以運行。Android在內存中保留更多的應用程序，對於用戶來說，程序間切換就能更快。作為我（英文作者）工作的一部分，我調查了Android應用程序的內存洩露問題，並發現這些內存洩露大多數都是由於相同的錯誤導致的，即：對Context擁有較長時間的引用。
在Android上，Context常用於許多操作，更多的時候是加載和訪問資源。這就是為什麼所有的Widget在它們的構造函數裡接受一個Context的參數。在一個正常的Android應用程序裡，你會看到兩種Context類型，Activity和Application。而一般在需要一個Context的類和方法裡，往往傳入的是第一種：

@Override
protected void onCreate(Bundle state) {

  super.onCreate(state);

  TextView label = new TextView(this);
  label.setText(Leaks are bad);
  setContentView(label);

}

這意味著，View擁有對整個Activity的引用以及Activity自身擁有的所有內容；一般是整個的View層次和它的所有資源。因此，如果你“洩露”了Context（“洩露”指你保留了一個引用，阻止了GC的垃圾回收），你將洩露很多的內存。如果你不夠仔細的話，很容易就能洩露一個Activity。
當屏幕的方向發生改變時，一般系統會銷毀當前的Activity並創建一個新的，並保存它的狀態。當系統這樣做時，Android會從資源中重新加載應用程序的UI。假設你寫的應用程序擁有大的位圖，而你又不想在每次旋轉時重新加載它。這裡有最簡單的方式，那就是在一個靜態的字段裡進行保存：

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擁有了更多的對象引用（依賴於你的代碼）。

這是最容易洩露Context的例子之一，你可以看看Home Screen源代碼裡是如何處理的（搜索unbindDrawables()方法）：當Activity銷毀時，設定存儲的Drawable的callback為null。有趣的是，還有很多一連串的Context洩露情況，並且是非常糟糕的。這些情況會使得應用程序很快耗盡內存。

這裡，有兩種簡單的方式可以避免與Context相關的內存洩露。最顯而易見的一種方式是避免將Context超出它自己的范圍。上面的例子代碼給出的靜態引用，還有內部類和它們對外部類的隱式引用也是很危險的。第二種解決方案是使用Application這種Context類型。這種Context擁有和應用程序一樣長的生命周期，並且不依賴Activity的生命周期。如果你打算保存一個長時間的對象，並且其需要一個Context，記得使用Application對象。你可以通過調用Context.getApplicationContext()或Activity.getApplication()輕松得到Application對象。

概括一下，避免Context相關的內存洩露，記住以下事情：

1、不要保留對Context-Activity長時間的引用（對Activity的引用的時候，必須確保擁有和Activity一樣的生命周期）

2、 嘗試使用Context-Application來替代Context-Activity

3、 如果你不想控制內部類的生命周期，應避免在Activity中使用非靜態的內部類，而應該使用靜態的內部類，並在其中創建一個對Activity的弱引用。這種情況的解決辦法是使用一個靜態的內部類，其中擁有對外部類的WeakReference，如同ViewRoot和它的Winner類那樣

4、 GC（垃圾回收）不能解決內存洩露問題

Android(Java)中常見的容易引起內存洩漏的不良代碼：

轉載自http://mzh3344258.blog.51cto.com/1823534/895093

Android主要應用在嵌入式設備當中，而嵌入式設備由於一些眾所周知的條件限制，通常都不會有很高的配置，特別是內存是比較有限的。如果我們編寫的代 碼當中有太多的對內存使用不當的地方，難免會使得我們的設備運行緩慢，甚至是死機。為了能夠使得Android應用程序安全且快速的運行，Android 的每個應用程序都會使用一個專有的Dalvik虛擬機實例來運行，它是由Zygote服務進程演變過來的，也就是說每個應用程序都是在屬於自己的進程中運行的（問題一：這個地方小馬怎麼知道是在屬於自己的進程中運行的？大家繼續，答案小馬會在下面詳細介紹）。一方面，如果程序在運行過程中出現了內存洩漏的問題，僅僅會使得自己的進程被殺掉，而不會影響其他進程（如果是system_process 等系統進程出問題的話，則會引起系統重啟）。另一方面Android為不同類型的進程分配了不同的內存使用上限，如果應用進程使用的內存超過了這個上限， 則會被系統視為內存洩漏，從而被殺掉

下面小馬來解釋下問題一：”每個應用程序都是在屬於自己的進程中運行的”這句話，對於這句話，大家只記住一點：“當一個程序第一次啟動的時候，Android會啟動一個LINUX進程和一個主線程。默認的情況下，所有該程序的組件都將在該進程和線程中運行。”~^_^ O_O ！！！

同時，Android會為每個應用程序分配一個單獨的LINUX用戶。Android會盡量保留一個正在運行進程，只在內存資源出現不足時，Android會嘗試停止一些進程從而釋放足夠的資源給其他新的進程使用， 也能保證用戶正在訪問的當前進程有足夠的資源去及時地響應用戶的事件。Android會根據進程中運行的組件類別以及組件的狀態來判斷該進程的重要性，Android會首先停止那些不重要的進程。按照重要性從高到低一共有五個級別就是我們常說的：前台進程、可見進程、服務進程、後台進程、空進程（此處概念略，大家自己查）

還有個小擴展：當一個程序第一次啟動時，Android會同時啟動一個對應的主線程（Main Thread），主線程主要負責處理與UI相關的事件，如用戶的按鍵事件，用戶接觸屏幕的事件以及屏幕繪圖事件，並把相關的事件分發到對應的組件進行處理。所以主線程通常又被叫做UI線程。在開發Android應用時必須遵守單線程模型的原則： Android UI操作並不是線程安全的並且這些操作必須在UI線程中執行。Android的UI是單線程(Single-threaded)的。為了避免拖住GUI，一些較費時的對象應該交給獨立的線程去執行。如果幕後的線程來執行UI對象，Android就會發出錯誤訊息 CalledFromWrongThreadException。以後遇到這樣的異常拋出時就要知道怎麼回事咯！

造成內存洩露的原因舉例：

1. 查詢數據庫沒有關閉游標

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

Cursor cursor = getContentResolver().query(uri ...); 
if (cursor.moveToNext()) { 
  ... ... 
} 
 修正示例代碼： 
Cursor cursor = null; 
try { 
  cursor = getContentResolver().query(uri ...); 
  if (cursor != null && cursor.moveToNext()) { 
  ... ... 
  } 
} finally { 
  if (cursor != null) { 
  try { 
  cursor.close(); 
  } catch (Exception e) { 
  //ignore this 
  } 
  } 
} 

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對象的話，即浪費時間，也造成內存垃圾，給垃圾回收增加壓力，如果垃圾回收來不及的話，虛擬機將不得不給該應用進程分配更多的內存，造成不必要的內存開支。

3. Bitmap對象不在使用時調用recycle()沒有及時釋放

如果一個Bitmap對象比較占內存，當它不在被使用的時候，可以調用Bitmap.recycle()方法回收此對象的像素所占用的內存

4.沒有及時釋放對象的引用

簡單舉個例子：比如兩個Activity之間傳遞的Context 或其它的自定義對象，使用完後必須立即釋放 即：Activity = null ; Context = null ; Object = null;可以的話在這釋放對象之後通知系統來回收：System.gc();這樣最好了！

5.注冊沒取消造成的內存洩露

這種Android的內存洩露比純java的內存洩露還要嚴重，因為其他一些Android程序可能引用我們的Anroid程序的對象（比如注冊機制）。即使我們的Android程序已經結束了，但是別的引用程序仍然還有對我們的Android程序的某個對象的引用，洩露的內存依然不能被垃圾回收。

比如

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

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

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

6.集合容器對象沒清理造成的內存洩露

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

7.static關鍵字的濫用 當類的成員變量聲明成static後，它是屬於類的而不是屬於對象的，如果我們將很大的資源對象（Bitmap，context等）聲明成static，那麼這些資源不會隨著對象的回收而回收， 會一直存在，所以在使用static關鍵字定義成員變量的時候要慎重。 8 .WebView對象沒有銷毀 當我們不要使用WebView對象時，應該調用它的destory()函數來銷毀它，並釋放其占用的內存，否則其占用的內存長期也不能被回收，從而造成內存洩露 9.GridView的濫用 GridView和ListView的實現方式不太一樣。GridView的View不是即時創建的，而是全部保存在內存中的。比如一個GridView有100項，雖然我們只能看到10項，但是其實整個100項都是在內存中的。