手機(jī)性能測(cè)試

1、android手機(jī)性能測(cè)試測(cè)試工具DDMS(DalvikDebugMonitorService)安裝與配置1、首先安裝JDK,1.5以上的版本(目前javavuser不支持JDK1.7)2、在安裝完JDK后，就需要下載及安裝AndroidSDK，即：android-sdk-windows，壓縮包大約有551M左右3、解壓縮android-sdk-windows，放在C盤的根目錄下，配置系統(tǒng)變量path的值為：C:android-sdk-windowstools啟動(dòng)DDMS1、可以在開始一運(yùn)行中進(jìn)入DDMS2、也可以在C:android-sdk-windowstools目錄下啟動(dòng)ddms.bat

2、連接DDMS1、使用數(shù)據(jù)線連接安卓系統(tǒng)的手機(jī)，確認(rèn)手機(jī)是處于“USB調(diào)試”模式。在手機(jī)上按下“Menu”鍵，在彈出的菜單中選擇“Setting(設(shè)置)”；選擇“應(yīng)用程序”；在此界面勾選“未知來源”，然后選擇“開發(fā)”；勾選“USB調(diào)試”，“保持喚醒狀態(tài)”；2、在ddms的左邊框中會(huì)顯示手機(jī)已經(jīng)打開的應(yīng)用程序(APP)進(jìn)程，如果不顯示，可以多連接幾次，或者換個(gè)手機(jī)試操作DDMS1、點(diǎn)擊選中想要監(jiān)測(cè)的進(jìn)程，比如system_process進(jìn)程；2、點(diǎn)擊選中Devices視圖界面中最上方一排圖標(biāo)中的“UpdateHeap”圖標(biāo)；3、點(diǎn)擊Heap視圖中的“CauseGC”按鈕；4、此時(shí)在Heap視圖中就

3、會(huì)看到當(dāng)前選中的進(jìn)程的內(nèi)存使用量的詳細(xì)情況。分析DDMS如何才能知道我們的程序是否有內(nèi)存泄漏的可能性呢。這里需要注意一個(gè)值：Heap視圖中部有一個(gè)Type叫做dataobject,即數(shù)據(jù)對(duì)象，也就是我們的程序中大量存在的類類型的對(duì)象。在dataobject一行中有一列是“TotalSize”，其值就是當(dāng)前進(jìn)程中所有Java數(shù)據(jù)對(duì)象的內(nèi)存總量，一般情況下，這個(gè)值的大小決定了是否會(huì)有內(nèi)存泄漏?？梢赃@樣判斷：1、不斷的操作當(dāng)前應(yīng)用，同時(shí)注意觀察dataobject的TotalSize值；2、正常情況下TotalSize值都會(huì)穩(wěn)定在一個(gè)有限的范圍內(nèi)，也就是說由于程序中的的代碼良好，沒有造成對(duì)象不被垃圾

4、回收的情況，所以說雖然我們不斷的操作會(huì)不斷的生成很多對(duì)象，而在虛擬機(jī)不斷的進(jìn)行GC的過程中，這些對(duì)象都被回收了，內(nèi)存占用量會(huì)會(huì)落到一個(gè)穩(wěn)定的水平；3、反之如果代碼中存在沒有釋放對(duì)象引用的情況，則dataobject的TotaiSize值在每次GC后不會(huì)有明顯的回落，隨著操作次數(shù)的增多TotalSize的值會(huì)越來越大，直到到達(dá)一個(gè)上限后導(dǎo)致進(jìn)程被kill掉。4、此處已system_process進(jìn)程為例，在我的測(cè)試環(huán)境中system_process進(jìn)程所占用的內(nèi)存的dataobject的TotalSize正常情況下會(huì)穩(wěn)定在2.22.8之間，而當(dāng)其值超過3.55后進(jìn)程就會(huì)被kill掉Android

