Напишите макробенчмарк

Используйте библиотеку Macrobenchmark для тестирования более масштабных вариантов использования вашего приложения, включая запуск приложения и сложные манипуляции с пользовательским интерфейсом, такие как прокрутка RecyclerView или запуск анимации. Если вы хотите протестировать небольшие области вашего кода, обратитесь к библиотеке Microbenchmark . На этой странице показано, как настроить библиотеку Macrobenchmark.

Библиотека выводит более подробные результаты тестирования как на консоль Android Studio, так и в файл JSON. Он также предоставляет файлы трассировки, которые вы можете загружать и анализировать в Android Studio.

Используйте библиотеку Macrobenchmark в среде непрерывной интеграции (CI), как описано в разделе «Бенчмарк в непрерывной интеграции» .

Вы можете использовать Macrobenchmark для создания базовых профилей. Сначала настройте библиотеку Macrobenchmark, затем вы сможете создать базовый профиль .

Настройка проекта

Мы рекомендуем использовать Macrobenchmark с последней версией Android Studio, чтобы использовать функции IDE, интегрируемые с Macrobenchmark.

Настройте модуль Macrobenchmark

Для макробенчмарков требуется модуль com.android.test — отдельный от кода вашего приложения — который отвечает за запуск тестов, измеряющих ваше приложение.

В Android Studio доступен шаблон для упрощения настройки модуля Macrobenchmark. Шаблон модуля тестирования автоматически создает в вашем проекте модуль для измерения приложения, созданного с помощью модуля приложения, включая образец теста запуска.

Чтобы использовать шаблон модуля для создания нового модуля, выполните следующие действия:

  1. Щелкните правой кнопкой мыши проект или модуль на панели «Проект» в Android Studio и выберите «Создать» > «Модуль» .

  2. Выберите «Бенчмарк» на панели «Шаблоны» . Вы можете настроить целевое приложение, то есть приложение, которое будет тестироваться, а также имя пакета и модуля для нового модуля Macrobenchmark.

  3. Нажмите «Готово» .

Шаблон модуля тестирования

Рисунок 1. Шаблон модуля тестирования.

Настройте приложение

Для тестирования приложения (известного как цель Macrobenchmark) приложение должно быть profileable , что позволяет считывать подробную информацию трассировки, не влияя на производительность. Мастер модулей автоматически добавляет тег <profileable> в файл AndroidManifest.xml приложения.

Убедитесь, что целевое приложение включает ProfilerInstaller 1.3 или более поздней версии, который необходим библиотеке Macrobenchmark для включения и сброса профиля, а также очистки кэша шейдеров.

Настройте тестируемое приложение как можно ближе к релизной или рабочей версии. Настройте его как неотлаживаемый и желательно с включенной минификацией, чтобы повысить производительность. Обычно это делается путем создания копии варианта выпуска, который выполняет то же самое, но подписывается локально с помощью ключей отладки. Альтернативно вы можете использовать initWith , чтобы поручить Gradle сделать это за вас:

Котлин

buildTypes {
    getByName("release") {
        isMinifyEnabled = true
        isShrinkResources = true
        proguardFiles(getDefaultProguardFile("proguard-android-optimize.txt"))
    }

    create("benchmark") {
        initWith(getByName("release"))
        signingConfig = signingConfigs.getByName("debug")
    }
}

классный

buildTypes {
    getByName("release") {
        isMinifyEnabled = true
        isShrinkResources = true
        proguardFiles(
            getDefaultProguardFile("proguard-android-optimize.txt"),
            "proguard-rules.pro"
        )
        // In real app, this would use its own release keystore
        signingConfig = signingConfigs.getByName("debug")
    }
}

Чтобы гарантировать, что при выполнении теста будет построен и протестирован правильный вариант вашего приложения, как показано на рисунке 2, выполните следующие действия:

  1. Выполните синхронизацию Gradle.
  2. Откройте панель «Варианты сборки» .
  3. Выберите вариант тестирования приложения и модуля Macrobenchmark.

Выберите вариант сравнения

Рисунок 2. Выбор эталонного варианта.

(Необязательно) Настройка многомодульного приложения

