標籤：
什麼是記憶體泄露
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<Activity > mActivityReference;
MyHandler(Activity activity) {
mActivityReference= new WeakReference<Activity>(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>
其中，package_name 也可以換成程式的pid，pid可以通過 adb shell top | grep app_name 來尋找。
（1） Native/Dalvik 的 Heap 資訊
具體在上面的第一行和第二行，它分別給出的是JNI層和Java層的記憶體配置情況，如果發現這個值一直增長，則代表程式可能出現了記憶體流失。
（2） Total 的 PSS 資訊
這個值就是 的應用真正佔據的記憶體大小，通過這個資訊， 可以輕鬆判別手機中哪些程式占記憶體比較大了。
歡迎關注公眾帳號
Android記憶體泄露分析和處理