5、程序的內(nèi)存泄漏與規(guī)避方法造成Android應(yīng)用程序內(nèi)存泄漏的原因1、引用沒釋放造成的內(nèi)存泄露注冊(cè)沒有取消造成的內(nèi)存泄漏這種Android的內(nèi)存泄露比純Java的內(nèi)存泄漏還要嚴(yán)重，因?yàn)槠渌恍〢ndroid程序可能引用系統(tǒng)的Android程序的對(duì)象(比如注冊(cè)機(jī)制)。即使Android程序已經(jīng)結(jié)束了，但是別的應(yīng)用程序仍然還有對(duì)Android程序的某個(gè)對(duì)象的引用，泄漏的內(nèi)存依然不能被垃圾回收。集合中對(duì)象沒有關(guān)閉造成的內(nèi)存泄漏通常把一些對(duì)象的引用加入到了集合中，當(dāng)我們不需要該對(duì)象時(shí)，并沒有把它的引用從集合中清理掉，慢慢地這個(gè)集合就會(huì)越來越大。如果這個(gè)集合是靜態(tài)的話，那情況就會(huì)更嚴(yán)重。2、資源對(duì)象沒有關(guān)

6、閉造成的內(nèi)存泄漏資源對(duì)象比如Cursor、File文件等往往都用了一些緩沖，在不使用的時(shí)候應(yīng)該及時(shí)關(guān)閉它們，以便它們的緩沖及時(shí)回收內(nèi)存。這些緩沖不僅存在于Java虛擬機(jī)內(nèi)，還存在于Java虛擬機(jī)外，如果僅僅是把它的引用設(shè)置為空，而不關(guān)閉它們，那么往往會(huì)造成內(nèi)存泄漏。3、一些不良代碼造成的內(nèi)存壓力原因如下：Bitmap沒有調(diào)用recycle();構(gòu)造Adapter時(shí)，沒有使用緩存的convertView;ThreadLoca丨使用不當(dāng)；內(nèi)存泄漏的檢測(cè)及定位1、內(nèi)存泄漏的檢測(cè)Android應(yīng)用程序是基于虛擬機(jī)的，其內(nèi)存管理都是由Dalvik2代為管理，GC的回收不是及時(shí)的。一個(gè)正常的應(yīng)用程序在其運(yùn)

7、行穩(wěn)定后其內(nèi)存的占用量是基本穩(wěn)定的，不應(yīng)該是無限制的增長(zhǎng)。同樣，對(duì)任何一個(gè)類的對(duì)象的使用個(gè)數(shù)也有一個(gè)相對(duì)穩(wěn)定的上限,不應(yīng)該是持續(xù)增長(zhǎng)的。當(dāng)我們持續(xù)地觀察某個(gè)應(yīng)用程序運(yùn)行過程中使用內(nèi)存的大小和各實(shí)例的個(gè)數(shù)時(shí)，如果內(nèi)存的大小持續(xù)增長(zhǎng)，則說明系統(tǒng)存在內(nèi)存泄漏的問題;如果特定類的實(shí)例對(duì)象個(gè)數(shù)隨時(shí)間而增長(zhǎng)，則說明這個(gè)類的實(shí)例可能存在泄漏情況。在重復(fù)打開關(guān)閉某個(gè)應(yīng)用程序的時(shí)候，內(nèi)存一直在向上爬升，也就是說每次關(guān)閉這個(gè)Activity的時(shí)候，有些應(yīng)該釋放的內(nèi)存并沒有被釋放掉。2、內(nèi)存泄漏的位置定位查找內(nèi)存泄漏一種比較徹底的方法就是代碼走查，我們可以一行一行地分析對(duì)象的創(chuàng)建去留等等4,但會(huì)很耗時(shí)間也比較迷茫。

8、這里可以通過EclipseMemoryAnalyzerTool(MAT)工具來定位內(nèi)存泄漏的位置，該方法只適用于Java層的查找，對(duì)C/C+沒用，也就是說只針對(duì)于被虛擬機(jī)來管理的進(jìn)程和內(nèi)存。MAT的解析文件是.hprof文件，這個(gè)文件里面存放了某進(jìn)程的內(nèi)存快照,MAT通過解析.hprof文件就會(huì)自動(dòng)生成一個(gè)內(nèi)存泄漏推測(cè)報(bào)告，通過分析這個(gè)報(bào)告就可以準(zhǔn)確定位到有可能存在內(nèi)存泄漏的具體位置。注：還有一些內(nèi)存泄漏通過MAT是查不出來的，如native的代碼對(duì)C/C+無效規(guī)避內(nèi)存泄漏的方法1、在編寫應(yīng)用程序的過程中，對(duì)于BraodcastReceiver、ContentObserver、FileObse

