Android內存洩露分析和處理

什麼是內存洩露
Java使用有向圖機制，通過GC自動檢查內存中的對象，如果GC發現一個或一組對象為不可到達狀態，則將該對象從內存中回收。也就是說，一個對象不被任何引用所指向，則該對象會在被GC發現的時候被回收。

內存洩露的原因
1.資源對象沒關閉造成的內存洩漏
資源性對象比如 （Cursor，File文件等）往往都用了一些緩沖，我們在不使用的時候，應該及時關閉它們，以便它們的緩沖及時回收內存。它們的緩沖不僅存在於 java虛擬機內，還存在於java虛擬機外。如果我們僅僅是把它的引用設置為null,而不關閉它們，往往會造成內存洩漏。因為有些資源性對象，比如 SQLiteCursor（在析構函數finalize(),如果我們沒有關閉它，它自己會調close()關閉），如果我們沒有關閉它，系統在回收它時 也會關閉它，但是這樣的效率太低了。因此對於資源性對象在不使用的時候，應該調用它的close()函數，將其關閉掉，然後才置為null.在我們的程序 退出時一定要確保我們的資源性對象已經關閉。
程序中經常會進行查詢數據庫的操作，但是經常會有使用完畢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, ViewconvertView, 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 --> voidaddScrapView(View scrap) 方法。
示例代碼：
public View getView(int position, ViewconvertView, ViewGroup parent) {
View view = new Xxx(...);
... ...
return view;
}
修正示例代碼：
public View getView(int position, ViewconvertView, ViewGroup parent) {
View view = null;
if (convertView != null) {
view = convertView;
populate(view, getItem(position));
...
} else {
view = new Xxx(...);
...
}
return view;
}
3.Bitmap對象不在使用時調用recycle()釋放內存
有時我們會手工的操作Bitmap對象，如果一個Bitmap對象比較占內存，當它不在被使用的時候，可以調用Bitmap.recycle()方法回收此對象的像素所占用的內存，但這不是必須的，視情況而定。可以看一下代碼中的注釋：
/**
* Free up the memory associated with thisbitmap's pixels, and mark the
* bitmap as "dead", meaning itwill throw an exception if getPixels() or
* setPixels() is called, and will drawnothing. This operation cannot be
* reversed, so it should only be called ifyou are sure there are no
* further uses for the bitmap. This is anadvanced call, and normally need
* not be called, since the normal GCprocess will free up this memory when
* there are no more references to thisbitmap.
*/
4.試著使用關於application的context來替代和activity相關的context
這是一個很隱晦的內 存洩漏的情況。有一種簡單的方法來避免context相關的內存洩漏。最顯著地一個是避免context逃出他自己的范圍之外。使用 Application context。這個context的生存周期和 的應用的生存周期一樣長，而不是取決於activity的生存周期。如果 想保持一個長期生存的對象， 並且這個對象需要一個context,記得使用application對象。 可以通過調用 Context.getApplicationContext() or Activity.getApplication()來獲得。更多的請看這篇文章如何避免Android內存洩漏 （見 http://www.linuxidc.com/Linux/2012-02/52951.htm ）。
5.注冊沒取消造成的內存洩漏
一些Android 程序可能引用我們的Anroid程序的對象（比如注冊機制）。即使我們的Android程序已經結束了，但是別的引用程序仍然還有對我們的Android 程序的某個對象的引用，洩漏的內存依然不能被垃圾回收。調用registerReceiver後未調用unregisterReceiver。
比如:假設我們希望 在鎖屏界面(LockScreen)中，監聽系統中的電話服務以獲取一些信息(如信號強度等)，則可以在LockScreen中定義一個 PhoneStateListener的對象，同時將它注冊到TelephonyManager服務中。對於LockScreen對象，當需要顯示鎖屏界 面的時候就會創建一個LockScreen對象，而當鎖屏界面消失的時候LockScreen對象就會被釋放掉。
但是如果在釋放 LockScreen對象的時候忘記取消我們之前注冊的PhoneStateListener對象，則會導致LockScreen無法被垃圾回收。如果不 斷的使鎖屏界面顯示和消失，則最終會由於大量的LockScreen對象沒有辦法被回收而引起OutOfMemory,使得system_process 進程掛掉。
雖然有些系統程序，它本身好像是可以自動取消注冊的（當然不及時），但是我們還是應該在我們的程序中明確的取消注冊，程序結束時應該把所有的注冊都取消掉。
6.集合中對象沒清理造成的內存洩漏
我們通常把一些對象的引用加入到了集合中，當我們不需要該對象時，並沒有把它的引用從集合中清理掉，這樣這個集合就會越來越大。如果這個集合是static的話，那情況就更嚴重了。
7.Android中使用Handler造成內存洩露
Handler mHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
mImageView.setImageBitmap(mBitmap);
}
}
上面是一段簡單的Handler的使用。當使用內部類（包括匿名類）來創建Handler的時候，Handler對象會隱式地持有一個外部類對象（通常是一個Activity的引用）。而Handler通常會伴隨著一個耗 時的後台線程（例如從網絡拉取圖片）一起出現，這個後台線程在任務執行完畢（例如圖片下載完畢）之後，通過消息機制通知Handler，然後 Handler把圖片更新到界面。然而，如果用戶在網絡請求過程中關閉了Activity，正常情況下，Activity不再被使用，它就有可能在GC檢 查時被回收掉，但由於這時線程尚未執行完，而該線程持有Handler的引用，這個Handler又持有 Activity的引用，就導致該Activity無法被回收（即內存洩露），直到網絡請求結束（例如圖片下載完畢）。另外，如果 執行了Handler 的postDelayed（）方法，該方法會將Handler裝入一個Message，並把這條Message推到MessageQueue中，那麼 在設定的delay到達之前，會有一條MessageQueue -> Message -> Handler -> Activity的鏈，導致Activity被持有引用而無法被回收。

