【App測試】怎麼測試啓動時間？

版權聲明：本文由何小偉 原創文章，轉載請註明出處: 
文章原文連接：https://www.qcloud.com/community/article/687066001482481827

來源：騰雲閣 https://www.qcloud.com/community

 

背景介紹

Android用戶也許會常常碰到如下的問題： 1）應用後臺開着，手機很快沒電了——應用耗電大； 2）首次/非首次啓動應用，進入應用特別慢——應用啓動慢； 3）應用使用過程當中，愈來愈卡——CPU能力不足/內存泄露； 4）應用頁面卡頓——幀率較低、頁面卡頓。 所以，對開發的Android應用，必須對其進行性能測試，否則將會直接影響用戶體驗。

Android應用性能測試一般包括：啓動時間、內存、CPU、耗電量、流量、流暢度等。本次先介紹啓動時間的測試方法。

啓動時間對於App的性能測試，啓動時間是個重要指標，啓動時間分爲兩種狀況，一種是冷啓動時間（一般是系統重啓，即在啓動前沒有該App進程的狀況），另外一種是熱啓動，即App從被切換到前臺（點back退出後再點擊圖標啓動）。QA測試時，通常關注冷啓動的啓動時間。如下介紹三種測試啓動時間的方法，供你們參考，能夠有針對性的使用。

1.1 使用adb命令

1.1.1 測試方法 輸入adbshell am start -W packagename/MainActivity命令，計算啓動時間。以下圖： 

圖1應用第一次啓動也就是咱們常說的冷啓動,這時候你的應用程序的進程是沒有建立的. 這也是大部分應用的使用場景.用戶在桌面上點擊你應用的 icon 以後,首先要建立進程,而後才啓動 MainActivity.這時候adbshell am start -w packagename/MainActivity 返回的結果,就是標準的應用程序的啓動時間。注意Android 5.0 以前的手機是沒有WaitTime這個值的。關於ThisTime/TotalTime/WaitTime的區別,下面是其解釋。 WaitTime=endTime-startTime

• startTime記錄的剛準備調用startActivityAndWait()的時間點
• endTime記錄的是startActivityAndWait()函數調用返回的時間點
• WaitTime = startActivityAndWait()調用耗時。

WaitTime 就是總的耗時，包括前一個應用Activity pause 的時間和新應用啓動的時間；ThisTime 表示一連串啓動Activity 的最後一個 Activity 的啓動耗時；TotalTime表示新應用啓動的耗時，包括新進程的啓動和 Activity 的啓動，但不包括前一個應用Activity pause 的耗時。也就是說，開發者通常只要關心 TotalTime 便可，這個時間纔是本身應用真正啓動的耗時。

總結一下，若是隻關心某個應用自身啓動耗時，參考TotalTime；若是關心繫統啓動應用耗時，參考WaitTime；若是關心應用有界面Activity啓動耗時，參考ThisTime。

1.1.2 總結

該方法算出的時間是系統從開始處理啓動activity的時間到完成運行layout和draw函數的時間，簡單的理解就是啓動這個Activity的時間，並不包括點擊icon到系統接收到消息的時間。顯然，這個時間並不能完整的模擬用戶操做場景的啓動時間。其次該方法只計算一個Activity的總體啓動時間，沒有分別統計其中每一個函數的時間，不便於定位問題。針對這兩個問題，咱們接下來看一下下面兩個方法是怎樣解決的。

咱們在測試中關注的實際上是用戶體驗的啓動時間，那麼上面的時間就不能知足咱們的需求了。既然是用戶體驗咱們能夠用更直觀的方式，使用screenrecord進行屏幕錄製而後分析視頻。

1.2 使用screenrecord進行屏幕錄製

1.2.1 測試方法 （1）輸入命令adb shellscreenrecord --bugreport /sdcard/lanch.mp4--bugreport 參數會使視頻輸出一些時間信息和幀信息便於咱們分析啓動時間。 （2）點擊收集圖標，app徹底啓動後，使用ctrl+c結束視頻錄製。 （3）使用命令adb pullsdcard/lanch.mp4 ./，導出視頻 （4）導出視頻到電腦，使用能夠按幀播放的視頻軟件打開（mac上quicktime就能夠，win下能夠用kmplayer），並按幀播放。 以下圖所示： 圖2按幀播放視頻，視頻左上角會顯示每一幀的時間（精確到ms）和幀數。如圖，11:09:38.031表示時分秒，f=333是幀數。在視頻中會看到icon會變暗而後高亮，高亮時就是系統開始處理本次icon點擊事件了。能夠把這裏做爲點擊時間，而後根據體驗要求，看到app啓動頁徹底繪製完做爲終止時間，這個時間減去點擊時間就是app的啓動時間。

1.2.2 總結 該方法雖然能夠模擬用戶的操做場景，可是操做成本較高且沒法準確清晰明瞭的知道哪些函數調用時間過長。 以上兩種方法，單從啓動時間看，是沒法定位出具體哪一個函數耗時多一些，遇到啓動時間大於預約的啓動時間閥值時，需一步步的打log，分析查明緣由。下面的方法是貼吧目前計算啓動時間的辦法，能夠很清晰的看到每一個函數的調用時間。

1.3 代碼埋點，查看輸出日誌

1.3.1 測試方法 在代碼中打點，輸出日誌查看。拿貼吧舉例，下圖是整個啓動要經歷的操做。 圖3具體每步作了哪些，能夠參照下表。 圖4這樣經過打點輸出日誌來測試啓動時間，QA就能夠很方便的查看到具體每一個模塊的耗時時間了，以下圖。

1.3.2 總結 這樣打點，能夠清晰明瞭的看出Activity的總耗時及各個函數的耗時狀況，這樣在測試過程當中，若是遇到問題能夠很容易的定位到具體的函數。在測試過程當中也有針對點，好比貼吧直播後續會以插件的形式整合到貼吧裏，測試時，能夠多關注plugin初始化的時間。

針對啓動時間這一性能指標，我的以爲打點輸出日誌的方式較爲理想，QA在測試過程當中發現有疑似問題後，能夠給出具體的函數耗時時間。