Das Gradle-Plug-in „Baseline Profile“ vereinfacht das Generieren und Verwalten von Baseline-Profilen. Er unterstützt Sie bei den folgenden Aufgaben:
- Erstellen Sie neue Baseline-Profile für Ihre App.
- Erstellen Sie neue Baseline-Profile für Ihre Bibliothek.
- Passe die Generierung des Baseline-Profils an.
Auf dieser Seite wird erläutert, wie Sie mit dem Gradle-Plug-in „Baseline Profile“ die Generierung Ihrer Baseline-Profile anpassen.
Anforderungen an Plug-ins
- AGP 8.0 oder höher
- Abhängigkeit von der neuesten Gradle-Plug-in-Version
Mit Gradle-verwalteten Geräten Baseline-Profile generieren
Wenn Sie ein Gradle Managed Device (GMD) zum Generieren Ihres Baseline-Profils verwenden möchten, fügen Sie eines in der build.gradle.kts
-Konfiguration des Profilerstellungsmoduls (z. B. das Testmodul :baselineprofile
) hinzu, wie im folgenden Beispiel gezeigt:
Kotlin
android { testOptions.managedDevices.devices { create<com.android.build.api.dsl.ManagedVirtualDevice>("pixel6Api31") { device = "Pixel 6" apiLevel = 31 systemImageSource = "aosp" } } }
Groovig
android { testOptions.managedDevices.devices { pixel6Api31(ManagedVirtualDevice) { device 'Pixel 6' apiLevel = 31 systemImageSource 'aosp' } } }
Verwenden Sie GMD, um Baseline-Profile zu generieren. Fügen Sie es dazu der Konfiguration des Gradle-Plug-ins „Baseline Profile“ so hinzu:
Kotlin
baselineProfile { managedDevices += "pixel6Api31" }
Groovig
baselineProfile { managedDevices = ['pixel6Api31'] }
Wenn Sie Baseline-Profile mit einem GMD generieren, legen Sie useConnectedDevices
auf false
fest:
Kotlin
baselineProfile { ... useConnectedDevices = false }
Groovig
baselineProfile { ... useConnectedDevices false }
Basisprofile für verschiedene Varianten erstellen
Sie können Baseline-Profile pro Variante, pro Flavor oder als einzelne Datei erstellen, die für alle Varianten verwendet werden soll. Sie können dieses Verhalten über die Zusammenführungseinstellung steuern, wie im folgenden Beispiel gezeigt.
Kotlin
baselineProfile { mergeIntoMain = true }
Groovig
baselineProfile { mergeIntoMain true }
Wenn Sie die generierten Profile für alle Varianten in einem einzigen Profil zusammenführen möchten, setzen Sie mergeIntoMain
auf true
. Es ist nicht möglich, Baseline-Profile pro Variante zu generieren, wenn diese Einstellung auf true
festgelegt ist. Daher gibt es eine einzelne Gradle-Aufgabe mit dem Namen generateBaselineProfile
. Das Profil wird unter src/main/generated/baselineProfiles
ausgegeben.
Wenn Sie das Zusammenführen deaktivieren und ein Profil pro Variante haben möchten, setzen Sie mergeIntoMain
auf false
. In diesem Fall sind mehrere variantenspezifische Gradle-Aufgaben vorhanden. Wenn es beispielsweise zwei Varianten, z. B. kostenlos und kostenpflichtig, und einen Release-Build-Typ gibt, sind die Aufgaben die folgenden:
* `generateFreeReleaseBaselineProfile`
* `generatePaidReleaseBaselineProfile`
* `generateReleaseBaselineProfile`
Verwenden Sie den folgenden Code, um das Zusammenführungsverhalten pro Variante festzulegen:
Kotlin
baselineProfile { variants { freeRelease { mergeIntoMain = true } } }
Groovig
baselineProfile { variants { freeRelease { mergeIntoMain true } } }
Im vorherigen Beispiel werden die Varianten, für die das Flag auf true
gesetzt ist, alle in src/main/generated/baselineProfiles
zusammengeführt. Die Profile für die Varianten, für die das Flag auf false
gesetzt ist, bleiben dagegen im Ordner src/<variant>/generated/baselineProfiles
.
Standardmäßig ist mergeIntoMain
für Bibliotheken auf true
und für Apps auf false
gesetzt.
Beim Zusammenstellen eines neuen Release automatisch Referenzprofile generieren
Sie können Referenzprofile so konfigurieren, dass sie mit jedem Release-Build automatisch generiert werden, anstatt die Aufgabe generateBaselineProfile
manuell zu verwenden. Bei der automatischen Generierung ist das aktuellste Profil im Release-Build enthalten.
Verwenden Sie das Flag automaticGenerationDuringBuild
, um die automatische Generierung von Release-Builds zu aktivieren:
Kotlin
baselineProfile { automaticGenerationDuringBuild = true }
Groovig
baselineProfile { automaticGenerationDuringBuild true }
Wenn Sie das Flag automaticGenerationDuringBuild
auf true
setzen, wird für jede Release-Assembly ein neues Referenzprofil generiert. Das bedeutet, dass durch das Ausführen einer Aufgabe zum Zusammenstellen des Release-Builds wie ./gradlew:app:assembleRelease
auch :app:generateReleaseBaselineProfile
ausgelöst, die Instrumentierungstests für das Baseline-Profil gestartet und der Build des Baseline-Profils erstellt wird, auf dem sie ausgeführt werden.
Durch die automatische Generierung können Nutzer zwar die besten Leistungsvorteile erzielen, sie verlängert jedoch auch die Build-Dauer aufgrund der doppelten Build- und Instrumentierungstests.
Sie können dieses Verhalten auch für einzelne Varianten festlegen, wie im folgenden Beispiel gezeigt:
Kotlin
baselineProfile { variants { freeRelease { automaticGenerationDuringBuild = true } } }
Groovig
baselineProfile { variants { freeRelease { automaticGenerationDuringBuild true } } }
Im vorherigen Beispiel wird die Aufgabe generateFreeReleaseBaselineProfile
beim Starten von assembleFreeRelease
ausgeführt. Das ist hilfreich, wenn der Nutzer beispielsweise einen release
für einen Distributions-Build haben möchte, der beim Erstellen immer das Profil generiert, und einen releaseWithoutProfile
-Build für interne Tests.
Referenzprofile in Quellen speichern
Sie können Baseline-Profile über das Flag saveInSrc
im Quellverzeichnis speichern:
true
: Das Baseline-Profil wird insrc/<variant>/generated/baselineProfiles
gespeichert. So können Sie das neueste generierte Profil in Ihre Quellen einbinden.false
: Das Baseline-Profil wird in den Zwischendateien im Build-Verzeichnis gespeichert. Auf diese Weise speichern Sie nicht das zuletzt generierte Profil, wenn Sie Ihren Code mit Commit speichern.
Kotlin
baselineProfile { saveInSrc = true }
Groovig
baselineProfile { saveInSrc true }
Sie können dieses Verhalten auch pro Variante festlegen:
Kotlin
baselineProfile { variants { freeRelease { saveInSrc = true } } }
Groovig
baselineProfile { variants { freeRelease { saveInSrc true } } }
Profilregeln filtern
Mit dem Gradle-Plug-in für Baseline Profile können Sie die generierten Baseline Profile-Regeln filtern. Das ist besonders hilfreich für Bibliotheken, wenn Sie Profilregeln für Klassen und Methoden ausschließen möchten, die Teil anderer Abhängigkeiten der Beispiel-App oder der Bibliothek selbst sind. Die Filter können bestimmte Pakete und Klassen ein- und ausschließen. Wenn Sie nur Ausschlüsse angeben, werden nur übereinstimmende Baseline-Profilregeln ausgeschlossen. Alle anderen Elemente werden einbezogen.
Die Filterspezifikation kann eines der folgenden Formate sein:
- Paketname, der mit doppelten Platzhaltern endet, um dem angegebenen Paket und allen Teilpaketen zu entsprechen. Beispiel:
com.example.**
stimmt mitcom.example.method
undcom.example.method.bar
überein. - Paketname, der mit einem Platzhalter endet, um nur das angegebene Paket abzugleichen. Beispiel:
com.example.*
stimmt mitcom.example.method
überein, aber nicht mitcom.example.method.bar
. - Klassennamen, die einer bestimmten Klasse entsprechen sollen, z. B.
com.example.MyClass
.
Die folgenden Beispiele zeigen, wie bestimmte Pakete ein- und ausgeschlossen werden:
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.**") } }
Groovig
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.**' } }
So passen Sie die Filterregeln für verschiedene Varianten an:
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.**") } } } }
Groovig
// 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.**' } } } }
Sie können Regeln auch mit dem Argument filterPredicate
in BaselineProfileRule.collect()
filtern. Wir empfehlen jedoch die Verwendung des Gradle-Plug-ins zum Filtern, da es eine einfachere Möglichkeit zum Filtern von Unterpaketen und einen zentralen Ort zum Konfigurieren des gesamten Moduls bietet.
Build-Typen für Benchmarks und Baseline-Profil anpassen
Das Gradle-Plug-in „Baseline Profile“ erstellt zusätzliche Build-Typen, um die Profile zu generieren und Benchmarks auszuführen. Diesen Build-Typen ist das Präfix benchmark
und nonMinified
vorangestellt. Für den Build-Typ release
erstellt das Plug-in beispielsweise die Build-Typen benchmarkRelease
und nonMinifiedRelease
.
Diese Build-Typen werden automatisch für den jeweiligen Anwendungsfall konfiguriert und müssen im Allgemeinen nicht angepasst werden. Es gibt jedoch Fälle, in denen es dennoch nützlich sein kann, einige benutzerdefinierte Optionen anzuwenden, z. B. eine andere Signaturkonfiguration.
Sie können die automatisch generierten Build-Typen mithilfe einer Teilmenge von Build-Typ-Attributen anpassen. Nicht verwendbare Attribute werden überschrieben. Das folgende Beispiel zeigt, wie Sie die zusätzlichen Build-Typen anpassen und welche Attribute überschrieben werden sollen:
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 } } }
Groovig
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 } } }
Zusätzliche Anmerkungen
Beachten Sie beim Erstellen von Baseline-Profilen außerdem Folgendes:
Kompilierte Referenzprofile müssen kleiner als 1,5 MB sein. Dies gilt nicht für das Textformat in den Quelldateien, die vor der Kompilierung normalerweise viel größer sind. Prüfen Sie die Größe Ihres binären Baseline-Profils. Suchen Sie es dazu im Ausgabeartefakt unter
assets/dexopt/baseline.prof
für APK oderBUNDLE-METADATA/com.android.tools.build.profiles/baseline.prof
für AAB.Allgemeine Regeln, die zu viel der Anwendung kompilieren, können den Start verlangsamen, da der Zugriff auf das Laufwerk zunimmt. Wenn Sie gerade mit Baseline Profile beginnen, müssen Sie sich keine Sorgen machen. Je nach Anwendung und Größe und Anzahl der Fahrten kann das Hinzufügen vieler Journeys jedoch zu einer suboptimalen Leistung führen. Testen Sie die Leistung Ihrer Anwendung, indem Sie verschiedene Profile ausprobieren und prüfen, ob die Leistung nach dem Hinzufügen nicht zurückgeht.