9、rver在ActivityonDestory或者某類聲明周期結(jié)束之后一定要注銷掉，否則這個(gè)Activity類會(huì)被系統(tǒng)強(qiáng)引用，不會(huì)被內(nèi)存回收。2、在定義成員變量時(shí)，不要直接對(duì)Activity進(jìn)行引用而作為成員變量。如果不得不這么做，那么可以用privateWeakReferencemActivity來聲明。同樣，對(duì)于Service等其他有自己聲明周期的對(duì)象來說，直接引用都需要謹(jǐn)慎考慮是否會(huì)存在內(nèi)存泄漏的可能。3、在應(yīng)用程序中，很多內(nèi)存泄漏是由于循環(huán)引用而造成的，比如a中包含了b，b中包含了c,c中又包含a,這樣只要一個(gè)對(duì)象存在，那么其他對(duì)象肯定會(huì)一直常駐內(nèi)存。因此，在編寫應(yīng)用程序時(shí)要從邏輯上來分

10、析是否需要這樣的設(shè)計(jì)。4、Bitmap對(duì)象不再使用時(shí)，調(diào)用recycle()方法釋放內(nèi)存。如果一個(gè)Bitmap對(duì)象比較占內(nèi)存，當(dāng)它不再被使用的時(shí)候，可以調(diào)用Bitmap.recycle()方法回收此對(duì)象的像素所占用的內(nèi)存，這個(gè)不是必須的，可視情況而定。5、還要注意釋放對(duì)象的引用。當(dāng)一個(gè)生命周期較短的對(duì)象A,被一個(gè)生命周期較長(zhǎng)的對(duì)象B保有其引用的情況下，在A的生命周期結(jié)束時(shí)，要在B中清除掉對(duì)A的引用。Android常見容易引起內(nèi)存泄漏的一些代碼1、查詢數(shù)據(jù)庫(kù)沒有關(guān)閉游標(biāo)程序中經(jīng)常會(huì)進(jìn)行查詢數(shù)據(jù)庫(kù)的操作，但是經(jīng)常會(huì)有使用完畢Cursor后沒有關(guān)閉的情況。如果我們的查詢結(jié)果集比較小，對(duì)內(nèi)存的消耗不容

