Il plug-in Baseline Profile per Gradle semplifica la generazione e la gestione dei profili di riferimento. Ti aiuta a svolgere le seguenti attività:
- Crea nuovi Profili di riferimento per la tua app.
- Crea nuovi profili di riferimento per la tua raccolta.
- Personalizza la generazione del profilo di riferimento.
Questa pagina spiega come utilizzare il plug-in Gradle Baseline Profile per personalizzare la generazione dei profili di riferimento.
Requisiti dei plug-in
- AGP 8.0 o superiore
- Dipendenza dalla versione più recente del plug-in Gradle
Utilizzare un dispositivo gestito da Gradle per generare profili di riferimento
Per utilizzare un dispositivo gestito Gradle (GMD) per generare il profilo di riferimento, aggiungine uno nella configurazione build.gradle.kts
del modulo producer profilo (probabilmente il modulo di test :baselineprofile
), come mostrato nell'esempio seguente:
Kotlin
android { testOptions.managedDevices.devices { create<com.android.build.api.dsl.ManagedVirtualDevice>("pixel6Api31") { device = "Pixel 6" apiLevel = 31 systemImageSource = "aosp" } } }
trendy
android { testOptions.managedDevices.devices { pixel6Api31(ManagedVirtualDevice) { device 'Pixel 6' apiLevel = 31 systemImageSource 'aosp' } } }
Utilizza GMD per generare profili di riferimento aggiungendoli alla configurazione del plug-in Gradle Baseline Profile nel seguente modo:
Kotlin
baselineProfile { managedDevices += "pixel6Api31" }
trendy
baselineProfile { managedDevices = ['pixel6Api31'] }
Quando utilizzi un GMD per generare profili di riferimento, imposta useConnectedDevices
su
false
:
Kotlin
baselineProfile { ... useConnectedDevices = false }
trendy
baselineProfile { ... useConnectedDevices false }
Generare profili di riferimento per varianti diverse
Puoi generare profili di riferimento per variante, per versione o come singolo file da utilizzare per tutte le varianti. Controlla questo comportamento tramite l'impostazione di unione, come mostrato nell'esempio seguente.
Kotlin
baselineProfile { mergeIntoMain = true }
trendy
baselineProfile { mergeIntoMain true }
Per unire i profili generati per tutte le varianti in un unico profilo, imposta mergeIntoMain
su true
. Non è possibile generare profili di riferimento per variante
quando questa impostazione è true
, perciò c'è una singola attività Gradle denominata
generateBaselineProfile
. L'output del profilo è in
src/main/generated/baselineProfiles
.
Per disattivare l'unione e avere un profilo per variante, imposta mergeIntoMain
su false
. In questo caso, esistono più attività Gradle specifiche per le varianti. Ad esempio, quando esistono due versioni, senza costi e a pagamento, e un tipo di build di release, le attività sono le seguenti:
* `generateFreeReleaseBaselineProfile`
* `generatePaidReleaseBaselineProfile`
* `generateReleaseBaselineProfile`
Per specificare il comportamento di unione per variante, utilizza il seguente codice:
Kotlin
baselineProfile { variants { freeRelease { mergeIntoMain = true } } }
trendy
baselineProfile { variants { freeRelease { mergeIntoMain true } } }
Nell'esempio precedente, le varianti in cui il flag è impostato su true
sono state unite in src/main/generated/baselineProfiles
, mentre i profili delle varianti in cui il flag è impostato su false
vengono conservati nella cartella src/<variant>/generated/baselineProfiles
.
Il valore predefinito di mergeIntoMain
è true
per le librerie e false
per le app.
Genera automaticamente profili di riferimento durante l'assemblaggio di una nuova release
Puoi configurare i profili di riferimento in modo che vengano generati automaticamente con ogni build di release, anziché utilizzare manualmente l'attività generateBaselineProfile
. Con la generazione automatica, il profilo più aggiornato è incluso nella build della release.
Per abilitare la generazione automatica per le build della release, utilizza il flag automaticGenerationDuringBuild
:
Kotlin
baselineProfile { automaticGenerationDuringBuild = true }
trendy
baselineProfile { automaticGenerationDuringBuild true }
L'impostazione del flag automaticGenerationDuringBuild
su true
attiva la generazione di un nuovo profilo di riferimento per ogni assemblaggio di release. Ciò significa che l'esecuzione di un'attività di compilazione della release assemblata, come ./gradlew:app:assembleRelease
, attiva anche :app:generateReleaseBaselineProfile
, avvia i test di strumentazione del profilo di riferimento e crea la build del profilo di riferimento su cui vengono eseguiti.
Sebbene la generazione automatica aiuti gli utenti a ottenere i migliori vantaggi in termini di prestazioni, aumenta anche i tempi di build a causa dei doppi test di build e di strumentazione.
Puoi anche specificare questo comportamento per variante, come mostrato nell'esempio seguente:
Kotlin
baselineProfile { variants { freeRelease { automaticGenerationDuringBuild = true } } }
trendy
baselineProfile { variants { freeRelease { automaticGenerationDuringBuild true } } }
Nell'esempio precedente, l'attività generateFreeReleaseBaselineProfile
viene eseguita
all'avvio di assembleFreeRelease
. Ciò è utile se l'utente vuole avere, ad esempio, una build release
per la distribuzione che genera sempre il profilo durante la creazione e una build releaseWithoutProfile
per i test interni.
Archivia i profili di riferimento nelle origini
Puoi archiviare i profili di riferimento nella directory di origine tramite il flag saveInSrc
:
true
: il profilo di riferimento viene archiviato insrc/<variant>/generated/baselineProfiles
. In questo modo puoi eseguire il commit del profilo generato più di recente con le tue origini.false
: il profilo di riferimento viene archiviato nei file intermedi nella directory di build. In questo modo, quando esegui il commit del codice, non salvi il profilo generato più recente.
Kotlin
baselineProfile { saveInSrc = true }
trendy
baselineProfile { saveInSrc true }
Puoi anche specificare questo comportamento per variante:
Kotlin
baselineProfile { variants { freeRelease { saveInSrc = true } } }
trendy
baselineProfile { variants { freeRelease { saveInSrc true } } }
Filtra regole del profilo
Il plug-in per Gradle Baseline Profile ti consente di filtrare le regole del profilo Baseline generate. Ciò è particolarmente utile per le librerie, se vuoi escludere le regole del profilo per classi e metodi che fanno parte di altre dipendenze dell'app di esempio o della libreria stessa. I filtri possono includere ed escludere pacchetti e classi specifici. Quando specifichi solo le esclusioni, vengono escluse solo le regole corrispondenti del profilo di riferimento e tutto il resto è incluso.
La specifica dei filtri può essere una delle seguenti:
- Nome del pacchetto che termina con caratteri jolly doppi per corrispondere al pacchetto specificato e a tutti i sottopacchetti. Ad esempio,
com.example.**
corrisponde acom.example.method
ecom.example.method.bar
. - Nome del pacchetto che termina con un carattere jolly per corrispondere solo al pacchetto specificato. Ad
esempio,
com.example.*
corrisponde acom.example.method
ma non corrisponde acom.example.method.bar
. - Nomi dei corsi corrispondenti a una classe specifica, ad esempio
com.example.MyClass
.
I seguenti esempi mostrano come includere ed escludere pacchetti specifici:
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.**") } }
trendy
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.**' } }
Personalizza le regole di filtro per diverse varianti nel seguente modo:
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.**") } } } }
trendy
// 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.**' } } } }
Puoi anche filtrare le regole utilizzando l'argomento filterPredicate
in BaselineProfileRule.collect()
, ma ti consigliamo di utilizzare il plug-in Gradle per filtrare perché offre un modo più semplice per filtrare i sottopacchetti e un'unica posizione per configurare l'intero modulo.
Personalizzare i tipi di build di benchmark e profilo di riferimento
Il plug-in Gradle Baseline Profile crea tipi di build aggiuntivi per generare i profili ed eseguire benchmark. Questi tipi di build sono preceduti dal prefisso
benchmark
e nonMinified
. Ad esempio, per il tipo di build release
, il
plug-in crea i tipi di build benchmarkRelease
e nonMinifiedRelease
.
Questi tipi di build sono configurati automaticamente per il caso d'uso specifico e generalmente non richiedono alcuna personalizzazione. Tuttavia, in alcuni casi potrebbe essere comunque utile applicare alcune opzioni personalizzate, ad esempio applicare una configurazione di firma diversa.
Puoi personalizzare i tipi di build generati automaticamente utilizzando un sottoinsieme di proprietà dei tipi di build. Le proprietà non utilizzabili vengono sostituite. L'esempio seguente mostra come personalizzare i tipi di build aggiuntivi e le proprietà che vengono sostituite:
Kotlin
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 } } }
trendy
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 } } }
Note aggiuntive
Quando crei profili di riferimento, tieni presente quanto segue:
I profili di riferimento compilati devono avere dimensioni inferiori a 1,5 MB. Ciò non si applica al formato del testo nei file di origine, che in genere sono molto più grandi prima della compilazione. Verifica le dimensioni del tuo profilo di riferimento binario individuandolo nell'artefatto di output in
assets/dexopt/baseline.prof
per l'APK oBUNDLE-METADATA/com.android.tools.build.profiles/baseline.prof
per AAB.Regole ampie che compilano una quantità eccessiva di applicazioni possono rallentare l'avvio a causa di un maggiore accesso al disco. Se hai appena iniziato con i profili di riferimento, non preoccuparti. Tuttavia, a seconda dell'app e delle dimensioni e del numero di percorsi, l'aggiunta di molti percorsi può comportare prestazioni non ottimali. Testa le prestazioni della tua app provando profili diversi e verificando che le prestazioni non regredino dopo le aggiunte.