Настройка создания базового профиля

Плагин Baseline Profile Gradle упрощает создание и поддержку Baseline Profiles . Это поможет вам решить следующие задачи:

На этой странице объясняется, как использовать плагин Gradle Baseline Profile для настройки создания базовых профилей.

Требования к плагину

Используйте управляемые устройства 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 базового профиля следующим образом:

Котлин 

baselineProfile {
    managedDevices += "pixel6Api31"
}

классный 

baselineProfile {
    managedDevices = ['pixel6Api31']
}

Когда вы используете GMD для создания базовых профилей, установите для useConnectedDevices значение false :

Котлин 

baselineProfile {
    ...
    useConnectedDevices = false
}

классный 

baselineProfile {
    ...
    useConnectedDevices false
}

Создание базовых профилей для различных вариантов

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

Котлин 

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 :

  • 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 {
            ...
        }
        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")
        }
        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.

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

Кодлабы

Погрузитесь в макробенчмаркинг для измерения производительности.
Узнать больше
Создайте собственный базовый профиль, адаптированный к приложению Android, и проверьте его эффективность.
Узнать больше
Назад
Создание базовых профилей для библиотеки
Далее
Измерьте с помощью библиотеки Macrobenchmark