Ab 2026 werden wir den Quellcode im 2. und 4. Quartal in AOSP veröffentlichen, um unser trunk-stable-Entwicklungsmodell zu unterstützen und die Plattformstabilität für das Ökosystem zu gewährleisten. Für die Entwicklung und das Beitragen zu AOSP empfehlen wir die Verwendung von android-latest-release anstelle von aosp-main. Der Manifestzweig android-latest-release verweist immer auf das neueste Release, das an AOSP übertragen wurde. Weitere Informationen finden Sie unter Änderungen an AOSP.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Boot-Image-Profile

Android 11 oder höher unterstützt die Generierung von Boot-Image-Profilen, die Informationen zum Code verschiedener Systemkomponenten wie dem Systemserver und dem Boot-Klassenpfad enthalten. Die Android Runtime (ART) verwendet diese Informationen, um systemweite Optimierungen vorzunehmen, von denen einige für die Leistung von Android entscheidend sind und sich auf die Ausführung aller nicht nativen Codes (System- oder App-Ebene) auswirken. In einigen Fällen können Boot-Image-Profile die Ausführungsleistung und den Speicherverbrauch um zweistellige Prozentsätze beeinflussen.

Informationen zum Boot-Profil abrufen

Boot-Image-Profile werden aus den Profilen von Apps abgeleitet, die während wichtiger Nutzerverhaltens (Critical User Journeys, CUJs) ausgeführt werden. In einer bestimmten Gerätekonfiguration erfasst ART (als Teil der JIT-Profile) die Boot-Klassenpfadmethoden und -klassen, die von Apps verwendet werden, und speichert diese Informationen im App-Profil (z. B. /data/misc/profiles/cur/0/com.android.chrome/primary.prof), wo sie durch die Dalvik EXecutable-Datei (DEX) des Boot-Klassenpfads indexiert werden (siehe ART-Profil format).

Prüfen Sie die während der CUJs aufgezeichneten App-Profile, um zu ermitteln, welcher Teil des Boot Klassenpfads am häufigsten verwendet wird und am wichtigsten für die Optimierung 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. Bei jedem Gerät sollte die Auswahl der Methode/Klasse auf der CUJ-Auswahl und der Menge der durch Tests erzeugten Daten basieren.

Führen Sie den Befehl adb shell cmd package snapshot-profile android aus, um Informationen zum Boot-Klassenpfad aus allen einzelnen App-Profilen auf dem Gerät zusammenzufassen. Sie können die zusammengefassten Informationen als Grundlage für die Verarbeitung und Auswahl von Methoden/Klassen verwenden, ohne einzelne Profile manuell zusammenzufassen (was aber möglich ist).

Boot-Image-Profil

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

Daten des Boot-Image-Profils

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). Bestimmt, welche Methoden vom Systemserver optimiert/kompiliert werden, welche Klasse im Boot-.artImage enthalten ist und wie die entsprechenden DEX Dateien angeordnet sind.

ART-Profilformat

Das ART-Profil erfasst Informationen aus jeder der geladenen DEX-Dateien, einschließlich Informationen zu Methoden, die optimiert werden sollten, und Klassen, die während des Starts verwendet werden. Wenn die Boot-Image-Profilerstellung aktiviert ist, enthält ART auch die JAR-Dateien des Boot-Klassenpfads und des Systemservers im Profil und versieht jede DEX-Datei mit dem Namen des Pakets, das sie verwendet.

So geben Sie beispielsweise das Rohprofil des Boot-Images mit dem folgenden Befehl aus:

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

Die Ausgabe sieht in etwa so aus:

=== 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. Jeder Eintrag listet die beiden Pakete auf, die aus core-oj.jar verwendet werden.
Beide Prozesse verwenden die Methode mit dem DEX-Index 520, aber nur der systemui-Prozess verwendet die Methode mit dem DEX-Index 521. Dasselbe gilt für die anderen Profilabschnitte (z. B. die Startklassen).

Filtern Sie bei 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 versehen (Start, Nach dem Start, Häufigkeit, ABI), was mehr ist, als im reinen Dump-Format angezeigt wird. Wenn Sie alle Signale nutzen möchten, ändern Sie die verfügbaren Skripts.

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 Tool profman unterstützt das Zusammenfassen und Auswählen mehrerer Boot-Image-Profile, funktioniert aber nur mit derselben Version des Boot-Images (derselbe Boot-Klassenpfad).
Priorisieren Sie bei der Auswahl die Methoden/Klassen, die von Systemprozessen verwendet werden. Diese Methoden/Klassen verwenden möglicherweise Code, der von anderen Apps nicht oft verwendet wird, aber dennoch optimiert werden muss.
Die Datenform aus einer einzelnen Geräteausführung unterscheidet sich stark von Testgeräten, auf denen CUJs in 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, um die Zuverlässigkeit der Optimierungen des Boot-Image-Profils in der Produktion zu erhöhen (dieses Szenario wird unten beschrieben).

Geräte konfigurieren

Verwenden Sie eine der folgenden Methoden, um die Konfiguration des Boot-Profils über Systemeigenschaften zu aktivieren.

Option 1:Eigenschaften 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:local.prop verwenden (dauerhafte Wirkung, bis die Datei gelöscht wird). Gehen Sie dazu so vor:
1. Erstellen Sie eine local.prop-Datei mit dem folgenden 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