En tant que développeur d'applications, vous pouvez générer automatiquement des profils pour chaque version d'une application à l'aide de la bibliothèque Jetpack Macrobenchmark et de BaselineProfileRule. Nous vous recommandons d'utiliser com.android.tools.build:gradle:8.0.0 ou une version ultérieure, qui offre des améliorations de compilation lorsque vous utilisez des profils de référence.
Définir le générateur de profils de référence
Pour créer des profils de référence à l'aide de la bibliothèque Macrobenchmark, procédez comme suit :
Configurez un module Macrobenchmark dans votre projet Gradle.
Définissez un nouveau test appelé
BaselineProfileGenerator:class BaselineProfileGenerator { @get:Rule val baselineProfileRule = BaselineProfileRule() @Test fun startup() = baselineProfileRule.collectBaselineProfile( packageName = "com.example.app", profileBlock = { startActivityAndWait() } ) }Le générateur peut contenir des interactions avec votre appli au-delà de son démarrage. Cela vous permet d'optimiser les performances d'exécution de votre application, comme le défilement de listes, l'exécution d'animations et la navigation dans une
Activity. Consultez d'autres exemples de tests qui utilisent@BaselineProfileRulepour améliorer les critical user journeys.(Facultatif) Désactivez l'obscurcissement lors de la génération de profils de référence. Pour ce faire, créez un autre fichier ProGuard dans le module de votre application et ajoutez
-dontobfuscateuniquement pour le type de compilationbenchmarkchargé de générer les profils.
Kotlin
buildTypes {
val benchmark by creating {
// Only use benchmark Proguard rules.
proguardFiles("benchmark-rules.pro")
// ...
}
}
Groovy
buildTypes {
benchmark {
// Only use benchmark Proguard rules.
proguardFiles 'benchmark-rules.pro'
// ...
}
}
Générer le profil de référence
Exécutez le générateur en tant que test instrumenté sur un appareil physique en mode root, un émulateur ou un appareil géré par Gradle. Pour configurer un appareil géré, ouvrez le fichier build.gradle.kts. Dans le bloc de configuration testOptions, ajoutez managedDevices et devices, puis créez une définition d'émulateur. Utilisez aosp comme systemImageSource, car vous aurez besoin d'un accès racine au générateur de profils de référence.
Kotlin
testOptions {
managedDevices {
devices {
create ("pixel6Api31", ManagedVirtualDevice::class) {
device = "Pixel 6"
apiLevel = 31
systemImageSource = "aosp"
}
}
}
}
Groovy
testOptions {
managedDevices {
devices {
pixel6Api31(com.android.build.api.dsl.ManagedVirtualDevice) {
device = "Pixel 6"
apiLevel = 31
systemImageSource = "aosp"
}
}
}
}
Gradle crée les tâches requises en fonction du nom de l'appareil sélectionné et des variantes de compilation disponibles dans le module. La tâche est mise en forme comme suit : [emulator_name][flavor][build type]AndroidTest. Vous pouvez l'exécuter à partir d'un terminal :
./gradlew :benchmark:pixel6Api31BenchmarkAndroidTest
Capturer tous les chemins de code requis
Les deux métriques clés pour mesurer le temps de démarrage de l'application sont le temps d'affichage initial (TTID) et le temps d'affichage total (TTFD). Le TTID correspond au temps nécessaire pour afficher le premier frame de l'interface utilisateur de l'application. Le TTFD inclut également le temps d'affichage du contenu chargé de manière asynchrone après l'affichage du frame initial.
Le TTFD est indiqué une fois que la méthode reportFullyDrawn() de ComponentActivity est appelée. Si reportFullyDrawn() n'est jamais appelé, le TTID est indiqué à la place.
Vous devrez peut-être différer l'appel de reportFullyDrawn() jusqu'à la fin du chargement asynchrone. Par exemple, si l'interface utilisateur contient une liste dynamique telle qu'une RecyclerView ou une liste différée, elle peut être renseignée par une tâche en arrière-plan qui se terminera après le premier affichage de la liste et, par conséquent, une fois que l'interface utilisateur sera marquée comme entièrement dessinée. Dans ce cas, le code qui s'exécute une fois que l'interface utilisateur est complètement dessiné n'est pas inclus dans le profil de référence.
Pour inclure la liste de membres dans votre profil de référence, obtenez FullyDrawnReporter à l'aide de getFullyDrawnReporter() et ajoutez-y un "rapporteur" dans le code de votre application. Vous devrez libérer ce rapporteur une fois que la tâche en arrière-plan aura rempli la liste. FullyDrawnReporter n'appelle pas la méthode reportFullyDrawn() tant que tous les rapporteurs ajoutés ne sont pas libérés. De cette façon, le profil de référence inclut les chemins de code requis pour remplir la liste. Cela ne modifie pas le comportement de l'application aux yeux de l'utilisateur, mais permet au profil de référence d'inclure tous les chemins de code nécessaires.
Si votre application utilise Jetpack Compose, vous pouvez utiliser les API suivantes pour indiquer l'état entièrement dessiné :
ReportDrawnindique que votre composable est immédiatement prêt à interagir.ReportDrawnWhenutilise un prédicat, commelist.count > 0, pour indiquer à quel moment votre composable sera prêt à interagir.ReportDrawnAfterutilise une méthode de suspension qui, lorsqu'elle se termine, indique que votre composable est prêt à interagir.
Plug-in Baseline Profile Gradle
Le plug-in Baseline Profile Gradle facilite la génération et la maintenance des profils de référence. Il suit les étapes nécessaires pour générer et installer un profil de référence dans votre module d'application.
Pour utiliser ce plug-in, ajoutez un module de tests instrumentés à votre projet et définissez un ensemble de tests qui simulera les parcours utilisateur critiques dans l'ensemble de votre application. Lorsque vous exécutez le test instrumenté, le plug-in Profil de référence Gradle suit toutes les classes et méthodes exécutées pendant ces parcours utilisateur, et génère un profil de référence basé sur ces classes et méthodes. Il copie ensuite le profil de référence généré dans le module d'application.
Le module de test d'instrumentation est le producteur de profil. Le module d'application est le consommateur de profil.
Les principaux domaines sur lesquels vous devez vous concentrer sont la configuration initiale et la création des tests pour simuler les parcours utilisateur critiques.
Conditions requises pour utiliser le plug-in
- AGP 8.0.0 ou version ultérieure
- Dépendance à la dernière version du plug-in Gradle (alpha13 ou ultérieure)
Utiliser le plug-in
L'exemple suivant suppose l'existence d'un module d'application nommé :app.
L'exemple suivant comporte deux modules :
- Consommateur du profil : module d'application pour lequel générer le profil. Dans l'exemple suivant, il s'agit de
:app. - Producteur de profil : module de test du profil de référence contenant les tests d'instrumentation permettant de générer le profil. Dans l'exemple suivant, il s'appelle
:baseline-profile.
Pour utiliser le plug-in, procédez comme suit :
- Créez un module
com.android.test, par exemple:baseline-profile. - Configurez
build.gradlepour:baseline-profile: - Appliquez le plug-in
androidx.baselineprofile. - Assurez-vous que
targetProjectPathpointe vers le module:app. - Si vous le souhaitez, ajoutez un GMD. Dans l'exemple suivant, il s'agit de
pixel6Api31. S'il n'est pas spécifié, le plug-in utilise un appareil connecté soit émulé, soit physique. - Appliquez la configuration de votre choix, comme indiqué dans l'exemple suivant.
- Créez un test de profil de référence dans le module de test
:baseline-profile. L'exemple suivant est un test qui lance l'application et attend l'inactivité. - Mettez à jour la configuration dans
build.gradledans le module d'application:app. - Appliquez le plug-in
androidx.baselineprofile. - Ajoutez une dépendance
baselineProfileau module:baseline-profile. - Générez le profil en exécutant le code suivant :
./gradlew :app:generateBaselineProfile.
Kotlin
plugins {
id("com.android.test")
id("androidx.baselineprofile")
}
android {
// There are no changes here. It's documented for completeness.
defaultConfig {
...
}
// This must point to the app module.
targetProjectPath = ":app"
// This is the optional managed device.
testOptions.managedDevices.devices {
pixel6Api31(com.android.build.api.dsl.ManagedVirtualDevice) {
device = "Pixel 6"
apiLevel = 31
systemImageSource = "aosp"
}
}
}
// There are no changes here. It's documented for completeness.
dependencies { ... }
// This is the plugin configuration. Everything is optional. Defaults are in the
// comments. In this example, you use the GMD added earlier and disable
// connected devices.
baselineProfile {
// This specifies the managed devices to use that you run the tests on. The
// default is none.
managedDevices += "pixel6Api31"
// This enables using connected devices to generate profiles. The default is
// true. When using connected devices, they must be rooted or API 33 and
// higher.
useConnectedDevices = false
}
Groovy
plugins {
id 'com.android.test'
id 'androidx.baselineprofile'
}
android {
// There are no changes here. It's documented for completeness.
defaultConfig {
...
}
// This must point to the app module.
targetProjectPath ':app'
// This is the optional managed device.
testOptions.managedDevices.devices {
pixel6Api31(com.android.build.api.dsl.ManagedVirtualDevice) {
device 'Pixel 6'
apiLevel 31
systemImageSource 'aosp'
}
}
}
// There are no changes here. It's documented for completeness.
dependencies { ... }
// This is the plugin configuration. Everything is optional. Defaults are in the
// comments. In this example, you use the GMD added earlier and disable
// connected devices.
baselineProfile {
// This specifies the managed devices to use that you run the tests on. The
// default is none.
managedDevices ['pixel6Api31']
// This enables using connected devices to generate profiles. The default is
// true. When using connected devices, they must be rooted or API 33 and
// higher.
useConnectedDevices false
}
Kotlin
class BaselineProfileGenerator {
@get:Rule
val baselineRule = BaselineProfileRule()
@Test
fun startupBaselineProfile() {
baselineRule.collectBaselineProfile("com.myapp") {
startActivityAndWait()
}
}
}
Java
public class BaselineProfileGenerator {
@Rule
Public BaselineProfileRule baselineRule = new BaselineProfileRule();
@Test
Public void startupBaselineProfile() {
baselineRule.collectBaselineProfile(
"com.myapp",
(scope -> {
scope.startActivityAndWait();
Return Unit.INSTANCE;
})
}
}
}
Kotlin
plugins {
id("com.android.application")
id("androidx.baselineprofile")
}
android {
// There are no changes to the `android` block.
...
}
dependencies {
...
// Add a baselineProfile dependency to the :baseline-profile module.
baselineProfile(project(":baseline-profile"))
}
Groovy
plugins {
id 'com.android.application'
id 'androidx.baselineprofile'
}
android {
// No changes to the `android` block.
...
}
dependencies {
...
// Add a baselineProfile dependency to the :baseline-profile module.
baselineProfile ':baseline-profile"'
}
À la fin de la tâche de génération, le profil de référence est stocké dans app/src/release/generated/baselineProfiles.
Générer un profil de référence pour une bibliothèque
Dans l'exemple suivant, le module de bibliothèque est nommé :library, tandis que le module d'application est nommé :sample-app, qui contient une application utilisant la bibliothèque.
Dans cet exemple, vous aurez besoin de trois modules :
- Cible de l'application : module d'application contenant une application exemple. Dans l'exemple suivant, il s'agit de
:sample-app. - Consommateur du profil : module de bibliothèque pour lequel générer le profil. Dans l'exemple suivant, il s'agit de
:library. - Producteur de profil : module de test du profil de référence contenant les tests d'instrumentation permettant de générer le profil.
Pour générer un profil de référence pour une bibliothèque, procédez comme suit :
- Créez un module
com.android.test, par exemple:baseline-profile. - Configurez
build.gradlepour:baseline-profile: - Appliquez le plug-in
androidx.baselineprofile. - Assurez-vous que
targetProjectPathpointe vers le module:sample-app. - Si vous le souhaitez, ajoutez un GMD. Dans l'exemple suivant, il s'agit de
pixel6Api31. - Appliquez la configuration de votre choix, comme indiqué dans l'exemple suivant.
- Créez un test de profil de référence dans le module de test
:baseline-profile. Il doit être spécifique à l'application exemple et utiliser toutes les fonctionnalités de la bibliothèque. - Mettez à jour la configuration dans
build.gradledans le module de bibliothèque:library. - Appliquez le plug-in
androidx.baselineprofile. - Ajoutez une dépendance
baselineProfileau module:baseline-profile. - Appliquez la configuration de plug-in de votre choix, comme illustré dans l'exemple suivant.
- Mettez à jour la configuration dans
build.gradledans le module d'application:sample-app, en ajoutant le plug-inandroidx.baselineprofile. - Générez le profil en exécutant le code suivant :
./gradlew :library:generateBaselineProfile.
Kotlin
plugins {
id("com.android.test")
id("androidx.baselineprofile")
}
android {
// There are no changes here. It's reported for completeness.
defaultConfig {
minSdkVersion 23
testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
}
// This must point to the app module.
targetProjectPath = ":app"
// This is the optional managed device.
testOptions.managedDevices.devices {
create("pixel6Api31") {
device = "Pixel 6"
apiLevel = 31
systemImageSource = "aosp"
}
}
}
// There's nothing to change here.
dependencies { ... }
// This is the plugin configuration. Everything is optional. Defaults are in the
// comments. In this example, you use the GMD added earlier and disable
// connected devices.
baselineProfile {
// This specifies the managed devices to use that you run the tests on. The
// default is none.
managedDevices += "pixel6Api31"
// This enables using connected devices to generate profiles. The default is
// true. When using connected devices, they must be rooted or API 33 and
// higher.
useConnectedDevices = false
}
Groovy
plugins {
id 'com.android.test'
id 'androidx.baselineprofile'
}
android {
// There are no changes here. It's reported for completeness.
defaultConfig {
...
}
// This must point to the app module.
targetProjectPath ':app'
// This is the optional managed device.
testOptions.managedDevices.devices {
pixel6Api31(com.android.build.api.dsl.ManagedVirtualDevice) {
device 'Pixel 6'
apiLevel 31
systemImageSource 'aosp'
}
}
}
// There's nothing to change here.
dependencies { ... }
// This is the plugin configuration. Everything is optional. Defaults are in the
// comments. In this example, you use the GMD added earlier and disable
// connected devices.
baselineProfile {
// This specifies the managed devices to use that you run the tests on. The
// default is none.
managedDevices ['pixel6Api31']
// This enables using connected devices to generate profiles. The default is
// true. When using connected devices, they must be rooted or API 33 and
// higher.
useConnectedDevices false
}
Kotlin
plugins {
id("com.android.library")
id("androidx.baselineprofile")
}
// There are no changes to the android block.
android { ... }
dependencies {
...
// Add a baselineProfile dependency to the :baseline-profile module.
baselineProfile(project(":baseline-profile"))
}
// This is the plugin configuration.
baselineProfile {
// This filters the generated profile rules. In this example, you keep
// all the classes in com.library and in all the subpackages.
filter {
include "com.mylibrary.**"
}
}
Groovy
plugins {
id 'com.android.library'
id 'androidx.baselineprofile'
}
// There are no changes to the android block.
android { ... }
dependencies {
...
// Add a baselineProfile dependency to the :baseline-profile module.
baselineProfile ':baseline-profile'
}
// This is the plugin configuration.
baselineProfile {
// This filters the generated profile rules. In this example, you keep
// all the classes in com.library and in all the subpackages.
filter {
include 'com.mylibrary.**'
}
}
Kotlin
plugins {
...
id("androidx.baselineprofile")
}
// There are no other changes to the configuration.
Groovy
plugins {
...
id 'androidx.baselineprofile'
}
// There are no other changes to the configuration.
À la fin de la tâche de génération, le profil de référence est stocké dans library/src/main/generated/baselineProfiles.
DSL
Bien que la présente documentation fasse référence au plug-in Baseline Profile Gradle en tant que plug-in unique, trois plug-ins effectuent des tâches différentes en fonction du module auquel ils s'appliquent. Dans cette documentation, l'ID de plug-in est androidx.baselineprofile, mais il couvre les trois plug-ins.
Pour mieux comprendre ce concept, consultez les modules suivants dont vous avez besoin pour générer un profil de référence :
- Une application sur laquelle exécuter les tests du profil de référence. Il s'agit d'un module d'application Android auquel
com.android.applicationest appliqué. Lors de la génération d'un profil pour une bibliothèque, il peut s'agir d'une application exemple. Lorsque vous générez un profil pour une application, il s'agit de l'application elle-même. Dans l'exemple suivant, le plug-inandroidx.baselineprofileappliqueandroidx.baselineprofile.apptargeten interne. - Un module de test du profil de référence contenant les tests à exécuter. Il s'agit d'un module de test Android auquel
com.android.testest appliqué. Dans l'exemple suivant, le plug-inandroidx.baselineprofileappliqueandroidx.baselineprofile.produceren interne. - Un module qui consomme le profil de référence dans le processus de compilation. Il s'agit d'un module d'application Android
com.android.applicationou d'un module de bibliothèquecom.android.library. Dans l'exemple suivant, le plug-inandroidx.baselineprofileappliqueandroidx.baselineprofile.consumeren interne.
Cible de l'application (androidx.baselineprofile.apptarget)
Aucune configuration n'est définie.
Producteur de profil (androidx.baselineprofile.producer)
Prise en charge des appareils gérés par Gradle
Pour utiliser un appareil géré par Gradle, ajoutez-en un dans la configuration build.gradle du module du producteur de profil, comme illustré dans l'exemple suivant :
Kotlin
android {
testOptions.managedDevices.devices {
create("pixel6Api31") {
device = "Pixel 6"
apiLevel = 31
systemImageSource = "aosp"
}
}
}
Groovy
android {
testOptions.managedDevices.devices {
pixel6Api31(ManagedVirtualDevice) {
device 'Pixel 6'
apiLevel = 31
systemImageSource 'aosp'
}
}
}
Vous pouvez ensuite utiliser le GMD créé pour générer des profils de référence en l'ajoutant au code suivant :
Kotlin
baselineProfile {
managedDevices += "pixel6Api31"
}
Groovy
baselineProfile {
managedDevices = ['pixel6Api31']
}
Les exemples suivants sont des options supplémentaires permettant d'activer ou de désactiver les appareils connectés pour générer des profils de référence.
Kotlin
baselineProfile {
...
useConnectedDevices = true
}
Groovy
baselineProfile {
...
useConnectedDevices true
}
Consommateur de profil (androidx.baselineprofile.consumer)
Générer des profils par type de produit et un profil pour toutes les variantes
Vous pouvez générer des profils par variante, par type ou par fichier unique à utiliser pour toutes les variantes. Vous pouvez contrôler ce comportement via le paramètre de fusion, comme illustré dans l'exemple suivant.
Kotlin
baselineProfile {
mergeIntoMain = true / false
}
Groovy
baselineProfile {
mergeIntoMain true / false
}
- Définissez
mergeIntoMainsurtruepour fusionner tous les profils générés pour chaque variante dans un seul profil. Il n'est pas possible de générer des profils de référence par variante lorsque ce paramètre esttrue. Il n'existe donc qu'une seule tâche de génération nomméegenerateBaselineProfile. La sortie du profil estsrc/main/generated/baselineProfiles. - Définissez
mergeIntoMainsurfalsepour désactiver la fusion et avoir un seul profil par variante. Dans l'exemple suivant, il est possible de générer des profils de référence par variante. Il existe donc plusieurs tâches de génération, une par variante. Par exemple, lorsqu'il existe deux types de produit (par exemple, un gratuit et un payant) et un type de compilation, les tâches générées sont les suivantes :generateFreeReleaseBaselineProfilegeneratePaidReleaseBaselineProfilegenerateReleaseBaselineProfile
Par défaut, ce paramètre est true pour les bibliothèques et false pour les applications.
Vous pouvez également spécifier le comportement suivant par variante :
Kotlin
baselineProfile {
variants {
freeRelease {
mergeIntoMain = true / false
}
}
}
Groovy
baselineProfile {
variants {
freeRelease {
mergeIntoMain true / false
}
}
}
Dans l'exemple précédent, les variantes dans lesquelles l'indicateur est défini sur true sont toutes fusionnées dans src/main/generated/baselineProfiles, tandis que les profils des variantes dont l'indicateur est défini sur "false" sont conservés dans le dossier src/<variant>/generated/baselineProfiles.
Générer automatiquement un profil de référence lors de l'assemblage d'une nouvelle version
Vous pouvez déclencher manuellement la génération de profils de référence via la tâche generateBaselineProfile ou automatiquement lors de la compilation d'une version. Ce paramètre est contrôlé par l'indicateur suivant :
Kotlin
baselineProfile {
automaticallyGenerateDuringBuild = true / false
}
Groovy
baselineProfile {
automaticallyGenerateDuringBuild true / false
}
Si cet indicateur est défini sur true, un nouveau profil de référence est généré pour chaque assemblage. De cette façon, le profil le plus à jour est inclus dans le build. Autrement dit, l'exécution d'une tâche d'assemblage d'un build, telle que ./gradlew:app:assembleRelease, déclenche également :app:generateReleaseBaselineProfile. Cette opération lance également les tests d'instrumentation du profil de référence et compile le build du profil de référence sur lequel ils seront exécutés.
Bien que cela permette aux utilisateurs de bénéficier des meilleures performances, la durée de compilation augmente également en raison des doubles tests de compilation et d'instrumentation.
Vous pouvez également spécifier ce comportement par variante, comme illustré dans l'exemple suivant :
Kotlin
baselineProfile {
variants {
freeRelease {
automaticallyGenerateDuringBuild = true / false
}
}
}
Groovy
baselineProfile {
variants {
freeRelease {
automaticallyGenerateDuringBuild true / false
}
}
}
Dans l'exemple précédent, la tâche generateFreeReleaseBaselineProfile s'exécute au démarrage de assembleFreeRelease. Cela peut être utile lorsque l'utilisateur souhaite disposer, par exemple, d'une release pour un build de distribution qui génère toujours le profil lors de la compilation, et d'un build releaseWithoutProfile pour les tests internes.
Stocker les profils de référence dans des sources
Vous pouvez stocker les profils de référence dans le répertoire source via l'indicateur saveInSrc :
true: le profil de référence est stocké danssrc/<variant>/generated/baselineProfiles. Cela vous permet de valider le dernier profil généré avec vos sources.false: le profil de référence est stocké dans les fichiers intermédiaires du répertoire de compilation. Lorsque vous validez votre code, vous n'enregistrez donc pas le dernier profil généré.
Kotlin
baselineProfile {
saveInSrc = true / false
}
Groovy
baselineProfile {
saveInSrc true / false
}
Vous pouvez également spécifier le comportement suivant par variante :
Kotlin
baselineProfile {
variants {
freeRelease {
saveInSrc = true / false
}
}
}
Groovy
baselineProfile {
variants {
freeRelease {
saveInSrc true / false
}
}
}
Filtrer les règles de profil
Vous pouvez filtrer les règles de profil de référence générées via la configuration du plug-in. Cette approche est particulièrement utile pour les bibliothèques si vous souhaitez exclure des règles de profil pour les classes et les méthodes qui font partie d'autres dépendances de l'application exemple ou de la bibliothèque. Les filtres peuvent spécifier, inclure et exclure des règles pour les packages et les classes. Lorsque vous spécifiez uniquement des exclusions, seules les règles correspondantes du profil de référence sont exclues. Les autres sont incluses.
La spécification des filtres peut se présenter comme suit :
- Nom de package se terminant par des caractères génériques doubles pour correspondre au package spécifié et à tous les sous-packages. Par exemple,
com.example.**correspond àcom.example.fooetcom.example.foo.bar. - Nom de package se terminant par un caractère générique pour correspondre uniquement au package spécifié. Par exemple,
com.example.*correspond àcom.example.foo, mais pas àcom.example.foo.bar. - Noms de classe correspondant à une classe spécifique, par exemple
com.example.MyClass.
Les exemples suivants montrent comment inclure et exclure des packages spécifiques :
Kotlin
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.**")
}
}
Groovy
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.**'
}
}
Les filtres sont également compatibles avec les variantes, et vous pouvez les exprimer comme suit :
Kotlin
// 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.**")
}
}
}
}
Groovy
// 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.**'
}
}
}
}
Appliquer les règles générées
Le générateur de profils de référence crée un fichier texte HRF (Human Readable Format) sur l'appareil et le copie sur votre machine hôte. Pour appliquer le profil généré à votre code, procédez comme suit :
Recherchez le fichier HRF dans le dossier de compilation du module dans lequel vous générerez le profil :
[module]/build/outputs/managed_device_android_test_additional_output/[device].Les profils suivent le format de dénomination
[class name]-[test method name]-baseline-prof.txt, qui se présente comme suit :BaselineProfileGenerator-startup-baseline-prof.txtCopiez le profil généré dans
src/flavor/baselineProfilesdans votre module d'application pour chaque type donné. Pour appliquer le profil à tous les types, copiez-le danssrc/main/baselineProfiles.Ajoutez une dépendance à la bibliothèque ProfileInstaller dans le fichier
build.gradle.ktsde votre application pour activer la compilation locale du profil de référence où les profils cloud ne sont pas disponibles. Il s'agit du seul moyen de télécharger indépendamment un profil de référence en local.dependencies { implementation("androidx.profileinstaller:profileinstaller:1.3.1") }Créez la version de production de votre application, tandis que les règles HRF appliquées sont compilées au format binaire et incluses dans l'APK ou l'AAB. Distribuez ensuite votre application comme vous le faites habituellement.
Remarques supplémentaires
Lorsque vous créez des profils de référence, gardez à l'esprit les points suivants :
La taille des profils de référence compilés doit être inférieure à 1,5 Mo. Cela ne s'applique pas au format de texte de vos fichiers sources, qui sont généralement beaucoup plus volumineux avant la compilation. Vérifiez la taille du profil de référence de votre binaire en le recherchant dans l'artefact de sortie sous
assets/dexopt/baseline.profpour l'APK ouBUNDLE-METADATA/com.android.tools.build.profiles/baseline.profpour l'AAB.Les règles générales qui compilent une trop grande partie de l'application peuvent ralentir le démarrage en raison de l'augmentation des accès au disque. Si vous débutez avec les profils de référence, vous n'avez pas à vous en soucier. Toutefois, selon votre application, ainsi que la taille et le nombre de parcours, l'ajout de nombreux parcours peut nuire aux performances. Testez les performances de votre application en essayant différents profils et en vérifiant que les performances ne régressent pas après les ajouts.