Ab dem 27. März 2025 empfehlen wir, android-latest-release anstelle von aosp-main zu verwenden, um AOSP zu erstellen und Beiträge dazu zu leisten. Weitere Informationen finden Sie unter Änderungen am AOSP.

Diese Seite wurde von der Cloud Translation API übersetzt.

Boot-Image-Profile

Unter Android 11 oder höher wird das Generieren von Boot-Image-Profilen unterstützt, die Informationen zum Code verschiedener Systemkomponenten wie Systemserver und Boot-Classpath enthalten. Die Android-Laufzeit (Android Runtime, ART) verwendet diese Informationen, um systemweite Optimierungen vorzunehmen. Einige davon sind entscheidend für die Leistung von Android und wirken sich auf die Ausführung von nicht nativem Code (auf System- oder App-Ebene) aus. In einigen Fällen können Boot-Image-Profile die Ausführungsleistung und den Speicherverbrauch um zweistellige Prozentzahlen beeinflussen.

Informationen zum Bootprofil abrufen

Boot-Image-Profile werden aus den Profilen von Apps abgeleitet, die während wichtiger Nutzerabläufe (Critical User Journeys, CUJs) ausgeführt werden. In einer bestimmten Gerätekonfiguration erfasst ART (als Teil der JIT-Profile) die von Apps verwendeten Boot-Classpath-Methoden und -Klassen und speichert diese Informationen dann im App-Profil (z. B. /data/misc/profiles/cur/0/com.android.chrome/primary.prof), wo sie nach der DEX-Datei (Dalvik EXecutable) des Boot-Classpaths indexiert werden (siehe ART-Profilformat).

Sehen Sie sich die während der CUJs aufgezeichneten App-Profile an, um zu ermitteln, welcher Teil des Boot-Klassenpfads am häufigsten verwendet wird und am wichtigsten zu optimieren ist (ein Beispiel finden Sie unter ART-Profilformat). Wenn Sie alle Methoden oder Klassen einbeziehen, wirkt sich das negativ auf die Leistung aus. Konzentrieren Sie sich daher auf die am häufigsten verwendeten Codepfade. Wenn beispielsweise eine Methode aus dem Boot-Klassenpfad von einer einzelnen App verwendet wird, sollte sie nicht Teil der Boot-Profile sein. Jedes Gerät sollte die Auswahl der Methode/Klasse basierend auf der CUJ-Auswahl und der Menge der durch Tests erzeugten Daten konfigurieren.

Wenn Sie Informationen zum Boot-Klassenpfad aus allen einzelnen Anwendungsprofilen auf dem Gerät zusammenfassen möchten, führen Sie den Befehl adb shell cmd package snapshot-profile android aus. Sie können die aggregierten Informationen als Grundlage für die Verarbeitung und die Auswahl von Methoden/Klassen verwenden, ohne einzelne Profile manuell zu aggregieren. Dies ist jedoch möglich, wenn Sie es wünschen.

Boot-Image-Profil

Abbildung 1: Prozess zum Abrufen von Boot-Image-Profilen

Profildaten für Boot-Image

Boot-Image-Profile enthalten die folgenden Dateien und Daten.

Profil für den Boot-Klassenpfad (frameworks/base/config/boot-image-profile.txt): Bestimmt, welche Methoden aus dem Boot-Klassenpfad optimiert werden und welche Klasse im Boot-.art-Image enthalten ist.
Liste der vorab geladenen Klassen. Bestimmt, welche Klassen in Zygote vorab geladen werden.
Profil für die Systemserverkomponenten (frameworks/base/services/art-profile). Legt fest, welche Methoden des Systemservers optimiert/kompiliert werden, welche Klasse im .art-Boot-Image enthalten ist und wie die entsprechenden DEX-Dateien angeordnet werden.

ART-Profilformat

Das ART-Profil enthält Informationen aus jeder der geladenen DEX-Dateien, einschließlich Informationen zu Methoden, die optimiert werden sollten, und zu Klassen, die beim Start verwendet werden. Wenn das Boot-Image-Profiling aktiviert ist, enthält ART auch den Boot-Classpath und die JAR-Dateien des Systemservers im Profil und annotiert jede DEX-Datei mit dem Namen des Pakets, das sie verwendet.