Если в вашем приложении имеется более одного модуля Gradle, убедитесь, что ваши сценарии сборки знают, какой вариант сборки компилировать. Добавьте свойство matchingFallbacks в тип benchmark сборки ваших модулей :macrobenchmark и :app . Остальные ваши модули Gradle могут иметь ту же конфигурацию, что и раньше.

Котлин

create("benchmark") {
    initWith(getByName("release"))
    signingConfig = signingConfigs.getByName("debug")

    matchingFallbacks += listOf("release")
 }

классный

benchmark {
    initWith buildTypes.release
    signingConfig signingConfigs.debug

    matchingFallbacks = ['release']
 }

Без этого новый добавленный тип сборки benchmark приведет к сбою сборки и выдаст следующее сообщение об ошибке:

> Could not resolve project :shared.
     Required by:
         project :app
      > No matching variant of project :shared was found.
      ...

Выбирая варианты сборки в своем проекте, выберите benchmark для модулей :app и :macrobenchmark и release для любых других модулей, имеющихся в вашем приложении, как показано на рисунке 3:

Варианты эталонного тестирования для многомодульного проекта с выбранными типами выпуска и эталонной сборки

Рис. 3. Варианты эталонного тестирования для многомодульного проекта с выбранными типами выпуска и эталонной сборки.

Дополнительные сведения см. в разделе Использование управления зависимостями с учетом вариантов .

(Необязательно) Настройка вкусов продукта

Если в вашем приложении установлено несколько вариантов продукта, настройте модуль :macrobenchmark , чтобы он знал, какой вариант продукта вашего приложения необходимо создать и протестировать.

В примерах на этой странице используются два варианта продукта в модуле :app : demo и production , как показано в следующем фрагменте:

Котлин

flavorDimensions += "environment"
productFlavors {
    create("demo") {
        dimension = "environment"
        // ...
    }
    create("production") {
        dimension = "environment"
        // ...
    }
}

классный

flavorDimensions 'environment'
productFlavors {
    demo {
        dimension 'environment'
        // ...
    }

    production {
        dimension 'environment'
        // ...
    }
}

Без этой конфигурации вы можете получить ошибку сборки, аналогичную ошибке при использовании нескольких модулей Gradle:

Could not determine the dependencies of task ':macrobenchmark:connectedBenchmarkAndroidTest'.
> Could not determine the dependencies of null.
   > Could not resolve all task dependencies for configuration ':macrobenchmark:benchmarkTestedApks'.
      > Could not resolve project :app.
        Required by:
            project :macrobenchmark
         > The consumer was configured to find a runtime of a component, as well as attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'benchmark', attribute 'com.android.build.api.attributes.AgpVersionAttr' with value '7.3.0'. However we cannot choose between the following variants of project :app:
             -   demoBenchmarkRuntimeElements
             -   productionBenchmarkRuntimeElements
           All of them match the consumer attributes:
           ...

В двух следующих разделах описаны способы настройки сравнительного анализа с несколькими вариантами продуктов.

Используйте MissingDimensionStrategy

Указание missingDimensionStrategy в defaultConfig модуля :macrobenchmark указывает системе сборки вернуться к размерному измерению. Укажите, какие измерения использовать, если вы не найдете их в модуле. В следующем примере production вариант используется в качестве измерения по умолчанию:

Котлин

defaultConfig {
    missingDimensionStrategy("environment", "production")
}

классный

defaultConfig {
    missingDimensionStrategy "environment", "production"
}

Таким образом, модуль :macrobenchmark может создавать и тестировать только указанный вариант продукта, что полезно, если вы знаете, что только один вариант продукта имеет правильную конфигурацию для тестирования.

Определите разновидности продукта в модуле :macrobenchmark.

Если вы хотите создать и протестировать другие варианты продукта, определите их в модуле :macrobenchmark . Укажите его так же, как в модуле :app , но назначьте productFlavors только dimension . Никаких других настроек не требуется:

Котлин

flavorDimensions += "environment"
productFlavors {
    create("demo") {
        dimension = "environment"
    }
    create("production") {
        dimension = "environment"
    }
}

классный

