作者:孫仁偉,單位:中國移動智慧家庭運營中心
基于Benchmark的性能測試量化指標方案是一種用于評估和量化系統(tǒng)性能的方法。通過使用Benchmark測試工具,該方案旨在提供可靠的性能數(shù)據(jù),并使用具體的指標來衡量系統(tǒng)在各個方面的表現(xiàn)。本文將介紹基于Google MacroBenchmark的性能量化指標測試的工程配置、測試流程、核心指標和應(yīng)用案例,幫助Android 開發(fā)者更好地評估和比較App的性能。
Part 01●??背景?●
隨著App業(yè)務(wù)不斷增長和功能的迭代,代碼量快速增加,導致應(yīng)用結(jié)構(gòu)復(fù)雜度提高。同時,在App開發(fā)過程中,與競爭對手的App進行性能比較也是必要的。為了避免代碼增長和功能迭代帶來的性能下降,我們需要一套技術(shù)方案來監(jiān)控App版本的性能,以指導開發(fā)人員及時進行代碼重構(gòu)。
Part 02●??方案說明?●
Benchmark,即基準測試,是檢查和監(jiān)控應(yīng)用性能的一種方式。通過對每個移動App版本的迭代運行基準測試,可以幫助分析和調(diào)試性能問題,并確保迭代的更改不會引起性能下降。
以下是一常見的移動App的benchmark方法和工具:
1.Startup Time Benchmark:評估應(yīng)用程序的啟動時間,即從用戶點擊應(yīng)用圖標到應(yīng)用程序完全加載并可交互的時間??梢允褂酶鞣N工具和方法來測量啟動時間,如使用應(yīng)用性能監(jiān)測工具或手動計時。
2.Responsiveness Benchmark:評估應(yīng)用程序?qū)τ脩舨僮鞯捻憫?yīng)速度,包括用戶界面的流暢度和操作的延遲??梢允褂眯阅鼙O(jiān)測工具記錄用戶操作和應(yīng)用程序響應(yīng)時間,或者進行用戶體驗測試來評估應(yīng)用的響應(yīng)性能。
3.Memory Usage Benchmark:評估應(yīng)用程序在運行過程中使用的內(nèi)存量??梢允褂脙?nèi)存分析工具來監(jiān)測應(yīng)用程序的內(nèi)存使用情況,并進行比較和分析。
4.Battery Consumption Benchmark:評估應(yīng)用程序?qū)υO(shè)備電池的消耗情況??梢允褂秒姵叵谋O(jiān)測工具來測量應(yīng)用程序在不同使用情景下的電池消耗量,并進行比較和分析。
5.Network Performance Benchmark:評估應(yīng)用程序在使用網(wǎng)絡(luò)功能時的性能和速度??梢允褂镁W(wǎng)絡(luò)性能監(jiān)測工具來模擬不同網(wǎng)絡(luò)條件下的應(yīng)用性能,并進行測試和比較。
針對Startup Time Benchmark和Responsiveness Benchmark,Google提供了Macrobenchmark庫,該庫主要用于評估Android App整體性能的基準測試。其旨在模擬真實世界的使用情景,通過測試用例以涵蓋各種應(yīng)用使用過程中交互操作,以綜合評估應(yīng)用的性能和響應(yīng)能力。
2.1 Macrobenchmark
2.1.1 設(shè)置Macrobenchmark
1. 打開應(yīng)用Application工程,在 Android Studio 的 Project 面板中右鍵點擊項目或模塊,然后依次點擊 New > Module。
2. 從Templates窗格中選擇 Benchmark。
3. 自定義目標應(yīng)用(要進行基準測試的應(yīng)用),以及新的Macrobenchmark模塊的軟件包和模塊名稱。
4. 點擊Finish,從而創(chuàng)建Macrobenchmark Module。
2.1.2 創(chuàng)建Macrobenchmark類
在Macrobenchmark,我們根據(jù)業(yè)務(wù)自身情況,創(chuàng)建所需的性能指標Benchmark測試用例。測試用例可以基于Macrobenchmark 庫中的`MacrobenchmarkRule` JUnit4規(guī)則所含的API實現(xiàn)。
比如我們現(xiàn)在需要對App應(yīng)用啟動時間進行監(jiān)控。則可以在Macrobenchmark Module編寫一個測試用例類,在測試用例類中編寫測試用例方案,如測量5次打開應(yīng)用時間。
創(chuàng)建startup測試用例,該用例基于MacrobenchmarkRule.measureRepated。
其中各參數(shù):
packageName:App的包名;
metrics:測量度量。此處我們選擇 StartupTimeMetric,標識測量啟動時長;
iterations:重復(fù)次數(shù)。表示該項用例的測試次數(shù),可以通過多次測量取均值的方式,避免單次測量的偏差影響;
setupBlock:用例前置操作。;
最后的 {} :用例內(nèi)容。此處我們執(zhí)行 startActivityAndWait,表示啟動App并等待啟動完成,App首幀顯示。
2.1.3 運行基準
在Android Studio中運行測試,以衡量應(yīng)用在設(shè)備上的性能??梢韵袷褂脺y試類或方法旁邊的邊線操作運行任何其他 `@Test` 一樣運行基準,如下圖所示。
也可以通過`gradle`命令,從命令行運行Gradle模塊中的所有基準:
2.1.4 基準結(jié)果
基準運行成功后,指標會直接顯示在Android Studio中,還會以JSON文件形式輸出以供持續(xù)集成環(huán)境使用。
每次衡量的迭代過程均會捕獲單獨的系統(tǒng)跟蹤文件。點擊Test Results窗格中的其中一個鏈接,可以打開這些結(jié)果跟蹤文件,如下圖所示。即平均啟動時長為748.1ms。
跟蹤文件加載完成后,Android Studio會提示您選擇要分析的進程。系統(tǒng)會預(yù)先填充目標應(yīng)用進程:
跟蹤文件加載完成后,Studio將在CPU性能剖析器工具中顯示結(jié)果:
Part 03●??應(yīng)用實例?●
在實驗工程中,在Application.onCreate中增加了200ms睡眠。
運行實驗工程,構(gòu)建App,運行App,運行Macrobenchmark。在CPU性能剖析器工具中可以看到主線程在app.onCreate方法執(zhí)行時耗時達223.12ms。
通過分析CPU性能剖析器工具 的示圖,可以判斷app.onCreate 時,主線程存在約200ms異常時延。再閱讀相關(guān)代碼,可以查出該異常部分的睡眠邏輯。
將該異常睡眠邏輯移除,從新運行實驗工程,構(gòu)建App,運行App,運行Macrobenchmark。
在CPU性能CPU性能剖析器工具中可以看到主線程在app.onCreate方法耗時約為22.01ms,時延正常,方法執(zhí)行過程中只執(zhí)行了相關(guān)調(diào)用方法,說明問題得到了修復(fù)。
通過以上案例,我們可以看出通過Macrobenchmark + CPU性能剖析器工具, 我們可以對應(yīng)用特定場景進行時延分析,并對新增時延進行有效歸因,從而能針對性的進行優(yōu)化處理。
參考文獻
[1] 基準化分析:https://developer.android.com/topic/performance/benchmarking/benchmarking-overview?hl=zh-cn.
[2]?使用Macrobenchmark 測量用戶啟動好卡頓:https://www.youtube.com/watch?v=0adLO2VRJtc.