Mit dem folgenden Befehl können Sie beispielsweise das Rohprofil des Boot-Images ausgeben:

adb shell profman --dump-only --profile-file=/data/misc/profman/android.prof

Die Ausgabe sollte in etwa so aussehen:

=== Dex files  ===
=== profile ===
ProfileInfo [012]

core-oj.jar:com.google.android.ext.services [index=0] [checksum=e4e3979a]
        hot methods: 520[], 611[] …
        startup methods: …
        classes: …
...
core-oj.jar:com.android.systemui [index=94] [checksum=e4e3979a]
        hot methods: 520[], 521[]…
        startup methods: …
        classes: …

Im obigen Beispiel:

core-oj.jar wird von com.google.android.ext.services und com.android.systemui verwendet. In jedem Eintrag sind die beiden Pakete aufgeführt, die aus core-oj.jar verwendet werden.
Bei beiden Prozessen wird die Methode mit DEX-Index 520 verwendet, aber nur beim systemui-Prozess wird die Methode mit DEX-Index 521 verwendet. Dasselbe gilt für die anderen Profilbereiche, z. B. die Startup-Klassen.

Filtern Sie während der Datenverarbeitung Methoden/Klassen nach Verwendung und priorisieren Sie Prozesse auf Systemebene (z. B. den Systemserver oder systemui) oder Methoden, die möglicherweise nicht häufig verwendet werden, aber dennoch wichtig sind (z. B. Methoden, die von der Kamera-App verwendet werden).

Im Profilformat wird jede Methode intern mit mehreren Flags (Startup, Post-Startup, Hotness, ABI) versehen. Das sind mehr als im Format „dump-only“. Wenn Sie alle Signale nutzen möchten, müssen Sie die verfügbaren Skripts entsprechend anpassen.

Empfehlungen

Beachten Sie die folgenden Richtlinien, um optimale Ergebnisse zu erzielen.

Stellen Sie die Konfiguration zum Generieren von Boot-Image-Profilen auf mehreren Testgeräten bereit und fassen Sie die Ergebnisse zusammen, bevor Sie das endgültige Boot-Image-Profil generieren. Das profman-Tool unterstützt das Aggregieren und Auswählen mehrerer Boot-Image-Profile, funktioniert aber nur mit derselben Version des Boot-Images (derselbe Boot-Classpath).
Geben Sie den Methoden/Klassen, die von Systemprozessen verwendet werden, eine höhere Priorität. Diese Methoden/Klassen verwenden möglicherweise Code, der von anderen Apps nicht häufig verwendet wird, aber dennoch wichtig für die Optimierung ist.
Die Datenform eines einzelnen Geräte-Runs sieht ganz anders aus als bei Testgeräten, auf denen CUJs aus der Praxis ausgeführt werden. Wenn Sie nicht über eine große Anzahl von Testgeräten verfügen, verwenden Sie dasselbe Gerät, um mehrere CUJs auszuführen. So können Sie die Wahrscheinlichkeit erhöhen, dass die Optimierungen des Boot-Image-Profils in der Produktion gut funktionieren. Dieses Szenario wird unten beschrieben.

Geräte konfigurieren

Wenn Sie die Konfiguration des Bootprofils über Systemattribute aktivieren möchten, verwenden Sie eine der folgenden Methoden.

Option 1:Attribute manuell einrichten (funktioniert bis zum Neustart):

adb root
adb shell stop
adb shell setprop dalvik.vm.profilebootclasspath true
adb shell setprop dalvik.vm.profilesystemserver true
adb shell start

Option 2:Verwenden Sie local.prop (permanenter Effekt bis zum Löschen der Datei). Gehen Sie dazu folgendermaßen vor:
1. Erstellen Sie eine local.prop-Datei mit folgendem Inhalt:
```
dalvik.vm.profilebootclasspath=true
dalvik.vm.profilesystemserver=true
```
2. Führen Sie folgende Befehle aus:
```
adb push local.prop /data/
adb shell chmod 0750 /data/local.prop
adb reboot
```

Option 3:Verwenden Sie die Gerätekonfiguration, um die folgenden serverseitigen Eigenschaften festzulegen:

adb shell device_config put runtime_native_boot profilebootclasspath true
adb shell device_config put runtime_native_boot profilesystemserver true