flavorDimensions 'environment'
productFlavors {
    demo {
        dimension 'environment'
    }

    production {
        dimension 'environment'
    }
}

После определения и синхронизации проекта выберите соответствующий вариант сборки на панели «Варианты сборки» , как показано на рисунке 4:

Варианты эталонного теста для проекта с вариантами продукта, показывающими производство. Выбранный эталонный тест и выпуск.

Рисунок 4. Варианты эталонного теста для проекта с вариантами продукта, показывающими выбранные «производственный тест» и «релиз».

Дополнительные сведения см. в разделе Устранение ошибок сборки, связанных с сопоставлением вариантов .

Создайте класс макробенчмарка

Сравнительное тестирование осуществляется через API правил MacrobenchmarkRule JUnit4 в библиотеке Macrobenchmark. Он содержит метод measureRepeated , который позволяет указать различные условия запуска и тестирования целевого приложения.

Вам необходимо как минимум указать packageName целевого приложения, какие metrics вы хотите измерить и сколько iterations должен выполнить тест.

Котлин

@LargeTest
@RunWith(AndroidJUnit4::class)
class SampleStartupBenchmark {
    @get:Rule
    val benchmarkRule = MacrobenchmarkRule()

    @Test
    fun startup() = benchmarkRule.measureRepeated(
        packageName = TARGET_PACKAGE,
        metrics = listOf(StartupTimingMetric()),
        iterations = DEFAULT_ITERATIONS,
        setupBlock = {
            // Press home button before each run to ensure the starting activity isn't visible.
            pressHome()
        }
    ) {
        // starts default launch activity
        startActivityAndWait()
    }
}

Ява

@LargeTest
@RunWith(AndroidJUnit4.class)
public class SampleStartupBenchmark {
    @Rule
    public MacrobenchmarkRule benchmarkRule = new MacrobenchmarkRule();

    @Test
    public void startup() {
        benchmarkRule.measureRepeated(
            /* packageName */ TARGET_PACKAGE,
            /* metrics */ Arrays.asList(new StartupTimingMetric()),
            /* iterations */ 5,
            /* measureBlock */ scope -> {
                // starts default launch activity
                scope.startActivityAndWait();
                return Unit.INSTANCE;
            }
        );
    }
}

Все варианты настройки тестов см. в разделе «Настройка тестов» .

Запустите тест

Запустите тест из Android Studio, чтобы измерить производительность вашего приложения на вашем устройстве. Вы можете запускать тесты так же, как и любой другой @Test используя действие поля рядом с вашим тестовым классом или методом, как показано на рисунке 5.

Запустите макротест с действием поля рядом с тестовым классом.

Рисунок 5. Запустите Macrobenchmark с действием поля рядом с тестовым классом.

Вы также можете запустить все тесты в модуле Gradle из командной строки, выполнив команду connectedCheck :

./gradlew :macrobenchmark:connectedCheck

Вы можете запустить один тест, выполнив следующее:

./gradlew :macrobenchmark:connectedCheck -P android.testInstrumentationRunnerArguments.class=com.example.macrobenchmark.startup.SampleStartupBenchmark#startup

См. раздел «Бенчмарк в непрерывной интеграции» для получения информации о том, как запускать и отслеживать тесты в непрерывной интеграции.

Результаты тестов

После успешного выполнения теста метрики отображаются непосредственно в Android Studio и выводятся для использования CI в файле JSON . Каждая измеренная итерация фиксирует отдельную трассировку системы. Вы можете открыть эти результаты трассировки, щелкнув ссылки на панели «Результаты теста» , как показано на рисунке 6:

Результаты запуска макробенчмарка

Рисунок 6. Результаты запуска Macrobenchmark.

Когда трассировка загружена, Android Studio предложит вам выбрать процесс для анализа. Выбор предварительно заполняется процессом целевого приложения, как показано на рисунке 7:

Выбор процесса трассировки Studio

Рисунок 7. Выбор процесса трассировки Studio.

После загрузки файла трассировки Studio отображает результаты в инструменте профилирования ЦП :

Студия Трейс

Рисунок 8. Трассировка студии.

Отчеты JSON и любые трассировки профилирования также автоматически копируются с устройства на хост. Они записываются на хост-компьютере в следующем месте:

