Jetpack Microbenchmark 程式庫可讓您在 Android Studio 中快速為 Android 原生程式碼 (Kotlin 或 Java) 進行基準測試。這個程式庫可以處理暖場作業、評估程式碼效能和分配次數，並將基準化結果輸出至 Android Studio 主控台和 JSON 檔案。
建議您先撰寫程式碼，再設定基準。這可幫助您找出價格高的最佳化作業。也可以顯示執行期間的活動，以釐清作業速度緩慢的原因。這些原因可能包括在低優先順序的執行緒上執行、因存取磁碟而進入休眠狀態，或意外呼叫會耗用大量資源的函式 (例如點陣圖解碼)。
Microbenchmark 相當適合用於應用程式中多次執行的 CPU 作業，也就是所謂的熱程式碼路徑。RecyclerView 是很好的範例，可以捲動一次，而且一次展示一個項目、資料轉換/處理，以及其他會重複使用的另一段程式碼。
使用 Microbenchmark 程式庫來評估其他類型的程式碼。由於基準是在迴圈中執行，因此任何不常執行或呼叫多次時都會採用不同方式的程式碼，都不適合進行基準化。
如要瞭解如何在持續整合 (CI) 環境中使用程式庫，請參閱在持續整合中執行基準。
避免測量快取
請盡量避免只評估快取。舉例來說，自訂資料檢視的版面配置基準只能測量版面配置快取的成效。為避免這種情況，您可以在每個迴圈中傳遞不同的版面配置參數。在其他情況下 (例如在測量檔案系統效能時)，由於作業系統會在迴圈中快取檔案系統，因此可能並不容易。
未頻繁執行的程式碼
在應用程式啟動期間執行的程式碼不太可能經由 Android 執行階段 (ART) 進行 JIT 編譯。因此，使用 Microbenchmark 執行程式碼的基準測試，因為程式碼在緊閉的迴圈中運作，並不是實際的測量效能。
如要對這類程式碼執行基準測試，建議您使用 Jetpack Macrobenchmark。這個程式碼支援評估層級較高的使用者互動情形，例如應用程式啟動與捲動效能。
取得一致的基準
行動裝置上的時鐘功能會將動態狀態從高狀態 (為了確保效能) 變更為低狀態 (為了節省電力，或是在裝置過熱時)。這些不同的時鐘可能會造成基準數相差甚遠，因此程式庫會提供解決此問題的方法。
鎖定時鐘 (必須啟用已解鎖裝置)
鎖定時鐘是穩定效能的最佳方式。這個機制可以確保時鐘完全不會因為裝置溫度升高而不足，如果基準未充分運用 CPU，則保持低狀態。使用 Gradle 執行 Microbenchmark 時，系統會自動套用這個屬性，也可以在 CI 中手動套用。雖然這個方法可以確保穩定效能；不過由於大部分 Android 裝置必須取得 Root 權限，因此並未支援大多數裝置。
持續效能模式
Window.setSustainedPerformanceMode() 是裝置支援的功能，可讓應用程式選擇較低的 CPU 頻率上限。在支援的裝置上執行時，Microbenchmark 程式庫使用了這個 API 的組合，並自行啟動活動，以防止溫度調節和穩定結果。
此功能預設為由 Gradle 外掛程式設定的 testInstrumentationRunner 啟用。如果您想使用自訂執行元件，則可將 AndroidBenchmarkRunner 設為子類別，並做為 testInstrumentationRunner 使用。
執行器會啟動不透明的全螢幕活動，確保基準可在前景執行，且沒有其他應用程式繪圖。
自動暫停執行
如果您既未使用時鐘鎖定功能，也未使用持續效能模式，程式庫會執行自動溫度調節偵測。啟用這項功能後，內部基準會定期執行，以判斷裝置溫度是否足夠到降低 CPU 效能。偵測到降低 CPU 效能時，程式庫會暫停執行，讓裝置降溫，並重試目前的基準。
範例
其他資源
提供意見
如要在使用基準化分析時回報問題或提交功能要求，請參閱公開版 Issue Tracker。