1.性能測試的幾個指標： android
2.性能測試環境準備：shell
3.啓動時間windows
3.1，監控值的獲取方法瀏覽器
啓動分爲冷啓動和熱啓動，冷啓動：應用程序首次啓動，進程首次建立並加載資源的過程；熱啓動：應用程序啓動後點「back」鍵、「Home」鍵，應用程序退到後臺，並未被徹底「殺死」的狀態，再次啓動；app
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名post
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.在命令先後加上時間戳，以差值做爲參考值（此種方式相對更精準）
腳本中須要建立兩個類以及方法：
腳本實現如圖一、2
獲得的數據在csv文件中，數據分析時去掉第一次的數據，取均值，並繪製出一個數據曲線，獲得的均值的參考價值的體現方式有兩種形式：1.取競品的數據做爲對比（好比測試的是google瀏覽器，用其餘瀏覽器作對比）；2.取歷史版本的數據作對比（版本間對比，看最新版本的開發過程當中是否形成了啓動時間的延長）
3.2.2，時間戳差值監控用到的類以及方法：
4，CPU監控值的獲取方法、腳本實現和數據分析
4.1獲取方法： 取圖中第一個百分數做爲cpu狀態值
腳本實現如圖三、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個數值相加。
腳本實現如圖五、6
在實際的測試採集過程當中，須要屢次採集數據，取最後一次採集到的流量值和第一次採集到的流量值的差，做爲咱們本次測試過程當中的流量消耗，這也是咱們關注的重點！
6，電量監控值的獲取方法、腳本實現和數據分析
*注意：通常，用硬件去測試電量的消耗更爲準確，用腳本的方式去獲取電量值會與用硬件得到的值有一點的誤差，可是用腳本的方式適合硬件資源相對有限的創業公司。
6.1獲取方法：
1.命令：adb shell dumpsys battery；2.由於測試過程當中須要手機和電腦經過USB線鏈接，這樣會形成測試電量的過程當中手機同時也在充電，因此須要經過命令切換成「非充電狀態」，此命令爲：adb shell dumpsys battery set status 1；
如圖，level值就是電量，取測試結束後和測試開始時的電量作差，就是咱們要獲得的測試過程當中電量的消耗。
腳本實現如圖七、8
7，內存監控值的獲取方法、腳本實現和數據分析
7.1.內存監控值的獲取方法
命令：adb shell top；執行完命令後，在所得的數據中，須要關注兩個字段：VSS（虛擬耗用內存）、RSS（實際使用物理內存），而後對測試過程當中VSS、RSS的變化狀況作曲線圖，得出測試過程當中內存的變化狀況。
具體的步驟：1.，（-d：命令刷新的頻率，1的單位是「秒」），將獲得的數據輸出到meminfo文件中
2.操做被測試的應用
3.對獲得的數據過濾，過濾出所測試應用的內存值（如圖）
7.2.腳本實現如圖九、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個顏色，綠色，黃色，紅色，紅色表明着耗時最長，也就意味着咱們須要優化，咱們能夠不斷點擊，查看 測量佈局以及繪製所須要的時間，從而優化。
以上，簡單介紹了Android app性能測試的幾個指標，但願對你們有幫助。