Das Gradle-Plug-in für das Baseline-Profil vereinfacht das Generieren und Verwalten Baseline-Profile: Sie hilft Ihnen, Führen Sie die folgenden Aufgaben aus:
- Erstellen Sie neue Baseline-Profile für Ihre Anwendung.
- Erstellen Sie neue Baseline-Profile für Ihre Bibliothek.
- Passen Sie die Generierung von Baseline-Profilen an.
Auf dieser Seite wird erläutert, wie Sie das Gradle-Plug-in „Baseline Profile“ verwenden, um Anpassungen vorzunehmen. die Generierung Ihrer Baseline-Profile.
Anforderungen an Plug-ins
- 8.0 AGP oder höher
- Abhängigkeit vom neueste Version des Gradle-Plug-ins
Baseline-Profile mit einem Gradle-verwalteten Gerät generieren
Wenn Sie ein von Gradle verwaltetes Gerät (Gradle Managed Device, GMD) zum Generieren Ihres Baseline-Profils verwenden möchten, fügen Sie es in der build.gradle.kts
-Konfiguration des Profilerstellungsmoduls hinzu – wahrscheinlich das :baselineprofile
-Testmodul –, 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" } } }
Cool
android { testOptions.managedDevices.devices { pixel6Api31(ManagedVirtualDevice) { device 'Pixel 6' apiLevel = 31 systemImageSource 'aosp' } } }
GMD zum Generieren von Baseline-Profilen verwenden, indem es dem Baseline-Profil hinzugefügt wird
Konfiguration des Gradle-Plug-ins: build.gradle.kts
des
:baselineprofile
-Testmodul:
Kotlin
baselineProfile { managedDevices += "pixel6Api31" }
Groovy
baselineProfile { managedDevices = ['pixel6Api31'] }
Wenn Sie GMD zum Generieren von Basisprofilen verwenden, legen Sie useConnectedDevices
auf
false
, in deinem :baselineprofile
-Testmodul:
Kotlin
baselineProfile { ... useConnectedDevices = false }
Groovy
baselineProfile { ... useConnectedDevices false }
Basisprofile für verschiedene Varianten generieren
Sie können Baseline-Profile pro Variante, pro Flavor oder als einzelne Datei generieren
die für alle Varianten verwendet werden. Sie können dieses Verhalten über die Zusammenführungseinstellung steuern.
wie im folgenden Beispiel dargestellt, im build.gradle.kts
der
Anwendungs- oder Bibliotheksmodul.
Kotlin
baselineProfile { mergeIntoMain = true }
Cool
baselineProfile { mergeIntoMain true }
Wenn Sie die generierten Profile für alle Varianten in einem einzigen Profil zusammenführen möchten, legen Sie mergeIntoMain
auf true
fest. Wenn diese Einstellung true
ist, ist es nicht möglich, Baseline-Profile pro Variante zu generieren. Es gibt also nur eine einzige Gradle-Aufgabe namens generateBaselineProfile
. Das Profil wird ausgegeben am
src/main/generated/baselineProfiles
Wenn Sie die Zusammenführung deaktivieren und ein Profil pro Variante haben möchten, legen Sie für mergeIntoMain
den Wert false
fest. In diesem Fall gibt es mehrere variantenspezifische Gradle-Aufgaben. Für
wenn es zwei Varianten gibt – z. B. kostenlos und kostenpflichtig – und eine
Release-Build-Typ haben, sind die Aufgaben folgende:
* `generateFreeReleaseBaselineProfile`
* `generatePaidReleaseBaselineProfile`
* `generateReleaseBaselineProfile`
Verwenden Sie den folgenden Code, um das Zusammenführungsverhalten pro Variante anzugeben:
Kotlin
baselineProfile { variants { freeRelease { mergeIntoMain = true } } }
Cool
baselineProfile { variants { freeRelease { mergeIntoMain true } } }
Im vorherigen Beispiel sind alle Varianten, für die das Flag auf true
gesetzt ist,
wurden mit src/main/generated/baselineProfiles
zusammengeführt, während die Profile für die
Varianten, bei denen das Flag auf false
gesetzt ist, werden im Ordner aufbewahrt.
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 Basisprofile generieren
Sie können Baseline-Profile so konfigurieren, dass sie mit jedem Release automatisch generiert werden
erstellen, anstatt die Aufgabe generateBaselineProfile
manuell zu verwenden. Mit
automatisch generiert wird, ist das neueste Profil im Release-Build enthalten.
Um die automatische Generierung für Release-Builds zu aktivieren, verwende die
automaticGenerationDuringBuild
-Flag:
Kotlin
baselineProfile { automaticGenerationDuringBuild = true }
Cool
baselineProfile { automaticGenerationDuringBuild true }
Wenn Sie das Flag automaticGenerationDuringBuild
auf true
festlegen, wird die
Erstellung eines neuen Baseline-Profils für jede Release-Assembly. Das bedeutet, dass durch Ausführen einer Build-Aufgabe für die Zusammenstellung einer Release-Version, z. B. ./gradlew:app:assembleRelease
, auch :app:generateReleaseBaselineProfile
ausgelöst wird, die Instrumentierungstests für das Baseline-Profil gestartet und der Build für das Baseline-Profil erstellt wird, auf dem sie ausgeführt werden.
Mit der automatischen Generierung erzielen Nutzer zwar die bestmögliche Leistung,
erhöht auch die Build-Zeit aufgrund des doppelten Builds und der Instrumentierung.
Tests durchführen.
Sie können dieses Verhalten auch für die einzelnen Varianten festlegen, wie im Folgenden gezeigt: Beispiel:
Kotlin
baselineProfile { variants { freeRelease { automaticGenerationDuringBuild = true } } }
Groovy
baselineProfile { variants { freeRelease { automaticGenerationDuringBuild true } } }
Im vorherigen Beispiel wird die Aufgabe generateFreeReleaseBaselineProfile
ausgeführt
beim Start von assembleFreeRelease
. Das ist hilfreich, wenn der Nutzer beispielsweise einen release
-Build für den Distributionsbuild haben möchte, der das Profil beim Erstellen immer generiert, und einen releaseWithoutProfile
-Build für interne Tests.
Referenzprofile in Quellen speichern
Sie können Baseline-Profile im Quellverzeichnis über die saveInSrc
speichern
Flag im build.gradle.kts
des Anwendungs- oder Bibliotheksmoduls:
true
: Das Baseline-Profil wird gespeichert insrc/<variant>/generated/baselineProfiles
. So können Sie die neuesten mit Ihren Quellen erstellt wird.false
: Das Baseline-Profil wird in den Zwischendateien im Build gespeichert. -Verzeichnis. So speichern Sie bei der Übermittlung Ihres Codes nicht die neuesten automatisch generiertes Profil an.
Kotlin
baselineProfile { saveInSrc = true }
Cool
baselineProfile { saveInSrc true }
Sie können dieses Verhalten auch für die einzelnen Varianten festlegen:
Kotlin
baselineProfile { variants { freeRelease { saveInSrc = true } } }
Cool
baselineProfile { variants { freeRelease { saveInSrc true } } }
Profilregeln filtern
Mit dem Gradle-Plug-in für das Baseline-Profil können Sie die Baseline-Profilregeln filtern generiert. Dies ist besonders hilfreich für Bibliotheken, wenn Sie für Klassen und Methoden, die Teil anderer Abhängigkeiten des Beispiel-App oder die Bibliothek selbst. Mit den Filtern können bestimmte Pakete und Klassen. Wenn Sie nur Ausschlüsse angeben, entspricht nur der Baseline-Wert Profilregeln werden ausgeschlossen und alles andere wird eingeschlossen.
Die Filterspezifikation kann Folgendes sein:
- Paketname, der mit doppelten Platzhaltern endet, um das angegebene Paket abzugleichen, und
allen Teilpaketen anzuzeigen. Zum Beispiel stimmt
com.example.**
mitcom.example.method
undcom.example.method.bar
- Paketname, der auf einen Platzhalter endet, um nur mit dem angegebenen Paket übereinzustimmen. Beispiel:
com.example.*
stimmt mitcom.example.method
überein, aber nicht mitcom.example.method.bar
. - Klassennamen, die mit einer bestimmten Klasse übereinstimmen, 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.**") } }
Cool
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.**' } }
Passen Sie die Filterregeln für verschiedene Varianten so 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.**") } } } }
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.**' } } } }
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 einfacher zum Filtern von Teilpaketen und einem
um das gesamte Modul zu konfigurieren.
Benchmark- und Baseline-Profil-Build-Typen anpassen
Das Gradle-Plug-in für das Baseline-Profil erstellt zusätzliche zu generierende Build-Typen
und Benchmarks durchführen. Diese Buildtypen haben das Präfix benchmark
und nonMinified
. Für den Build-Typ release
Das Plug-in erstellt die Build-Typen benchmarkRelease
und nonMinifiedRelease
.
Diese Build-Typen werden automatisch für den jeweiligen Anwendungsfall und
brauchen in der Regel keine Anpassungen. Es gibt jedoch Fälle, in denen
kann trotzdem nützlich sein, wenn Sie benutzerdefinierte Optionen anwenden möchten, z. B. eine
eine andere Signaturkonfiguration.
Sie können die automatisch generierten Build-Typen mit einer Teilmenge von Build-Typ-Eigenschaften Eigenschaften, die nicht verwendbar sind, werden überschrieben. Das folgende Beispiel zeigt, wie Sie die zusätzlichen Build-Typen und welche Attribute überschrieben werden:
Kotlin
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 } } }
Cool
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 Referenzprofilen Folgendes:
Kompilierte Referenzprofile müssen kleiner als 1,5 MB sein. Das ist nicht auf das Textformat in Ihren Quelldateien anwenden, die in der Regel vor der Kompilierung größer. Größe der binären Referenz überprüfen Erstellen Sie ein Profil, indem Sie es 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 von der Anwendung kompilieren, können den Start verlangsamen weil mehr Speicherplatz auf dem Laufwerk verfügbar ist. Wenn Sie gerade erst mit Baseline-Profilen beginnen, ist das kein Problem. Abhängig von Ihrer App und Umfang und Anzahl der Kaufprozesse haben, kann das Hinzufügen vieler Wege zu einer eine suboptimale Leistung. Testen Sie die Leistung Ihrer App, indem Sie verschiedene Profile ausprobieren und prüfen, ob sich die Leistung nach den Ergänzungen nicht verschlechtert.