內存洩露的危害
虛擬機占用內存過高，導致OOM（內存溢出），程序出錯。對於Android應用來說，就是用戶打開一個Activity，使用完之後關閉它，內存洩露；又打開，又關閉，又洩露；幾次之後，程序占用內存超過系統限制，FC。

使用Handler導致內存洩露的解決方法
1.通過程序邏輯來進行保護。
（1）在關閉Activity的時候停掉 的後台線程。線程停掉了，就相當於切斷了Handler和外部連接的線，Activity自然會在合適的時候被回收。
（2）如果 的Handler是被delay的Message持有了引用，那麼使用相應的Handler的removeCallbacks()方法，把消息對象從消息隊列移除就行了。
2.將Handler聲明為靜態類。
靜態類不持有外部類的對象，所以 的Activity可以隨意被回收。代碼如下：
static class MyHandler extends Handler {
@Override
public void handleMessage(Message msg) {
mImageView.setImageBitmap(mBitmap);
}
}
但是這樣還是有問題由於Handler不再持有外部類對象的引用，導致程序不允許 在Handler中操作Activity中的對象了。所以 需要在Handler中增加一個對Activity的弱引用（WeakReference）：
static class MyHandler extends Handler {
WeakReference mActivityReference;

MyHandler(Activity activity) {
mActivityReference= new WeakReference(activity);
}

@Override
public void handleMessage(Message msg) {
final Activity activity = mActivityReference.get();
if (activity != null) {
mImageView.setImageBitmap(mBitmap);
}
}
}

延伸：什麼是WeakReference？
WeakReference弱引用，與強引用（即我們常說的引用）相對，它的特點是，GC在回收時會忽略掉弱引用，即就算有弱引用指向某對象，但只 要該對象沒有被強引用指向（實際上多數時候還要求沒有軟引用，但此處軟引用的概念可以忽略），該對象就會在被GC檢查到時回收掉。對於上面的代碼，用戶在 關閉Activity之後，就算後台線程還沒結束，但由於僅有一條來自Handler的弱引用指向Activity，所以GC仍然會在檢查的時候把 Activity回收掉。這樣，內存洩露的問題就不會出現了。

那麼，Android開發中，有什麼有效的方法可以檢測內存使用情況以及內存洩漏呢？
這裡主要介紹三種方法：
1. 程序的Log信息
程序在進行垃圾回收的時候，會打印一條Log信息（logcat窗口），例如：
D/dalvikvm( 9050): GC_CONCURRENT freed 2049K, 65% free 3571K/9991K, external 4703K/5261K, paused 2ms+2ms
注意這條信息中的 “ 3571K/9991K” 值，這代表著程序使用的heap大小，如果這個值一直在增加，而從來不減小，那麼就代表著 的程序存在著內存洩漏。
2. DDMS的Heap信息
Eclipse開發環境還提供了一種更加直觀的方法來查看App的Heap信息，操作方式如下：
Android開發實踐：檢測App的內存占用和洩漏
（1） 連接手機，運行程序，假設是 com.ticktick.test 程序
（2） 點擊DDMS按鈕，在左側的Device窗口選中 要檢測的程序（com.ticktick.test ）
（3） 點擊Device窗口工具欄的第二個圖標（Update Heap），
（4） 點擊右邊的窗口的Cause GC按鈕，即可得到當前程序的Heap信息
同樣，隨著程序的運行，多次點擊得到的Heap大小，如果只增不減的話，也昭示著 的程序有內存洩漏。
3. adb命令查看內存信息
其實，最全面最簡單的方式還是用adb命令來查看程序的內存占用和內存洩漏情況，打開命令行窗口，adb命令的格式如下：
adb shell dumpsys meminfo
其中，package_name 也可以換成程序的pid，pid可以通過 adb shell top | grep app_name 來查找。

（1） Native/Dalvik 的 Heap 信息
具體在上面的第一行和第二行，它分別給出的是JNI層和Java層的內存分配情況，如果發現這個值一直增長，則代表程序可能出現了內存洩漏。
（2） Total 的 PSS 信息

這個值就是 的應用真正占據的內存大小，通過這個信息， 可以輕松判別手機中哪些程序占內存比較大了。