無論怎么小心，想完全避免bad code是不可能的，此時(shí)就需要一些工具來幫助我們檢查代碼中是否存在會造成內(nèi)存泄漏的地方。
Android tools中的DDMS就帶有一個(gè)很不錯(cuò)的內(nèi)存監(jiān)測工具Heap(這里我使用eclipse的ADT插件，并以真機(jī)為例，在模擬器中的情況類似)。用 Heap監(jiān)測應(yīng)用進(jìn)程使用內(nèi)存情況的步驟如下：
1. 啟動(dòng)eclipse后，切換到DDMS透視圖，并確認(rèn)Devices視圖、Heap視圖都是打開的；
2. 將
手機(jī)通過USB鏈接至電腦，鏈接時(shí)需要確認(rèn)手機(jī)是處于“USB調(diào)試”模式，而不是作為“Mass Storage”；
3. 鏈接成功后，在DDMS的Devices視圖中將會顯示手機(jī)設(shè)備的序列號，以及設(shè)備中正在運(yùn)行的部分進(jìn)程信息；
4. 點(diǎn)擊選中想要監(jiān)測的進(jìn)程，比如system_process進(jìn)程；
5. 點(diǎn)擊選中Devices視圖界面中最上方一排圖標(biāo)中的“Update Heap”圖標(biāo)；
6. 點(diǎn)擊Heap視圖中的“Cause GC”按鈕；
7. 此時(shí)在Heap視圖中就會看到當(dāng)前選中的進(jìn)程的內(nèi)存使用量的詳細(xì)情況。
說明：
a) 點(diǎn)擊“Cause GC”按鈕相當(dāng)于向虛擬機(jī)請求了一次gc操作；
b) 當(dāng)內(nèi)存使用信息第一次顯示以后，無須再不斷的點(diǎn)擊“Cause GC”，Heap視圖界面會定時(shí)刷新，在對應(yīng)用的不斷的操作過程中就可以看到內(nèi)存使用的變化；
c) 內(nèi)存使用信息的各項(xiàng)參數(shù)根據(jù)名稱即可知道其意思，在此不再贅述。
如何才能知道我們的程序是否有內(nèi)存泄漏的可能性呢。這里需要注意一個(gè)值：Heap視圖中部有一個(gè)Type叫做data object，即數(shù)據(jù)對象，也就是我們的程序中大量存在的類類型的對象。在data object一行中有一列是“Total Size”，其值就是當(dāng)前進(jìn)程中所有Java數(shù)據(jù)對象的內(nèi)存總量，一般情況下，這個(gè)值的大小決定了是否會有內(nèi)存泄漏。可以這樣判斷：
a) 不斷的操作當(dāng)前應(yīng)用，同時(shí)注意觀察data object的Total Size值；
b) 正常情況下Total Size值都會穩(wěn)定在一個(gè)有限的范圍內(nèi)，也就是說由于程序中的的代碼良好，沒有造成對象不被垃圾回收的情況，所以說雖然我們不斷的操作會不斷的生成很多對 象，而在虛擬機(jī)不斷的進(jìn)行GC的過程中，這些對象都被回收了，內(nèi)存占用量會會落到一個(gè)穩(wěn)定的水平；
c) 反之如果代碼中存在沒有釋放對象引用的情況，則data object的Total Size值在每次GC后不會有明顯的回落，隨著操作次數(shù)的增多Total Size的值會越來越大，
直到到達(dá)一個(gè)上限后導(dǎo)致進(jìn)程被kill掉。
d) 此處已system_process進(jìn)程為例，在我的
測試環(huán)境中system_process進(jìn)程所占用的內(nèi)存的data object的Total Size正常情況下會穩(wěn)定在2.2~2.8之間，而當(dāng)其值超過3.55后進(jìn)程就會被kill。
總之，使用DDMS的Heap視圖工具可以很方便的確認(rèn)我們的程序是否存在內(nèi)存泄漏的可能性。
版權(quán)聲明：本文出自 smalllin 的51Testing軟件測試博客：http://www.51testing.com/?344504
原創(chuàng)作品，轉(zhuǎn)載時(shí)請務(wù)必以超鏈接形式標(biāo)明本文原始出處、作者信息和本聲明，否則將追究法律責(zé)任。