Плагин Baseline Profile Gradle упрощает создание и поддержку Baseline Profiles . Это поможет вам решить следующие задачи:
- Создайте новые базовые профили для своего приложения .
- Создайте новые базовые профили для своей библиотеки .
- Настройте генерацию базового профиля.
На этой странице объясняется, как использовать плагин Gradle Baseline Profile для настройки создания базовых профилей.
Требования к плагину
- АГП 8.0 или выше
- Зависимость от последней версии плагина Gradle
Используйте управляемые устройства Gradle для создания базовых профилей
Чтобы использовать управляемое устройство Gradle (GMD) для создания базового профиля, добавьте его в конфигурацию build.gradle.kts
модуля производителя профиля (вероятно, тестовый модуль :baselineprofile
), как показано в следующем примере:
Котлин
android { testOptions.managedDevices.devices { create<com.android.build.api.dsl.ManagedVirtualDevice>("pixel6Api31") { device = "Pixel 6" apiLevel = 31 systemImageSource = "aosp" } } }
классный
android { testOptions.managedDevices.devices { pixel6Api31(ManagedVirtualDevice) { device 'Pixel 6' apiLevel = 31 systemImageSource 'aosp' } } }
Используйте GMD для создания базовых профилей, добавив его в конфигурацию плагина Gradle базового профиля следующим образом: в build.gradle.kts
тестового модуля :baselineprofile
:
Котлин
baselineProfile { managedDevices += "pixel6Api31" }
классный
baselineProfile { managedDevices = ['pixel6Api31'] }
Когда вы используете GMD для создания базовых профилей, установите для useConnectedDevices
значение false
в тестовом модуле :baselineprofile
:
Котлин
baselineProfile { ... useConnectedDevices = false }
классный
baselineProfile { ... useConnectedDevices false }
Создание базовых профилей для различных вариантов
Вы можете создавать базовые профили для каждого варианта, для каждого варианта или в виде одного файла для использования для всех вариантов. Управляйте этим поведением с помощью параметра слияния, как показано в следующем примере, в build.gradle.kts
модуля приложения или библиотеки.
Котлин
baselineProfile { mergeIntoMain = true }
классный
baselineProfile { mergeIntoMain true }
Чтобы объединить сгенерированные профили для всех вариантов в один профиль, установите для mergeIntoMain
значение true
. Невозможно генерировать базовые профили для каждого варианта, если этот параметр имеет true
, поэтому существует единственная задача Gradle generateBaselineProfile
которая называетсяgenerateBaselineProfile. Профиль выводится в src/main/generated/baselineProfiles
.
Чтобы отключить слияние и иметь один профиль для каждого варианта, установите для mergeIntoMain
значение false
. В этом случае существует несколько задач Gradle для конкретных вариантов. Например, когда есть два варианта — например, бесплатный и платный — и один тип сборки выпуска, задачи следующие:
* `generateFreeReleaseBaselineProfile`
* `generatePaidReleaseBaselineProfile`
* `generateReleaseBaselineProfile`
Чтобы указать поведение слияния для каждого варианта, используйте следующий код:
Котлин
baselineProfile { variants { freeRelease { mergeIntoMain = true } } }
классный
baselineProfile { variants { freeRelease { mergeIntoMain true } } }
В предыдущем примере все варианты, в которых флаг установлен в значение true
объединены в src/main/generated/baselineProfiles
, а профили для вариантов, в которых флаг установлен в значение false
хранятся в папке src/<variant>/generated/baselineProfiles
.
По умолчанию mergeIntoMain
установлено значение true
для библиотек и false
для приложений.
Автоматически генерировать базовые профили при сборке нового выпуска.
Вы можете настроить базовые профили для автоматического создания при каждой сборке выпуска вместо ручного использования generateBaselineProfile
. При автоматическом создании в сборку выпуска включается самый обновленный профиль.
Чтобы включить автоматическое создание сборок выпуска, используйте флаг automaticGenerationDuringBuild
:
Котлин
baselineProfile { automaticGenerationDuringBuild = true }
классный
baselineProfile { automaticGenerationDuringBuild true }
Установка флага automaticGenerationDuringBuild
в значение true
запускает создание нового базового профиля для каждой сборки выпуска. Это означает, что выполнение задачи сборки выпуска сборки, например ./gradlew:app:assembleRelease
, также запускает :app:generateReleaseBaselineProfile
, запускает инструментальные тесты базового профиля и создает сборку базового профиля, на которой они выполняются. Хотя автоматическая генерация помогает пользователям получить максимальную выгоду от производительности, она также увеличивает время сборки из-за двойной сборки и инструментальных тестов.
Вы также можете указать это поведение для каждого варианта, как показано в следующем примере:
Котлин
baselineProfile { variants { freeRelease { automaticGenerationDuringBuild = true } } }
классный
baselineProfile { variants { freeRelease { automaticGenerationDuringBuild true } } }
В предыдущем примере задача generateFreeReleaseBaselineProfile
запускается при запуске assembleFreeRelease
. Это помогает, когда пользователь хочет иметь, например, release
для сборки распространения, которая всегда генерирует профиль при сборке, и сборку releaseWithoutProfile
для внутреннего тестирования.
Сохранение базовых профилей в источниках
Вы можете хранить базовые профили в исходном каталоге с помощью флага saveInSrc
в build.gradle.kts
модуля приложения или библиотеки:
-
true
: базовый профиль хранится вsrc/<variant>/generated/baselineProfiles
. Это позволит вам зафиксировать последний сгенерированный профиль с вашими источниками. -
false
: базовый профиль хранится в промежуточных файлах в каталоге сборки. Таким образом, при фиксации кода вы не сохраняете последний созданный профиль.
Котлин
baselineProfile { saveInSrc = true }
классный
baselineProfile { saveInSrc true }
Вы также можете указать это поведение для каждого варианта:
Котлин
baselineProfile { variants { freeRelease { saveInSrc = true } } }
классный
baselineProfile { variants { freeRelease { saveInSrc true } } }
Правила фильтра профиля
Плагин Baseline Profile Gradle позволяет фильтровать созданные правила базового профиля. Это особенно полезно для библиотек, если вы хотите исключить правила профиля для классов и методов, которые являются частью других зависимостей примера приложения или самой библиотеки. Фильтры могут включать и исключать определенные пакеты и классы. Если вы указываете только исключения, исключаются только соответствующие правила базового профиля, а все остальное включается.
Спецификация фильтров может быть любой из следующих:
- Имя пакета, заканчивающееся двойными подстановочными знаками, соответствует указанному пакету и всем подпакетам. Например,
com.example.**
соответствуетcom.example.method
иcom.example.method.bar
. - Имя пакета, заканчивающееся подстановочным знаком, соответствует только указанному пакету. Например,
com.example.*
соответствуетcom.example.method
, но не соответствуетcom.example.method.bar
. - Имена классов, соответствующие определенному классу, например
com.example.MyClass
.
В следующих примерах показано, как включать и исключать определенные пакеты:
Котлин
baselineProfile { filter { include("com.somelibrary.widget.grid.**") exclude("com.somelibrary.widget.grid.debug.**") include("com.somelibrary.widget.list.**") exclude("com.somelibrary.widget.list.debug.**") include("com.somelibrary.widget.text.**") exclude("com.somelibrary.widget.text.debug.**") } }
классный
baselineProfile { filter { include 'com.somelibrary.widget.grid.**' exclude 'com.somelibrary.widget.grid.debug.**' include 'com.somelibrary.widget.list.**' exclude 'com.somelibrary.widget.list.debug.**' include 'com.somelibrary.widget.text.**' exclude 'com.somelibrary.widget.text.debug.**' } }
Настройте правила фильтрации для разных вариантов следующим образом:
Котлин
// Non-specific filters applied to all the variants. baselineProfile { filter { include("com.myapp.**") } } // Flavor-specific filters. baselineProfile { variants { free { filter { include("com.myapp.free.**") } } paid { filter { include("com.myapp.paid.**") } } } } // Build-type-specific filters. baselineProfile { variants { release { filter { include("com.myapp.**") } } } } // Variant-specific filters. baselineProfile { variants { freeRelease { filter { include("com.myapp.**") } } } }
классный
// Non-specific filters applied to all the variants. baselineProfile { filter { include 'com.myapp.**' } } // Flavor-specific filters. baselineProfile { variants { free { filter { include 'com.myapp.free.**' } } paid { filter { include 'com.myapp.paid.**' } } } } // Build-type specific filters. baselineProfile { variants { release { filter { include 'com.myapp.**' } } } } // Variant-specific filters. baselineProfile { variants { freeRelease { filter { include 'com.myapp.**' } } } }
Вы также можете фильтровать правила, используя аргумент filterPredicate
в BaselineProfileRule.collect()
, но мы рекомендуем использовать плагин Gradle для фильтрации, поскольку он обеспечивает более простой способ фильтрации подпакетов и единое место для настройки всего модуля.
Настройка типов сборки эталонного теста и базового профиля
Плагин Baseline Profile Gradle создает дополнительные типы сборок для создания профилей и запуска тестов. Эти типы сборок имеют префикс benchmark
и nonMinified
. Например, для типа сборки release
плагин создает типы сборки benchmarkRelease
и nonMinifiedRelease
. Эти типы сборок автоматически настраиваются для конкретного варианта использования и обычно не требуют какой-либо настройки. Но в некоторых случаях все же может оказаться полезным применить некоторые пользовательские параметры, например применить другую конфигурацию подписи.
Вы можете настроить автоматически создаваемые типы сборки, используя подмножество свойств типа сборки; свойства, которые невозможно использовать, переопределяются. В следующем примере показано, как настроить дополнительные типы сборки и какие свойства переопределяются:
Котлин
android { buildTypes { release { ... } create("benchmarkRelease") { // Customize properties for the `benchmarkRelease` build type here. // For example, you can change the signing config (by default // it's the same as for the `release` build type). signingConfig = signingConfigs.getByName("benchmarkRelease") } create("nonMinifiedRelease") { // Customize properties for the `nonMinifiedRelease` build type here. signingConfig = signingConfigs.getByName("nonMinifiedRelease") // From Baseline Profile Gradle plugin 1.2.4 and higher, you can't // customize the following properties, which are always overridden to // avoid breaking Baseline Profile generation: // // isJniDebuggable = false // isDebuggable = false // isMinifyEnabled = false // isShrinkResources = false // isProfileable = true // enableAndroidTestCoverage = false // enableUnitTestCoverage = false } } }
классный
android { buildTypes { release { ... } benchmarkRelease { // Customize properties for the `benchmarkRelease` build type here. // For example, you can change the signing config (by default it's the // same as for the `release` build type.) signingConfig = signingConfigs.benchmarkRelease } nonMinifiedRelease { // Customize properties for the `nonMinifiedRelease` build type here. signingConfig = signingConfigs.nonMinifiedRelease // From Baseline Profile Gradle plugin 1.2.4 and higher, you can't use // the following properties, which are always overridden to avoid breaking // Baseline Profile generation: // // isJniDebuggable = false // isDebuggable = false // isMinifyEnabled = false // isShrinkResources = false // isProfileable = true // enableAndroidTestCoverage = false // enableUnitTestCoverage = false } } }
Дополнительные примечания
При создании базовых профилей следует учитывать некоторые дополнительные моменты:
Скомпилированные базовые профили должны быть меньше 1,5 МБ. Это не относится к текстовому формату исходных файлов, которые перед компиляцией обычно намного больше. Проверьте размер двоичного базового профиля, найдя его в выходном артефакте в папке
assets/dexopt/baseline.prof
для APK илиBUNDLE-METADATA/com.android.tools.build.profiles/baseline.prof
для AAB.Общие правила, которые компилируют слишком большую часть приложения, могут замедлить запуск из-за увеличения доступа к диску. Если вы только начинаете работать с базовыми профилями, не беспокойтесь об этом. Однако в зависимости от вашего приложения, а также размера и количества поездок добавление большого количества поездок может привести к снижению производительности. Проверьте производительность своего приложения, опробовав разные профили и проверив, что производительность не снижается после дополнений.