project_root/module/build/outputs/connected_android_test_additional_output/debugAndroidTest/connected/device_id/

Доступ к файлам трассировки вручную

Если вы хотите использовать инструмент Perfetto для анализа файла трассировки, необходимо выполнить дополнительные действия. Perfetto позволяет вам проверять все процессы, происходящие на устройстве во время трассировки, в то время как профилировщик ЦП Android Studio ограничивает проверку одним процессом.

Если вы вызываете тесты из Android Studio или из командной строки Gradle, файлы трассировки автоматически копируются с устройства на хост. Они записываются на хост-компьютере в следующем месте:

project_root/module/build/outputs/connected_android_test_additional_output/debugAndroidTest/connected/device_id/TrivialStartupBenchmark_startup[mode=COLD]_iter002.perfetto-trace

Если у вас есть файл трассировки в вашей хост-системе, вы можете открыть его в Android Studio, выбрав в меню «Файл» > «Открыть» . Это показывает вид инструмента профилировщика, показанный в предыдущем разделе.

Ошибки конфигурации

Если приложение неправильно настроено (отлаживаемое или непрофилируемое), Macrobenchmark возвращает ошибку, а не сообщает о неправильном или неполном измерении. Вы можете подавить эти ошибки с помощью аргумента androidx.benchmark.suppressErrors .

Macrobenchmark также возвращает ошибки при попытке измерить эмулятор или устройство с низким зарядом батареи, что может поставить под угрозу доступность ядра и тактовую частоту.

Настройте тесты

Функция measureRepeated принимает различные параметры, которые влияют на то, какие метрики собирает библиотека, как запускается и компилируется ваше приложение или сколько итераций выполняет тест.

Фиксируйте показатели

Метрики — это основной тип информации, извлекаемой из ваших тестов. Доступны следующие показатели:

Дополнительные сведения о метриках см. в разделе Захват метрик Macrobenchmark .

Улучшите данные трассировки с помощью пользовательских событий

Может быть полезно оснастить ваше приложение пользовательскими событиями трассировки, которые отображаются в остальной части отчета трассировки и могут помочь выявить проблемы, специфичные для вашего приложения. Дополнительные сведения о создании пользовательских событий трассировки см. в разделе Определение пользовательских событий .

Режим компиляции

Макробенчмарки могут указывать CompilationMode , который определяет, какая часть приложения должна быть предварительно скомпилирована из байт-кода DEX (формат байт-кода в APK) в машинный код (аналогично предварительно скомпилированному C++).

По умолчанию макротесты запускаются с помощью CompilationMode.DEFAULT , который устанавливает базовый профиль (если он доступен) на Android 7 (уровень API 24) и более поздних версиях. Если вы используете Android 6 (уровень API 23) или более раннюю версию, режим компиляции полностью компилирует APK как поведение системы по умолчанию.

Вы можете установить базовый профиль, если целевое приложение содержит как базовый профиль, так и библиотеку ProfileInstaller .

В Android 7 и более поздних версиях вы можете настроить CompilationMode , чтобы влиять на объем предварительной компиляции на устройстве, чтобы имитировать различные уровни предварительной компиляции (AOT) или JIT-кэширования. См. CompilationMode.Full , CompilationMode.Partial , CompilationMode.None и CompilationMode.Ignore .

Эта функция построена на командах компиляции ART . Перед запуском каждого теста данные профиля очищаются, чтобы обеспечить отсутствие помех между тестами.

Режим запуска

Чтобы выполнить запуск активности, вы можете передать предопределенный режим запуска: COLD , WARM или HOT . Этот параметр изменяет способ запуска активности и состояние процесса в начале теста.

Дополнительные сведения о типах запуска см. в разделе Время запуска приложения .

Образцы

Пример проекта доступен в образце Macrobenchmark репозитория на GitHub.

Оставьте отзыв

Чтобы сообщить о проблемах или отправить запрос на добавление функций для Jetpack Macrobenchmark, воспользуйтесь общедоступной системой отслеживания проблем .

{% дословно %} {% дословно %} {% дословно %} {% дословно %}