1.性能測試的幾個指標：
2.性能測試環境准備：
3.啟動時間
3.1，監控值的獲取方法
啟動分為冷啟動和熱啟動，冷啟動：應用程序首次啟動，進程首次創建並加載資源的過程；熱啟動：應用程序啟動后點“back”鍵、“Home”鍵，應用程序退到后台，並未被完全“殺死”的狀態，再次啟動；
3.1.1，冷啟動
啟動App命令：adb shell am start -W -n package/activity 停止App命令：adb shell am force-stop package
獲取package/activity的方法：1.先執行監控指令 adb logcat | grep START，再啟動程序，生成的log信息中可以查看該程序的包名和activity名
ThisTime:647 這條信息中的時間就作為這次應用啟動的耗時
3.1.2，熱啟動
啟動App命令：adb shell am start -W -n package/activity 停止App命令：adb shell input keyevent 3 (發送一個keyevent事件，3代表點擊手機上的“back”鍵)
ThisTime:427 這條信息中的時間就作為這次應用啟動的耗時
3.2，“啟動時間”監控的腳本實現
“啟動時間”監控的腳本實現有兩種方式：1.獲取命令執行時間，作為啟動時間參考值；2.在命令前后加上時間戳，以差值作為參考值（此種方式相對更精准）
腳本中需要創建兩個類以及方法：
腳本實現如圖1、2
得到的數據在csv文件中，數據分析時去掉第一次的數據，取均值，並繪制出一個數據曲線，得到的均值的參考價值的體現方式有兩種形式：1.取競品的數據作為對比（比如測試的是google瀏覽器，用其他瀏覽器做對比）；2.取歷史版本的數據做對比（版本間對比，看最新版本的開發過程中是否造成了啟動時間的延長）
3.2.2，時間戳差值監控用到的類以及方法：
4，CPU監控值的獲取方法、腳本實現和數據分析
4.1獲取方法：
取圖中第一個百分數作為cpu狀態值
腳本實現如圖3、4
注意：關於cpu的狀態測試的時間要稍長一些，需要配合一個自動化腳本來實現對設備的操作，例如重復搜索100次，同時執行監控命令，來獲取搜索100次之后的cpu狀態值
5，流量監控值的獲取方法、腳本實現和數據分析
5.1獲取方法：
1.首先要獲取進程的ID，命令：adb shell ps | grep packagename；
，如圖中的“5715”就是我們想要的進程的ID。
2.獲取進程的ID流量，命令：adb shell cat/proc/pid/net/dev(pid:第一步中獲取到的進程的ID)；
如圖，得到的結果中只需要關注兩個值：Receive（app接收到的數據）、Transmit（app發出的請求數據）；流量等於這兩個值的和：Receive+Transmit。只取eth0、eth1兩個網卡的Receive和Transmit即可，也就是把圖中框起來的4個數值相加。
腳本實現如圖5、6
在實際的測試采集過程中，需要多次采集數據，取最后一次采集到的流量值和第一次采集到的流量值的差，作為我們本次測試過程中的流量消耗，這也是我們關注的重點！
6，電量監控值的獲取方法、腳本實現和數據分析
*注意：一般，用硬件去測試電量的消耗更為准確，用腳本的方式去獲取電量值會與用硬件獲得的值有一點的偏差，但是用腳本的方式適合硬件資源相對有限的創業公司。
6.1獲取方法：
1.命令：adb shell dumpsys battery；2.因為測試過程中需要手機和電腦通過USB線連接，這樣會造成測試電量的過程中手機同時也在充電，所以需要通過命令切換成“非充電狀態”，此命令為：adb shell dumpsys battery set status 1；
如圖，level值就是電量，取測試結束后和測試開始時的電量做差，就是我們要得到的測試過程中電量的消耗。
腳本實現如圖7、8
7，內存監控值的獲取方法、腳本實現和數據分析
7.1.內存監控值的獲取方法
命令：adb shell top；執行完命令后，在所得的數據中，需要關注兩個字段：VSS（虛擬耗用內存）、RSS（實際使用物理內存），然后對測試過程中VSS、RSS的變化情況做曲線圖，得出測試過程中內存的變化情況。
具體的步驟：1.
，（-d：命令刷新的頻率，1的單位是“秒”），將得到的數據輸出到meminfo文件中
2.操作被測試的應用
3.對得到的數據過濾，過濾出所測試應用的內存值（如圖）
7.2.腳本實現如圖9、10
7.3.數據分析
打開得到的csv文件，windows系統可以用excel打開，然后對VSS、RSS做曲線圖
得到的曲線圖中，具體什么樣的表現是有問題的、不可以接受的，需要長時間的測試之后才可能發現一些問題；
1.例如連續測試2個小時或以上，然后看內存變化的區間范圍，如圖中內存的變化區間（最大值-最小值）為6M，可以認為6M的變化對app的影響並不大！如果長時間測試之后得出的變化區間在幾百M，一般認為此時的內存消耗是有問題的。
2.由於每次軟件發版都會測試內存，我們要在多次測試的過程中根據內存的變化得出一個經驗值（參考值），然后對比本次測試所得的值和經驗值，來判斷本次測試所得的值是不是在合理區間內。
8，FPS&過渡渲染的概念和監控方法--分析頁面卡慢的方法
A.FPS：Android應用的幀率FPS（每秒的幀數）是衡量應用流暢度的一個非常重要的指標，可以根據FPS對應用做一些優化，Android系統里定義每秒大於60幀是流暢的（一幀的完成時間是16ms），如果每幀的完成時間大於16ms，我們認為就有卡頓的現象。
1.獲取方法：進入到開發者選項，可以看到有“GPU呈現模式分析”的選項，開啟后即可以條形圖和線形圖的方法顯示系統的界面響應速度，可以用以觀察系統流暢度。那么要如何根據曲線判斷系統是否流暢呢？實際上這個曲線表達的是GPU繪制每一幀界面的時間，只要不超過頂部綠線，都可以視為足夠流暢。
開啟GPU呈現模式分析
只要下方的曲線不超過綠線，都可以視之為流暢
使用系統自帶方法測試流暢度的好處很多，首先是數據准確，系統肯定最知道自己的幀率如何；其次是不占資源，對流暢度測試的影響比較小。那么這個方法是否萬無一失呢？其實還是有一些缺點的。比如說利用CPU渲染UI的App界面，就無法得到測試結果（當然這些界面基本無一例外卡頓無比，不用測也知道不流暢）；當系統停頓了一下，例如微博加載圖片時，響應速度會大幅增加，曲線瞬間突破綠線——這情況不能說不流暢，因為這屬於內容和界面先后響應的機制，如果光憑曲線是否突破綠線判斷是否流暢，未免太過局限。所以，在測試應用程序的時候，需要一邊操作應用，去直觀的感受流暢度，一邊觀察曲線的走勢，如果直觀的感受流暢度差，並且曲線也大量的突破綠線，那么此時我們認為測試應用的流暢度低，需要優化。
1.在設置里打開GPU呈現模式分析。點擊Android設備的“設置”->"開發者選項"，然后勾選“GPU顯示配置文件”。
2.
2.1.點擊Android設備的“設置”->"開發者選項"，然后勾選“GPU顯示配置文件”。重啟我們的應用。啟動應用以后，在應用的頁面上做滑動
2.2.lijiedeMacBook-Air:~ lijie$ adb shell dumpsys gfxinfo com.dianping.v1>fps.txt （com.dianping.v1即packagename）
2.數據分析：
打開生成的fps.txt，找到Profile data in ms這部分數據。
4.為了看得更直接，我們可以把數據放到Excel中，然后以圖表的形式進行查看。
從圖中可以看出來，我這個應用的流暢度是很低的，正常情況下每幀的完成時間在16ms左右，如果1秒60幀的話，而且Execute時間太長！所以是需要進行優化的。
a: "Draw" : 創建顯示列表(display lists，記錄所有view對象的繪制指令)的時間開銷。
b: "Process" : 執行顯示列表中繪制指令的時間。UI視窗中的View數量越多，需要執行的繪畫命令就越多。
c: "Execute" : 將一幀圖像交給合成器compostior的時間。這部分占用的時間通常比較少
測試方法二：FPS Meter測試安卓幀數
FPS Meter是一款非常實用的小軟件，能夠用數字實時顯示安卓界面的每秒幀數，非常直觀。此外，FPS Meter還可以顯示最大幀數、最小幀數以及平均幀數，用來評價安卓流暢度極具價值。由於涉及到了系統功能，所以FPS Meter需要root。如果你打算嘗試，請先root機后再使用。
FPS Meter的使用很簡單，開啟App后啟動服務即可。在App內，你可以選擇幀數顯示的位置，以及是否開啟平均幀數、最低/最高幀數顯示。開啟服務后，即可看到有幀數顯示於界面上。這里要注意，使用FPS Meter測量幀數需要在開發者選項中停用HW疊加層才會比較准確。
FPS Meter可以顯示最大最小幀數以及平均幀數
FPS Meter可以測試界面幀數，不過某些手機如果界面靜止，幀數會為0。FPS Meter除了測量系統界面幀數外，還可以用來測量游戲的幀數，所以用FPS Meter來測試某部安卓機游戲性能多強也是個很好的選擇。
當然，FPS Meter也並非十全十美。由於屬於第三方App，所以可能會有一些兼容性問題。某些安卓機或者ROM使用FPS Meter可能會不兼容，即使成功開啟了幀數顯示也沒法測量到准確數值，而某些設備使用FPS Meter甚至會死機。不過在大多數情況下，這款App還是相當值得信任的。
安卓在多個版本中都通過新技術提升了流暢度，比如說安卓2.3引入Dalvik、安卓4.0引入GPU界面繪制、安卓4.1引入黃油計划、安卓4.3引入Trim以及安卓4.4引入ART等等。
2.過渡渲染：
屏幕上的某個像素在同一幀的時間內被繪制了多次。簡單言，app的一個頁面所顯示的效果是由像素一幀一幀繪制而成，過度繪制就是意味着這一幀被繪制多次。
如果是靜態的布局，可能影響不是很大，如果是動態的，比如ListView，GridView,ViewPager等在性能上就會差一點，常見的比如listView上下滑動，過度繪制的情況下，就會出現卡頓，或者跳躍感很明顯。 當然過度繪制肯定無法避免，我們只能減少不必要的繪制，那么如何看的出來，一個頁面是否過度繪制呢？
下面我們來看一下，下面說的這個工具只有Android 4.2以上有此功能。
2.1.打開我們的手機設置--開發者選項--調試GPU過度繪制（可能有些手機不是這樣的叫法，有的是顯示GPU過度繪制，根據手機而來），選擇顯示過度繪制區域，此時手機頁面會顯示成這樣，不要驚慌。。
這里給大家介紹下，繪制顏色的標識，從好到差：藍色(1x次繪制)-》淺綠色(2x繪制)-》淡紅色(3x繪制)-》紅色(4x繪制)
2.2.怎么減少過度繪制
一般情況下，最好把繪制控制在2次以下，3次繪制有時候是不能避免的，盡量避免，4次的繪制基本上是不允許的。
怎么減少繪制是我們最關心的，我們來看一個圖（自己項目里面的。。我們以圖片下面的ListView為例子）從圖上看的出來，被繪制3次甚至4次
我們來看下代碼：listView和item
紅色標記出來的，是問題的所在，背景顏色繪制了三次，最后一個是選擇器，因為有點擊效果，現在把前2個都給刪掉，只留最后一個，現在我們看一下圖片，看是不是達到預期的效果。
這里只是一個簡單的例子，當然有很多原因組成，我們可以從以下幾個方面着手：
第一：如果是相對比較復雜的布局，建議使用相對布局；
第二：如果需要多層嵌套，我們可以使用merge標簽來減少嵌套；
第三：減少背景顏色的多次繪制；
第四：對於使用Selector當背景的Layout(比如ListView的Item,會使用Selector來標記點擊,選擇等不同的狀態),可以將normal狀態的color設置 為”@android:color/transparent”,來解決對應的問題；
第五：當一個頁面有多種不同的顯示效果，最常見的是listview 中的多種item布局，我們可以采用抽取的方式，等等。
下面再介紹以下Android studio自帶的工具，
首先 打開 Android Device mointor，找到 Hierarychy view （這里我簡稱 視圖樹）
將你要查看的項目運行到模擬器或者真機上，在Android device mointor 上windows 找到當前的模擬器或者真機，找到當前的項目，
如圖：點擊當前項目某一個布局，在View里面會顯示當前這個布局的各個節點圖，然后點擊3（profile node）,在視圖里面就會顯示4上面的三個點
他們分別表示 測量 布局 繪制，再次點擊的時候，我們就可以看到子節點上着三個圓點在變化，他有3個顏色，綠色，黃色，紅色，紅色代表着耗時最長，也就意味着我們需要優化，我們可以不斷點擊，查看 測量布局以及繪制所需要的時間，從而優化。
