Android開發(fā)內(nèi)存泄漏及檢查工具使用培訓資料

1、Android 開發(fā)內(nèi)存泄漏及檢查工具使用培訓資料目錄1內(nèi)存泄露 31.1 內(nèi)存泄露的概念 31.2 開發(fā)人員注意事項 41.3 Android（java）中常見的引起內(nèi)存泄露的代碼示例 41.3.1查詢數(shù)據(jù)庫沒有關(guān)閉游標 61.3.2 構(gòu)造Adapter時，沒有使用緩存的convertView 61.3.3 Bitmap對象不在使用時調(diào)用recycle(釋放內(nèi)存 71.3.4 釋放對象的引用 81.3.5 其他 92內(nèi)存泄露的分析工具 92.1 內(nèi)存監(jiān)測工具DDMS -> Heap 92.2 內(nèi)存分析工具MAT (Memory Analyzer Tool 102.2.1 生成.hpro

2、f文件 102.2.2 使用MAT導入.hprof文件 112.2.3 使用MAT的視圖工具分析內(nèi)存 121內(nèi)存泄露Android 應(yīng)用程序開發(fā)以Java語言為主，而Java編程中一個非常重要但卻經(jīng)常被忽視的問題就是內(nèi)存使用的問題。Java的垃圾回收機制(Garbage Collection 以下簡稱GC使得很多開發(fā)者并不關(guān)心內(nèi)存使用的生命周期，只顧著申請內(nèi)存，卻不手動釋放廢棄的內(nèi)存，而造成內(nèi)存泄露，引起很多問題，甚至程序崩潰。Android的虛擬機Dalvik VM和java虛擬機JVM沒有什么太大的區(qū)別，只是在字節(jié)碼上稍做優(yōu)化，所以Android應(yīng)用開發(fā)中同樣會出現(xiàn)內(nèi)存泄露的問題。而且由于

3、Android智能平臺主要用于嵌入式產(chǎn)品開發(fā)，可用的內(nèi)存資源更加稀少，所以對于我們Android應(yīng)用開發(fā)人員來說，就更該了解Android程序的內(nèi)存管理機制，避免內(nèi)存泄露的發(fā)生。1.1 內(nèi)存泄露的概念在計算機科學中，內(nèi)存泄漏(memory leak指由于疏忽或錯誤造成程序未能釋放已經(jīng)不再使用的內(nèi)存的情況。內(nèi)存泄漏并非指內(nèi)存在物理上的消失，而是應(yīng)用程序分配某段內(nèi)存后，由于設(shè)計錯誤，失去了對該段內(nèi)存的控制，因而造成了內(nèi)存的浪費。內(nèi)存泄漏與許多其他問題有著相似的癥狀，并且通常情況下只能由那些可以獲得程序源代碼的程序員才可以分析出來。然而，有不少人習慣于把任何不需要的內(nèi)存使用的增加描述為內(nèi)存泄漏，嚴格

4、意義上來說這是不準確的。一般我們常說的內(nèi)存泄漏是指堆內(nèi)存的泄漏。堆內(nèi)存是指程序從堆中分配的，大小任意的（內(nèi)存塊的大小可以在程序運行期決定），使用完后必須顯式釋放的內(nèi)存。應(yīng)用程序一般使用malloc，calloc，realloc，new等函數(shù)從堆中分配到一塊內(nèi)存，使用完后，程序必須負責相應(yīng)的調(diào)用free或delete釋放該內(nèi)存塊，否則，這塊內(nèi)存就不能被再次使用，我們就說這塊內(nèi)存泄漏了。這里我們只簡單的理解，在java程序中，如果已經(jīng)不再使用一個對象，但是仍然有引用指向它，GC就無法收回它，當然該對象占用的內(nèi)存就無法再被使用，這就造成內(nèi)存泄露?？赡芤粋€實例對象的內(nèi)存泄露很小，并不會引起很大的問題。

5、但是如果程序反復(fù)做此操作或者長期運行，造成內(nèi)存不斷泄露，終究會使程序無內(nèi)存可用，只好被系統(tǒng)kill掉。在以下情況，內(nèi)存泄漏導致較嚴重的后果： * 程序運行后置之不理，并且隨著時間的流失消耗越來越多的內(nèi)存（比如服務(wù)器上的后臺任務(wù)，尤其是嵌入式系統(tǒng)中的后臺任務(wù)，這些任務(wù)可能被運行后很多年內(nèi)都置之不理）；* 新的內(nèi)存被頻繁地分配，比如當顯示電腦游戲或動畫視頻畫面時；* 程序能夠請求未被釋放的內(nèi)存（比如共享內(nèi)存），甚至是在程序終止的時候；* 泄漏在操作系統(tǒng)內(nèi)部發(fā)生；* 泄漏在系統(tǒng)關(guān)鍵驅(qū)動中發(fā)生；* 內(nèi)存非常有限，比如在嵌入式系統(tǒng)或便攜設(shè)備中；* 當運行于一個終止時內(nèi)存并不自動釋放的操作系統(tǒng)（比如Ami

6、gaOS）之上，而且一旦丟失只能通過重啟來恢復(fù)。1.2 開發(fā)人員注意事項對于開發(fā)者，對待內(nèi)存泄露應(yīng)該以防為主，以治為輔，因為一旦造成內(nèi)存泄露，追查原因并不容易，雖然有工具可以利用，但是還是會耗費不必要的時間和精力來分析內(nèi)存使用報告和反復(fù)搜查代碼。為了開發(fā)高性能和高質(zhì)量的軟件，防止出現(xiàn)豆腐渣工程的出現(xiàn)，我們要知道什么時候用gc什么時候用recycle以及到底用不用finalization，因為 Java 對內(nèi)存的分配只需要new開發(fā)者不需要顯示的釋放內(nèi)存，但是這樣造成的內(nèi)存泄露問題的幾率反而更高。我們還需要：1.了解 Java 的四種引用方式，比如強引用，軟引用，弱引用以及虛引用。一些復(fù)雜些的程

7、序在長期運行很可能出現(xiàn)類似OutOfMemoryError 的異常。2.并不要過多的指望gc，不用的對象可以顯示的設(shè)置為空，比如 obj=null，這里 提示大家，java的gc使用的是一個有向圖，判斷一個對象是否有效看的是其他的對象能到達這個對象的頂點，有向圖的相對于鏈表、二叉樹來說開銷是可想而知。3.Android 為每個程序分配的對內(nèi)存可以通過Runtime類的totalMemory( freeM emory( 兩個方法獲取VM的一些內(nèi)存信息，對于系統(tǒng)heap內(nèi)存獲取，可以通過 Da lvik.VMRuntime 類的getMinimumHeapSize(方法獲取最小可用堆內(nèi)存，同時顯示

8、釋放軟引用可以調(diào)用該類的gcSoftReferences(方法，獲取更多的運行內(nèi)存。4.對于多線程的處理，如果并發(fā)的線程很多，同時有頻繁的創(chuàng)建和釋放，可以通過concurrent類的線程池解決線程創(chuàng)建的效率瓶頸。5.不要在循環(huán)中創(chuàng)建過多的本地變量。Java中的引用簡介：在Java中內(nèi)存管理，引用分為四大類，強引用 HardReference、弱引用WeakReference、軟引用SoftReference 和虛引用PhantomReference。它們的區(qū)別也很明顯，HardReference 對象是即使虛擬機內(nèi)存吃緊拋出 OOM 也不會導致這一引用的對象被回收，而 WeakReferenc

9、e等更適合于一些數(shù)量不多，但體積稍微龐大的對象，在這四個引用中，它是最容易被垃圾回收的，而我們對于顯示類似 Android Market 中每個應(yīng)用的AppIcon時可以考慮使用SoftReference來解決內(nèi)存不至于快速回收，同時當內(nèi)存短缺面臨JavaVM崩潰拋出OOM前時，軟引用將會強制回收內(nèi)存，最后的虛引用一般沒有實際意義，僅僅觀察GC的活動狀態(tài)，對于測試比較實用同時必須和ReferenceQueue一起使用。對于一組數(shù)據(jù)，我們可以通過HashMap的方式來添加一組SoftReference對象來臨時保留一些數(shù)據(jù)，同時對于需要反復(fù)通過網(wǎng)絡(luò)獲取的不經(jīng)常改變的內(nèi)容，可以通過本地的文件系統(tǒng)或

10、數(shù)據(jù)庫來存儲緩存。1.3 Android（java）中常見的引起內(nèi)存泄露的代碼示例Android 主要應(yīng)用在嵌入式設(shè)備當中，而嵌入式設(shè)備由于一些眾所周知的條件限制，通常都不會有很高的配置，特別是內(nèi)存是比較有限的。如果我們編寫的代碼當中有太多的對內(nèi)存使用不當?shù)牡胤?，難免會使得我們的設(shè)備運行緩慢，甚至是死機。為了能夠使得Android應(yīng)用程序安全且快速的運行，Android 的每個應(yīng)用程序都會使用一個專有的Dalvik 虛擬機實例來運行，它是由Zygote 服務(wù)進程孵化出來的，也就是說每個應(yīng)用程序都是在屬于自己的進程中運行的。一方面，如果程序在運行過程中出現(xiàn)了內(nèi)存泄漏的問題，僅僅會使得自己的進程被

11、kill 掉，而不會影響其他進程（如果是system_process 等系統(tǒng)進程出問題的話，則會引起系統(tǒng)重啟）。另一方面Android 為不同類型的進程分配了不同的內(nèi)存使用上限，如果應(yīng)用進程使用的內(nèi)存超過了這個上限，則會被系統(tǒng)視為內(nèi)存泄漏，從而被kill 掉。Android 為應(yīng)用進程分配的內(nèi)存上限如下所示：位置： /ANDROID_SOURCE/system/core/rootdir/init.rc 部分腳本# Define the oom_adj values for the classes of processes that can be# killed by the kernel. T

12、hese are used in ActivityManagerService.setprop ro.FOREGROUND_APP_ADJ 0setprop ro.VISIBLE_APP_ADJ 1setprop ro.SECONDARY_SERVER_ADJ 2setprop ro.BACKUP_APP_ADJ 2setprop ro.HOME_APP_ADJ 4setprop ro.HIDDEN_APP_MIN_ADJ 7setprop ro.CONTENT_PROVIDER_ADJ 14setprop ro.EMPTY_APP_ADJ 15# Define the memory thre

13、sholds at which the above process classes will# be killed. These numbers are in pages (4k.setprop ro.FOREGROUND_APP_MEM 1536setprop ro.VISIBLE_APP_MEM 2048setprop ro.SECONDARY_SERVER_MEM 4096setprop ro.BACKUP_APP_MEM 4096setprop ro.HOME_APP_MEM 4096setprop ro.HIDDEN_APP_MEM 5120setprop ro.CONTENT_PR

14、OVIDER_MEM 5632setprop ro.EMPTY_APP_MEM 6144# Write value must be consistent with the above properties.# Note that the driver only supports 6 slots, so we have HOME_APP at the# same memory level as services.write /sys/module/lowmemorykiller/parameters/adj 0,1,2,7,14,15write /proc/sys/vm/overcommit_m

15、emory 1write /proc/sys/vm/min_free_order_shift 4write /sys/module/lowmemorykiller/parameters/minfree1536,2048,4096,5120,5632,6144# Set init its forked children's oom_adj.write /proc/1/oom_adj -16正因為我們的應(yīng)用程序能夠使用的內(nèi)存有限，所以在編寫代碼的時候需要特別注意內(nèi)存使用問題。如下是一些常見的內(nèi)存使用不當?shù)那闆r。1.3.1查詢數(shù)據(jù)庫沒有關(guān)閉游標描述：程序中經(jīng)常會進行查詢數(shù)據(jù)庫的操作，但是經(jīng)常

16、會有使用完畢Cursor 后沒有關(guān)閉的情況。如果我們的查詢結(jié)果集比較小，對內(nèi)存的消耗不容易被發(fā)現(xiàn)，只有在常時間大量操作的情況下才會復(fù)現(xiàn)內(nèi)存問題，這樣就會給以后的測試和問題排查帶來困難和風險。示例代碼：Cursor cursor = getContentResolver(.query(uri .;if (cursor.moveToNext( . .修正示例代碼：Cursor cursor = null;try cursor = getContentResolver(.query(uri .;if (cursor != null && cursor.moveToNext( . .

17、finally if (cursor != null try cursor.close(; catch (Exception e /ignore this1.3.2 構(gòu)造Adapter時，沒有使用緩存的convertView描述：以構(gòu)造ListView 的BaseAdapter 為例，在BaseAdapter 中提高了方法：public View getView(int position, View convertView, ViewGroup parent來向ListView 提供每一個item 所需要的view 對象。初始時ListView 會從BaseAdapter 中根據(jù)當前的屏幕布局

18、實例化一定數(shù)量的view 對象，同時ListView 會將這些view 對象緩存起來。當向上滾動ListView 時，原先位于最上面的list item 的view 對象會被回收，然后被用來構(gòu)造新出現(xiàn)的最下面的list item。這個構(gòu)造過程就是由getView(方法完成的，getView(的第二個形參View convertView 就是被緩存起來的list item 的view 對象(初始化時緩存中沒有view對象則convertView 是null。由此可以看出，如果我們不去使用convertView，而是每次都在getView(中重新實例化一個View 對象的話，即浪費資源也浪費時間，

19、也會使得內(nèi)存占用越來越大。ListView 回收listitem 的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 p

20、arent View view = null;if (convertView != null view = convertView;populate(view, getItem(position;. else view = new Xxx(.;.return view;1.3.3 Bitmap對象不在使用時調(diào)用recycle(釋放內(nèi)存描述：有時我們會手工的操作Bitmap 對象，如果一個Bitmap 對象比較占內(nèi)存，當它不在被使用的時候，可以調(diào)用Bitmap.recycle(方法回收此對象的像素所占用的內(nèi)存，但這不是必須的，視情況而定?？梢钥匆幌麓a中的注釋：/* Free up the me

21、mory associated with this bitmap's pixels, and mark the* bitmap as "dead", meaning it will throw an exception if getPixels( or* setPixels( is called, and will draw nothing. This operation cannot be* reversed, so it should only be called if you are sure there are no* further uses for th

22、e bitmap. This is an advanced call, and normally need* not be called, since the normal GC process will free up this memory when* there are no more references to this bitmap.*/1.3.4 釋放對象的引用描述：這種情況描述起來比較麻煩，舉兩個例子進行說明。示例A：假設(shè)有如下操作public class DemoActivity extends Activity . .private Handler mHandler = .p

23、rivate Object obj;public void operation( obj = initObj(;.MarkmHandler.post(new Runnable( public void run( useObj(obj;我們有一個成員變量obj，在operation(中我們希望能夠?qū)⑻幚韔bj 實例的操作post 到某個線程的MessageQueue 中。在以上的代碼中，即便是mHandler 所在的線程使用完了obj所引用的對象，但這個對象仍然不會被垃圾回收掉，因為DemoActivity.obj 還保有這個對象的引用。所以如果在DemoActivity 中不再使用這個對象了，

24、可以在Mark的位置釋放對象的引用，而代碼可以修改為：. .public void operation( obj = initObj(;.final Object o = obj;obj = null;mHandler.post(new Runnable( public void run( useObj(o;. .示例B:假設(shè)我們希望在鎖屏界面(LockScreen中，監(jiān)聽系統(tǒng)中的電話服務(wù)以獲取一些信息(如信號強度等，則可以在LockScreen 中定義一個PhoneStateListener 的對象，同時將它注冊到TelephonyManager 服務(wù)中。對于LockScreen 對象，當需

25、要顯示鎖屏界面的時候就會創(chuàng)建一個LockScreen 對象，而當鎖屏界面消失的時候LockScreen 對象就會被釋放掉。但是如果在釋放LockScreen 對象的時候忘記取消我們之前注冊的PhoneStateListener 對象，則會導致LockScreen 無法被垃圾回收。如果不斷的使鎖屏界面顯示和消失，則最終會由于大量的LockScreen 對象沒有辦法被回收而引起OutOfMemory,使得system_process 進程掛掉?？傊斠粋€生命周期較短的對象A，被一個生命周期較長的對象B 保有其引用的情況下，在A 的生命周期結(jié)束時，要在B 中清除掉對A 的引用。1.3.5 其他And

26、roid 應(yīng)用程序中最典型的需要注意釋放資源的情況是在Activity 的生命周期中，在onPause(、onStop(、onDestroy(方法中需要適當?shù)尼尫刨Y源的情況。由于此情況很基礎(chǔ)，在此不詳細說明，具體可以查看官方文檔對Activity 生命周期的介紹，以明確何時應(yīng)該釋放哪些資源。2內(nèi)存泄露的分析工具2.1 內(nèi)存監(jiān)測工具DDMS -> Heap無論怎么小心，想完全避免bad code也很困難，此時就需要一些工具來幫助我們檢查代碼中是否存在會造成內(nèi)存泄漏的地方。Android tools中的DDMS就帶有一個很不錯的內(nèi)存監(jiān)測工具Heap(這里我使用eclipse 的ADT 插件，

27、并以真機為例，在模擬器中的情況類似。用Heap監(jiān)測應(yīng)用進程使用內(nèi)存情況的步驟如下：1. 啟動eclipse后，切換到DDMS 視圖，并確認Devices 視圖、Heap 視圖都是打開的；2. 將設(shè)備通過USB 鏈接至電腦，鏈接時需要確認手機是處于“USB 調(diào)試”模式，而不是作為“Mass Storage”；3. 鏈接成功后，在DDMS 的Devices 視圖中將會顯示手機設(shè)備的序列號，以及設(shè)備中正在運行的部分進程信息；4. 點擊選中想要監(jiān)測的進程，比如system_process 進程；5. 點擊選中Devices 視圖界面中最上方一排圖標中的“Update Heap”圖標；6. 點擊Heap

28、 視圖中的“Cause GC”按鈕；7. 此時在Heap 視圖中就會看到當前選中的進程的內(nèi)存使用量的詳細情況如圖所示。說明：a 點擊“Cause GC”按鈕相當于向虛擬機請求了一次gc 操作；b 當內(nèi)存使用信息第一次顯示以后，無須再不斷的點擊“Cause GC”，Heap 視圖界面會定時刷新，在對應(yīng)用的不斷的操作過程中就可以看到內(nèi)存使用的變化；c 內(nèi)存使用信息的各項參數(shù)根據(jù)名稱即可知道其意思，在此不再贅述。如何才能知道我們的程序是否有內(nèi)存泄漏的可能性呢。這里需要注意一個值：Heap 視圖中部有一個Type 叫做data object，即數(shù)據(jù)對象，也就是我們的程序中大量存在的類類型的對象。點擊“

29、Data Object”這一行，會產(chǎn)生Allocation count per size的統(tǒng)計圖。在data object 一行中有一列是“Total Size”，其值就是當前進程中所有Java 數(shù)據(jù)對象的內(nèi)存總量，一般情況下，這個值的大小決定了是否會有內(nèi)存泄漏?？梢赃@樣判斷：a 不斷的操作當前應(yīng)用，同時注意觀察data object 的Total Size 值；b 正常情況下Total Size 值都會穩(wěn)定在一個有限的范圍內(nèi)，也就是說由于程序中的的代碼良好，沒有造成對象不被垃圾回收的情況，所以說雖然我們不斷的操作會不斷的生成很多對象，而在虛擬機不斷的進行GC 的過程中，這些對象都被回收了，內(nèi)

30、存占用量會會落到一個穩(wěn)定的水平；c 反之如果代碼中存在沒有釋放對象引用的情況，則data object 的Total Size 值在每次GC后不會有明顯的回落，隨著操作次數(shù)的增多Total Size 的值會越來越大，直到到達一個上限后導致進程被kill 掉。d 此處已system_process 進程為例，在我的測試環(huán)境中system_process 進程所占用的內(nèi)存的data object 的Total Size 正常情況下會穩(wěn)定在2.22.8 之間，而當其值超過3.55 后進程就會被kill。總之，使用DDMS 的Heap 視圖工具可以很方便的確認我們的程序是否存在內(nèi)存泄漏的可能性。2.2

31、 內(nèi)存分析工具MAT (Memory Analyzer Tool如果使用DDMS 確實發(fā)現(xiàn)了我們的程序中存在內(nèi)存泄漏，那又如何定位到具體出現(xiàn)問題的代碼片段，最終找到問題所在呢？如果從頭到尾的分析代碼邏輯，那肯定會把人逼瘋，特別是在維護別人寫的代碼的時候。這里介紹一個極好的內(nèi)存分析工具- Memory Analyzer Tool(MAT。MAT 是一個Eclipse 插件，同時也有單獨的RCP 客戶端。官方下載地址、MAT 介紹和詳細的使用教程請參見：/mat，在此不進行說明了。另外在MAT 安裝后的幫助文檔里也有完備的使用教程。在此僅舉例說明其使用方法。我自己使用

32、的是MAT 的eclipse 插件，使用插件要比RCP 稍微方便一些。插件安裝地址：/mat/1.1/update-site，請在eclipse->Help->Install new software中安裝使用MAT 進行內(nèi)存分析需要幾個步驟，包括：生成.hprof 文件、打開MAT 并導入.hprof文件、使用MAT 的視圖工具分析內(nèi)存。以下詳細介紹。2.2.1 生成.hprof文件1. 打開eclipse 并切換到DDMS 視圖，同時確認Devices、Heap 和logcat 視圖已經(jīng)打開了；2. 將設(shè)備鏈接到電腦，并確保使

33、用“USB 調(diào)試”模式鏈接；3. 鏈接成功后在Devices 視圖中就會看到設(shè)備的序列號，和設(shè)備中正在運行的部分進程；4. 點擊選中想要分析的應(yīng)用的進程，在Devices 視圖上方的一行圖標按鈕中，同時選中“Update Heap”和“Dump HPROF file”兩個按鈕；5. 這是DDMS 工具將會自動生成當前選中進程的.hprof 文件，并將其進行轉(zhuǎn)換后存放在sdcard 當中，如果你已經(jīng)安裝了MAT 插件，那么此時MAT 將會自動被啟用，并開始對.hprof文件進行分析；注意：第4 步和第5 步能夠正常使用前提是我們需要有sdcard，并且當前進程有向sdcard中寫入的權(quán)限(WRI

34、TE_EXTERNAL_STORAGE，否則.hprof 文件不會被生成，在logcat 中會顯示諸如ERROR/dalvikvm(8574: hprof: can't open /sdcard/com.xxx.hprof-hptemp: Permission denied.的信息。如果我們沒有sdcard，或者當前進程沒有向sdcard 寫入的權(quán)限（如system_process）， 那我們可以這樣做：6. 在當前程序中，例如framework 中某些代碼中，可以使用android.os.Debug 中的：public static void dumpHprofData(String

35、 fileName throws IOException方法，手動的指定.hprof 文件的生成位置。例如：xxxButton.setOnClickListener(new View.OnClickListener( public void onClick(View view android.os.Debug.dumpHprofData("/data/temp/myapp.hprof". .上述代碼意圖是希望在xxxButton 被點擊的時候開始抓取內(nèi)存使用信息，并保存在我們指定的位置：/data/temp/myapp.hprof，這樣就沒有權(quán)限的限制了，而且也無須用sdc

36、ard。但要保證/data/temp 目錄是存在的。這個路徑可以自己定義，當然也可以寫成sdcard 當中的某個路徑。2.2.2 使用MAT導入.hprof文件1. 如果是eclipse 自動生成的.hprof 文件，可以使用MAT 插件直接打開（可能是比較新的ADT才支持）；2. 如果eclipse 自動生成的.hprof 文件不能被MAT 直接打開， 或者是使用android.os.Debug.dumpHprofData(方法手動生成的.hprof 文件，則需要將.hprof 文件進行轉(zhuǎn)換，轉(zhuǎn)換的方法：例如我將.hprof 文件拷貝到PC 上的/ANDROID_SDK/tools 目錄下，

37、并輸入命令hprofconv xxx.hprof yyy.hprof，其中xxx.hprof 為原始文件，yyy.hprof 為轉(zhuǎn)換過后的文件。轉(zhuǎn)換過后的文件自動放在/ANDROID_SDK/tools 目錄下。OK，到此為止，.hprof 文件處理完畢，可以用來分析內(nèi)存泄露情況了。3. 在Eclipse 中點擊Windows->Open Perspective->Other->Memory Analyzer，或者打Memory Analyzer Tool 的RCP。在MAT 中點擊File->Open File，瀏覽并導入剛剛轉(zhuǎn)換而得到的.hprof文件。2.2.3

38、使用MAT的視圖工具分析內(nèi)存導入.hprof 文件以后，MAT 會自動解析并生成報告，點擊Dominator Tree，并按Package分組，選擇自己所定義的Package 類點右鍵，在彈出菜單中選擇List objects->With incomingreferences。這時會列出所有可疑類，右鍵點擊某一項，并選擇Path to GC Roots -> exclude weak/soft references，會進一步篩選出跟程序相關(guān)的所有有內(nèi)存泄露的類。據(jù)此，可以追蹤到代碼中的某一個產(chǎn)生泄露的類。以下是MAT使用時的兩個個簡單示例：例子1：將packages/app/Bro

39、wser中的BrowserHistoryPage.java 中為ListView配置的Adapter是HistoryAdapter，在HistoryAdapter的getGroupView 和getChildView中不再使用緩存中存在的convertView，每次new 一個View。由此產(chǎn)生內(nèi)存泄漏分析過程：用MAT打開 .hprof文件，選擇“Leak Suspect Report”，從Leak Suspect可以看到占用內(nèi)存從多到少排列，列出的可疑的類。由于heap dump 的時機不同，對于占用內(nèi)存最多的類的分析結(jié)果不一樣。Leak Suspects 會列出android.content.res.Resources為占用內(nèi)存最多的類。三次heap dump的結(jié)果，有兩次是分析android.app.FragmentManagerImpl占用內(nèi)存次之，有一次分析出android.widget.ListView占用內(nèi)存僅次于android.content.res.Resources。下面分析的基礎(chǔ)是推斷android.widget.ListView是主要造成內(nèi)存泄漏的類：打開“object Histogram”從Class Name 的第一行篩選出 ListView選擇android.widget.ListView，由于它是一個基礎(chǔ) 類，點擊左鍵->List