11、易被發(fā)現(xiàn)，只有在常時(shí)間大量操作的情況下才會(huì)復(fù)現(xiàn)內(nèi)存問題，這樣就會(huì)給以后的測(cè)試和問題排查帶來困難和風(fēng)險(xiǎn)示例代如下碼：01.02.03.040506.07.oe.09.1011*5.16.17.IS.19.20.Cursorcursor=getContentResoLver().qiiery(uri.J;ifcursoroNext()黑正示洌代碼:Cursorcursor-null;trycursor=getContentResolver(q;iery(uri);ifDursor!=null強(qiáng)curaDrmoveToNext()finaLLyifDursor!=null)try

12、cursar.closeO;catch(EjccEptione|廠z2、構(gòu)造Adapter時(shí)，沒有使用緩存的convertView3、Bitmap對(duì)象不在使用時(shí)調(diào)用recycle()沒有及時(shí)釋放如果一個(gè)Bitmap對(duì)象比較占內(nèi)存，當(dāng)它不在被使用的時(shí)候，可以調(diào)用Bitmap.recycle()方法回收此對(duì)象的像素所占用的內(nèi)存4、沒有及時(shí)釋放對(duì)象的引用OOM調(diào)試方式一：使用內(nèi)存監(jiān)測(cè)工具DDMS-Heap:(真機(jī)、模擬器均可使用)工具介紹1、啟動(dòng)eclipse后，切換到DDMS透視圖，并確認(rèn)Devices視圖、Heap視圖都是打開的，沒打開的直接WindowShowView自己選；2、將手機(jī)通過US

13、B鏈接至電腦，鏈接時(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)程，如果在進(jìn)程列表中未出現(xiàn)你的進(jìn)程的話隨便選中一條讓Device一排的工具處于可用狀態(tài)，再點(diǎn)擊下UpdateHeap讓其自動(dòng)找到我們跑的應(yīng)用的進(jìn)程，比如小馬臨時(shí)跑的兩個(gè)應(yīng)用進(jìn)程如圖：5、點(diǎn)擊Heap視圖中的“CauseGC”按鈕；館ThreadsHeap總$AllocationTracker謂【FileEjiploref1Heapupdatesv.IIhappenaftefeweryGCFortFiiscli

14、entEDHe-apSi工亡AllocatedFree%Used音ObjectsCUEflGCDisplay:StatsTTyptCountTotalSisemall?&tL3rg?5iMedianAwvrag?6、點(diǎn)擊CauseGC之后就可以看到我們應(yīng)用的內(nèi)存情況如下圖:說明：點(diǎn)擊“CauseGC”按鈕相當(dāng)于向虛擬機(jī)請(qǐng)求了一次gc操作；當(dāng)內(nèi)存使用信息第一次顯示以后，無須再不斷的點(diǎn)擊“CauseGC”，Heap視圖界面會(huì)定時(shí)刷新，在對(duì)應(yīng)用的不斷的操作過程中就可以看到內(nèi)存使用的變化；c）內(nèi)存使用信息的各項(xiàng)參數(shù)根據(jù)名稱即可知道其意思定位分析這里需要注意一個(gè)值：Heap視圖中部有一個(gè)Type叫做da

15、taobject,即數(shù)據(jù)對(duì)象，也就是我們的程序中大量存在的類類型的對(duì)象。在dataobject一行中有一列是“TotaiSize”，其值就是當(dāng)前進(jìn)程中所有Java數(shù)據(jù)對(duì)象的內(nèi)存總量，如果大家想要看“TotaiSize”是分配的具體信息可以點(diǎn)擊“dataobject這一行來查看詳細(xì)信息，如下圖”：Type-匚ountTotalSize-SmallettLargestMedianAveffsge-free601285.172KB16B122-82BKB16B4B5B:dazaobject2&.M7BOS.273KB16BBOSB32B31Bdas-s口Sajtrt2.525743.465KBlai

16、BD汨IBa口S&lEl1-bytisarr-BQbyteO,booleantl)6774.02MB24BLfiOOMB購(gòu)B陽(yáng)4KB2-foytearray(shortU,chdirQ)出291533.5raKB24B28.023KB43日64Bdrs*ayfabjert,in?|.floafl)4.-543aw.eaakb24B15.023KB牝El65Q8-byte日w日#(JwglldoubkO)165.555KB24B4.WWKB128日355Bnon-Jawaobject1225.602KB16B如B40B478cation8LTitpersEe一般情況下，在dataobject行的

17、TotaiSize這個(gè)值的大小決定了是否會(huì)有內(nèi)存泄漏?？梢赃@樣判斷：a）不斷的操作當(dāng)前應(yīng)用，同時(shí)注意觀察dataobject的TotalSize值；b）正常情況下TotalSize值都會(huì)穩(wěn)定在一個(gè)有限的范圍內(nèi)，也就是說由于程序中的的代碼良好，沒有造成對(duì)象不被垃圾回收的情況，所以說雖然我們不斷的操作會(huì)不斷的生成很多對(duì)象，而在虛擬機(jī)不斷的進(jìn)行GC的過程中，這些對(duì)象都被回收了，內(nèi)存占用量會(huì)會(huì)落到一個(gè)穩(wěn)定的水平；c）反之如果代碼中存在沒有釋放對(duì)象引用的情況，則dataobject的TotalSize值在每次GC后不會(huì)有明顯的回落，隨著操作次數(shù)的增多TotaiSize的值會(huì)越來越大，直到到達(dá)一個(gè)上限后導(dǎo)

18、致進(jìn)程被殺掉。d）此處以com.xiaoma.www進(jìn)程為例，在我的測(cè)試環(huán)境中com.xiaoma.www進(jìn)程所占用的內(nèi)存的dataobject的TotalSize正常情況下穩(wěn)定在0.81.0M之間，而當(dāng)其值超過35M每次啟動(dòng)應(yīng)用該值不穩(wěn)定的時(shí)候進(jìn)程就會(huì)被系統(tǒng)殺掉啦！方式二：方式二：DDMS-Heap:使用內(nèi)存分析工具M(jìn)AT（MemoryAnalyzerTool）1、生成.hprof文件（生成很簡(jiǎn)單，直接點(diǎn)擊Device工具欄中的DumpHPROFfile即可生成2、使用MAT導(dǎo)入.hprof文件3、使用MAT的視圖工具分析內(nèi)存總之，使用DDMS的Heap視圖工具可以很方便的確認(rèn)我們的程序是否存在內(nèi)存泄漏的可能性。這個(gè)地方