android ddms heap內(nèi)存分析工具怎么使用
無論怎么小心,想完全避免bad code是不可能的,此時(shí)就需要一些工具來幫助我們檢查代碼中是否存在會(huì)造成內(nèi)存泄漏的地方。 Android tools中的DDMS就帶有一個(gè)很不錯(cuò)的內(nèi)存監(jiān)測(cè)工具Heap(這里我使用eclipse的ADT插件,并以真機(jī)為例,在模擬器中的情 況類似)。下面是學(xué)習(xí)啦小編為大家介紹android ddms heap內(nèi)存分析工具使用方法,歡迎大家閱讀。
android ddms heap內(nèi)存分析工具使用方法
1. 啟動(dòng)eclipse后,切換到DDMS視圖,并確認(rèn)Devices視圖、Heap視圖都是打開的;
2. 將手機(jī)通過USB鏈接至電腦,鏈接時(shí)需要確認(rèn)手機(jī)是處于“USB調(diào)試”模式;
3. 鏈接成功后,在DDMS的Devices視圖中將會(huì)顯示手機(jī)設(shè)備的序列號(hào),以及設(shè)備中正在運(yùn)行的部分進(jìn)程信息;
4. 點(diǎn)擊選中想要監(jiān)測(cè)的進(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視圖中就會(huì)看到當(dāng)前選中的進(jìn)程的內(nèi)存使用量的詳細(xì)情況[如圖所示]。
說明:
a) 點(diǎn)擊“Cause GC”按鈕相當(dāng)于向虛擬機(jī)請(qǐng)求了一次gc操作;
b) 當(dāng)內(nèi)存使用信息第一次顯示以后,無須再不斷的點(diǎn)擊“Cause GC”,Heap視圖界面會(huì)定時(shí)刷新,在對(duì)應(yīng)用的不斷的操作過程中就可以看到內(nèi)存使用的變化;
如何才能知道我們的程序是否有內(nèi)存泄漏的可能性呢。這里需要注意一個(gè)值:Heap視圖中部有一個(gè)Type叫做data object,即數(shù)據(jù)對(duì) 象,也就是我們的程序中大量存在的類類型的對(duì)象。在data object一行中有一列是“Total Size”,其值就是當(dāng)前進(jìn)程中所有Java數(shù)據(jù) 對(duì)象的內(nèi)存總量,一般情況下,這個(gè)值的大小決定了是否會(huì)有內(nèi)存泄漏??梢赃@樣判斷:
a) 不斷的操作當(dāng)前應(yīng)用,同時(shí)注意觀察data object的Total Size值;
b) 正 常情況下Total Size值都會(huì)穩(wěn)定在一個(gè)有限的范圍內(nèi),也就是說由于程序中的的代碼良好,沒有造成對(duì)象不被垃圾回收的情況,所以說雖然我們 不斷的操作會(huì)不斷的生成很多對(duì)象,而在虛擬機(jī)不斷的進(jìn)行GC的過程中,這些對(duì)象都被回收了,內(nèi)存占用量會(huì)會(huì)落到一個(gè)穩(wěn)定的水平;
c) 反之如果代碼中存在沒有釋放對(duì)象引用的情況,則data object的Total Size值在每次GC后不會(huì)有明顯的回落,隨著操作次數(shù)的增多Total Size的值會(huì)越來越大,
直到到達(dá)一個(gè)上限后導(dǎo)致進(jìn)程被kill掉。
d) 此處已system_process進(jìn)程為例,在我的測(cè)試環(huán)境中system_process進(jìn)程所占用的內(nèi)存的data object的Total Size正常情況下會(huì)穩(wěn)定在2.2~2.8之間,而當(dāng)其值超過3.55后進(jìn)程就會(huì)被kill。
總之,使用DDMS的Heap視圖工具可以很方便的確認(rèn)我們的程序是否存在內(nèi)存泄漏的可能性。
如果使用DDMS確實(shí)發(fā)現(xiàn)了我們的程序中存在內(nèi)存泄漏,那又如何定位到具體出現(xiàn)問題的代碼片段,最終找到問題所在呢?如果從頭到尾的分析代碼邏 輯,那肯定會(huì)把人逼瘋,特別是在維護(hù)別人寫的代碼的時(shí)候。這里介紹一個(gè)極好的內(nèi)存分析工具 -- Memory Analyzer Tool(MAT)。