Android Monitor捕獲到的文件都在該路徑下
|
今日科技快訊 本月起，攜號轉(zhuǎn)網(wǎng)業(yè)務(wù)就要在試點省市落地了。業(yè)內(nèi)人士認(rèn)為，有了攜號轉(zhuǎn)網(wǎng)的壓力，運營商就會更積極實施提速降費，有利于擴(kuò)大信息消費。所謂“攜號轉(zhuǎn)網(wǎng)”，是指一家電信運營商的用戶，無需改變自己的號碼，就能轉(zhuǎn)而成為另一家運營商的用戶，并享受其提供的各種服務(wù)。 作者簡介 本篇轉(zhuǎn)自掘金的文章，分享了Android Monitor的相關(guān)內(nèi)容，一起來看看！希望大家喜歡。 文章地址如下所示：
正文 Android Studio 內(nèi)置了四種性能監(jiān)測工具M(jìn)emory Monitor、Network Monitor、CPU Monitor、GPU Monitor，我們可以使用這些工具監(jiān)測APP的狀態(tài)，該文簡單介紹下這些工具的使用 Memory Monitor Memory Monitor工具主要是用來監(jiān)測APP的內(nèi)存分配情況，判斷是否存在內(nèi)存泄漏。連接設(shè)備，選擇好要監(jiān)測的APP，如圖所示：
通過與應(yīng)用交互并在Memory Monitor中觀察它是如何影響內(nèi)存的使用，圖表可以為你展示 一些潛在的問題:
正常情況下，上圖中的D區(qū)域會隨著時間的走勢慢慢上升(就算你與APP沒有任何交互)，直到E區(qū)域被用完，則會觸發(fā)GC操作，釋放內(nèi)存，周而復(fù)始。如果你發(fā)現(xiàn)你的應(yīng)用是靜態(tài)的，但是E區(qū)域的內(nèi)存很快就被用完了，即頻繁的觸發(fā)GC操作，這時你就應(yīng)該引起重視，說不定你的代碼中就存在著引起內(nèi)存泄漏的隱患。
使用場景：定位內(nèi)存泄漏 點擊上圖中的B按鈕開始檢測APP，此時APP會變得很卡，容易發(fā)生ANR，一段時間過后會生成.hprof文件，如下圖所示 這里的截圖是我故意生成的一個能引起內(nèi)存泄漏的例子，點擊上圖右上方的Analyzer Tasks按鈕，若代碼中存在內(nèi)存泄漏隱患，在其下方會列出可能引起內(nèi)存泄漏的Activity，如上圖右下方的Leaked Activities，之后我們便可以結(jié)合左下方Reference Tree中指出的問題分析，如果你有源碼的話還可以索引源碼(右鍵->Jump to source)。實例代碼如下： 多次旋轉(zhuǎn)屏幕，使得內(nèi)存不斷增加就容易引起內(nèi)存泄漏。 上面的例子比較簡單，可以直接通過Memory Monitor工具就能直接看出，在平常的開發(fā)中內(nèi)存泄漏的問題往往沒有這么簡單，我們可以借助MAT工具分析。
MAT(Memory Analyzer Tool)，一個基于Eclipse的內(nèi)存分析工具，是一個快速、功能豐富的JAVA heap分析工具，它可以幫助我們查找內(nèi)存泄漏和減少內(nèi)存消耗。使用內(nèi)存分析工具從眾多的對象中進(jìn)行分析，快速的計算出在內(nèi)存中對象的占用大小，看看是誰阻止了垃圾收集器的回收工作，并可以通過報表直觀的查看到可能造成這種結(jié)果的對象。 之后用MAT打開，顯示如下 點擊Histogram按鈕 如圖所示，該圖會列出內(nèi)存中所有的對象的個數(shù)即其占用的內(nèi)存大小，其次，我們可以輸入指定的Activity名稱來縮小定位范圍 如圖所示，這里列出了MainActivity和其內(nèi)部類MyThread的對象個數(shù)即占用的內(nèi)存大小，接下來我們選擇一個條目右鍵—>Merge Shortest Paths to GC Roots(查看一個對象到GC Roots是否存在引用鏈相連接)->Merge Shortest Paths to GC Roots(排除虛引用/弱引用/軟引用等等)， 如上圖所示，就是可能存在內(nèi)存泄漏的地方，具體還是要結(jié)合代碼分析。
對象存活的判定: 當(dāng)一個對象不會再被使用的時候，我們會說這對象已經(jīng)死亡。對象何時死亡，寫程序的人應(yīng)當(dāng)是最清楚的。如果計算機(jī)也要弄清楚這件事情，就需要使用一些方法來進(jìn)行對象存活判定，常見的方法有引用計數(shù)（Reference Counting）和有可達(dá)性分析（Reachability Analysis）兩種。 引用計數(shù)算法的大致思想是給對象中添加一個引用計數(shù)器，每當(dāng)有一個地方引用它時，計數(shù)器值就加1；當(dāng)引用失效時，計數(shù)器值就減1；任何時刻計數(shù)器為0的對象就是不可能再被使用的。 Java語言里面沒有選用引用計數(shù)算法來管理內(nèi)存，其中最主要原因是它沒有一個優(yōu)雅的方案解決對象之間相互循環(huán)引用的問題： 當(dāng)兩個對象互相引用，即使它們都無法被外界使用時，它們的引用計數(shù)器也不會為0。 可達(dá)性算法的基本思路就是通過一系列的稱為GC根節(jié)點（GC Roots）的對象作為起始點，從這些節(jié)點開始進(jìn)行向下搜索，搜索所走過的路徑成為引用鏈（Reference Chain），當(dāng)一個對象到GC Roots沒有任何引用鏈相連（用圖論的話來說就是從GC Roots到這個對象不可達(dá)）時，則證明此對象是不可用的。 如上圖，對象object 5、object 6、object 7雖然互相有關(guān)聯(lián)，它們的引用并不為0，但是它們到GC Roots是不可達(dá)的，因此它們將會被判定為是可回收的對象。
在內(nèi)存圖中點擊C，啟動追蹤，再次點擊停止追蹤，隨后自動生成一個alloc結(jié)尾的文件，這個文件就記錄了這次追蹤到的所有數(shù)據(jù)。
如上圖，我們可以看出這次操作中應(yīng)用里的各個組件的分配次數(shù)與占用大小，若發(fā)現(xiàn)這兩個數(shù)據(jù)有異常(分配過多，占用過大)，同樣可以索引源碼優(yōu)化(前提是你有)，最下方的視圖是以另一種較酷炫的方式呈現(xiàn)，感興趣的可以具體結(jié)合文件操作。 Network Monitor Network Monitor是用于顯示app網(wǎng)絡(luò)請求的狀態(tài)，頻繁的網(wǎng)絡(luò)請求是耗電的重要原因
如上圖所示，Tx與Rx分別表示上下行的速度。 GPU Monitor GPU Monitor工具可以將進(jìn)行UI渲染工作所花的時間表現(xiàn)出來，它記錄下渲染線程準(zhǔn)備以及進(jìn)行描繪的時間。
我們通常都會提到60fps與16ms，可是知道為何會是以程序是否達(dá)到60fps來作為App性能的衡量標(biāo)準(zhǔn)嗎？這是因為人眼與大腦之間的協(xié)作無法感知超過60fps的畫面更新。 12fps大概類似手動快速翻動書籍的幀率，這明顯是可以感知到不夠順滑的。24fps使得人眼感知的是連續(xù)線性的運動，這其實是歸功于運動模糊的效果。24fps是電影膠圈通常使用的幀率，因為這個幀率已經(jīng)足夠支撐大部分電影畫面需要表達(dá)的內(nèi)容，同時能夠最大的減少費用支出。但是低于30fps是無法順暢表現(xiàn)絢麗的畫面內(nèi)容的，此時就需要用到60fps來達(dá)到想要的效果，當(dāng)然超過60fps是沒有必要的。 開發(fā)app的性能目標(biāo)就是保持60fps，這意味著每一幀你只有16ms=1000/60的時間來處理所有的任務(wù)。
如上圖所示，就是GPU Monitor的樣子，點擊上圖獲取gfxtrace按鈕后，出現(xiàn)彈出框讓你選擇要監(jiān)測的指定線程
選定后點擊Trace
過程中會加載指定的lib,同時手機(jī)會彈出Dialog
環(huán)境需滿足條件(手機(jī)root，安裝GPU Debugging tools以及相關(guān)lib)，若不滿足會提示：“Failed to connect to the graphics debugger”，假設(shè)這里已滿足條件
判斷是否在獲取trace的依據(jù)是隨著你的操作，上圖的值不斷增長，點擊stop獲得這個過程中生成的gfxtrace。
GPU Debuger是檢查OpenGL ES 2.0或3.1渲染app圖形的情況，打開之前生成的gfxtrace |
|
|
