Auf dieser Seite wird die Konfiguration der Android-Laufzeit (ART) und ihrer Kompilierungsoptionen erläutert. Themen
die hier enthalten sind, die Konfiguration der Vorkompilierung des System-Images dex2oat
Kompilierungsoptionen und den Ausgleich
von Systempartitions- und Datenpartitionsspeichern
die Leistung.
Informationen zur Arbeit mit ART finden Sie unter ART und Dalvik und das ausführbare Format von Dalvik. Weitere Informationen finden Sie unter Überprüfen App-Verhalten in Android Runtime (ART), um sicherzustellen, dass Ihre Apps funktionieren ordnungsgemäß funktioniert.
So funktioniert ART
ART verwendet eine Pre-of-Time-Kompilierung (AOT) und ab Android 7 verwendet eine Hybridkombination aus AOT-Kompilierung, Just-in-Time-Kompilierung (JIT) und Interpretation. und die AOT-Kompilierung kann profilgesteuert werden. Die Kombination all dieser Ausführungsmodi konfigurierbar sind und werden in diesem Abschnitt erläutert. Pixel-Geräte sind beispielsweise so konfiguriert, wie im Folgenden beschrieben:
- Eine Anwendung wird anfangs mit einer DEX-Metadatendatei (
.dm
) installiert, die über Play Store, der ein Cloud-Profil enthält. ART AOT kompiliert die in der Cloud aufgeführten Methoden zu erstellen. Wenn die Anwendung ohne DEX-Metadatendatei installiert wird, ist keine AOT-Kompilierung durchgeführt wurde. - In den ersten paar Ausführungen der Anwendung werden nicht durch AOT kompilierte Methoden interpretiert. Unter den interpretierten Methoden werden die häufig ausgeführten Methoden dann per JIT kompiliert. Kunst generiert basierend auf der Ausführung ein lokales Profil und kombiniert es mit dem Cloud-Profil (falls eines existiert).
- Wenn das Gerät inaktiv ist und aufgeladen wird, wird ein Kompilierungs-Daemon ausgeführt, um die Anwendung neu zu kompilieren. basierend auf dem kombinierten Profil, das während der ersten Ausführungen erstellt wurde.
- In den nachfolgenden Ausführungen der Anwendung verwendet ART die von der Kompilierung generierten Artefakte Daemon, der mehr AOT-kompilierten Code enthält als der, der während Nicht mit AOT kompilierte Methoden werden trotzdem interpretiert oder mit JIT kompiliert. ART aktualisiert das Profil und das Profil wird von nachfolgenden Durchläufen den Kompilierungs-Daemon.
ART besteht aus einem Compiler (dem dex2oat
-Tool) und einer Laufzeit.
(libart.so
), der während des Startvorgangs geladen wird. Die
Das dex2oat
-Tool generiert aus einer APK-Datei
Kompilierungsartefaktdateien, die von der Laufzeit geladen werden. Die Anzahl der Dateien, ihre
Erweiterungen und Namen können sich je nach Version ändern, ab dem
Android 8. Diese Dateien werden generiert:
.vdex
: enthält zusätzliche Metadaten, um die Überprüfung zu beschleunigen, manchmal zusammen mit durch den unkomprimierten DEX-Code des APK..odex
: enthält AOT-kompilierten Code für Methoden in den APK.art (optional)
enthält interne ART-Elemente Darstellungen einiger im APK aufgeführter Strings und Klassen zur Beschleunigung App-Start.
Kompilierungsoptionen
Es gibt zwei Kategorien von Kompilierungsoptionen für ART:
- System-ROM-Konfiguration: Welcher Code wird bei der Erstellung eines System-Image.
- Laufzeitkonfiguration: wie ART Apps kompiliert und auf einem .
Compiler-Filter
Eine ART-Hauptoption zum Konfigurieren dieser beiden Kategorien ist der Compiler
Filter. Compiler-Filter bestimmen, wie ART den DEX-Code kompiliert.
an das dex2oat
-Tool übergeben. Ab Android 8
gibt es vier offiziell unterstützte Filter:
verify
: Führt nur die DEX-Codeüberprüfung aus (keine AOT-Kompilierung).quicken
: (bis Android 11) DEX-Code ausführen überprüfen und einige DEX-Anweisungen optimieren, um eine bessere Dolmetscherleistung zu erzielen.speed
: Führen Sie die DEX-Codeüberprüfung aus und kompilieren Sie alle Methoden mithilfe von AOT.speed-profile
: Methoden zur DEX-Codeüberprüfung und AOT-Kompilierung ausführen die in einer Profildatei aufgeführt sind.
System-ROM-Konfiguration
Vorinstallierte Bibliotheken und Apps werden beim Erstellen eines System-Images automatisch kompiliert. Dieses wird als dexpreopt bezeichnet. Solche kompilierten Dateien sind nutzbar, solange alle Abhängigkeiten unverändert bleiben, insbesondere der Boot-Klassenpfad.
Hinweis:Wenn das Gerät Systemmodul aktualisiert, dann ist der Boot-Klassenpfad wird sich bei der nächsten Aktualisierung wahrscheinlich ändern, wodurch alle dexpreopt-Dateien veraltet und unbrauchbar werden.
Für die Konfiguration von dexpreopt stehen mehrere ART-Build-Optionen zur Verfügung. Konfiguration Diese Optionen hängen vom verfügbaren Speicherplatz für das System-Image und der Anzahl vorinstallierten Apps installiert. Die JARs/APKs, die in ein System-ROM kompiliert werden, können in vier unterteilt werden. Kategorien:
- Bootklassenpfadcode: mit dem Compiler
speed-profile
kompiliert nach Standardeinstellung. - Systemservercode (siehe
PRODUCT_SYSTEM_SERVER_JARS
,PRODUCT_APEX_SYSTEM_SERVER_JARS
,PRODUCT_STANDALONE_SYSTEM_SERVER_JARS
,PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS
weiter unten in diesem Dokument): <ph type="x-smartling-placeholder">- </ph>
- (Android 14 und höher) Kompiliert mit
speed-profile
ist standardmäßig der Compiler-Filter oder wird mit dem Compiler-Filterspeed
kompiliert, wenn ein Profil nicht angegeben. - (Android 13 und niedriger) Kompiliert mit
speed
Compiler-Filter standardmäßig.
PRODUCT_SYSTEM_SERVER_COMPILER_FILTER
(weitere Informationen später in diesem Dokument). - (Android 14 und höher) Kompiliert mit
- Produktspezifische Haupt-Apps (siehe
PRODUCT_DEXPREOPT_SPEED_APPS
weiter unten in dieser document): Standardmäßig mit dem Compiler-Filterspeed
kompiliert. - Alle anderen Apps: standardmäßig mit dem Compiler-Filter
speed-profile
kompiliert oder mit dem Compiler-Filterverify
kompiliert werden, wenn kein Profil angegeben ist.Konfigurierbar über
PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER
(weitere Informationen weiter unten) Dokument).
Makefile-Optionen
WITH_DEXPREOPT
DONT_DEXPREOPT_PREBUILTS
(Android 5 und höher)PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER
(Android 9) und höher)WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY
(seit Android 8 MR1)LOCAL_DEX_PREOPT
PRODUCT_DEX_PREOPT_BOOT_FLAGS
PRODUCT_DEX_PREOPT_DEFAULT_FLAGS
PRODUCT_DEX_PREOPT_MODULE_CONFIGS
PRODUCT_DEXPREOPT_SPEED_APPS
(seit Android 8)PRODUCT_SYSTEM_SERVER_APPS
(seit Android 8)PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD
(seit Android 8.WITH_DEXPREOPT_PIC
(bis Android 7)WITH_DEXPREOPT_BOOT_IMG_ONLY
(bis Android 7) MR1)PRODUCT_SYSTEM_SERVER_COMPILER_FILTER
- (Android 14 und höher) Wenn nicht angegeben, wird die
speed-profile
Compiler-Filter oder derspeed
-Compiler-Filter wird verwendet, wenn ein Profil nicht bereitgestellt. - (Android 13 und niedriger) Wenn nicht angegeben, der Compiler
speed
-Filter verwendet wird. - Wenn
speed
festgelegt ist, wird der Compilerfilterspeed
verwendet. - Wenn
speed-profile
festgelegt ist, wird der Compiler-Filterspeed-profile
verwendet, oder der Compiler-Filterverify
wird verwendet, wenn kein Profil angegeben ist. - Wenn
verify
festgelegt ist, wird der Compilerfilterverify
verwendet. PRODUCT_SYSTEM_SERVER_JARS
,PRODUCT_APEX_SYSTEM_SERVER_JARS
,PRODUCT_STANDALONE_SYSTEM_SERVER_JARS
,PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS
- (Erforderlich)
PRODUCT_SYSTEM_SERVER_JARS
: Liste der Klassenpfad-JARs des Systemservers aktiviert der Plattform (d. h. als Teil vonSYSTEMSERVERCLASSPATH
). Systemserver wird hinzugefügt Klassenpfad-JARs zu dieser Liste sind erforderlich. Klassenpfad-JARs für Systemserver konnten nicht der Liste hinzugefügt werden werden diese JARs nicht geladen. - (Erforderlich)
PRODUCT_APEX_SYSTEM_SERVER_JARS
: Liste der Klassenpfad-JARs für Systemserver mit APEX ausgeliefert (d. h. als Teil vonSYSTEMSERVERCLASSPATH
). Das Format ist<apex name>:<jar name>
Klassenpfad-JARs für APEX-Systemserver werden hinzugefügt zu Diese Liste ist erforderlich. Wenn Sie dieser Liste keine APEX-Systemserver-Klassenpfad-JARs hinzufügen, führt das zu dass diese JARs nicht geladen werden. - (Optional, Android 13 und niedriger)
PRODUCT_STANDALONE_SYSTEM_SERVER_JARS
: Liste der JARs, die vom Systemserver geladen werden dynamisch mit separaten Classloadern (durchSystemServiceManager.startServiceFromJar
). Hinzufügen eigenständiger Systemserver-JARs zu Diese Liste ist nicht erforderlich, wird aber dringend empfohlen, da sie die JARs kompiliert und und eine gute Laufzeit haben. - (erforderlich, seit Android 13)
PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS
: Liste mit Mit APEX gelieferte JARs, die vom Systemserver dynamisch mit separaten Classloadern geladen werden (die ist, durchSystemServiceManager.startServiceFromJar
oder deklariert als<apex-system-service>
. Das Format ist<apex name>:<jar name>
. Hinzufügen eigenständiger APEX-Systemserver-JARs zu Diese Liste ist erforderlich. Wenn keine eigenständigen APEX-Systemserver-JARs zu dieser Liste hinzugefügt werden, wird Folgendes ausgegeben: Startfehler. dalvik.vm.usejit
: Gibt an, ob JIT aktiviert ist.dalvik.vm.jitinitialsize
(Standard: 64 K): Die anfängliche Kapazität im Code-Cache gespeichert. Der Code-Cache führt regelmäßig eine automatische Speicherbereinigung durch und erhöht sich bei Bedarf.dalvik.vm.jitmaxsize
(Standard: 64 M): Die maximale Kapazität des Code-Cache.dalvik.vm.jitthreshold
(Standardwert 10.000): Der Schwellenwert, an dem die „Wärme“ muss der Zähler einer Methode für die JIT-Kompilierung der Methode. Die „Wärme“ Zähler ist ein interner Messwert zur Laufzeit hinzugefügt. Sie enthält die Anzahl der Aufrufe, Rückwärtszweige und andere Faktoren.dalvik.vm.usejitprofiles
(bis Android 13): Gibt an, ob oder JIT-Profile sind nicht aktiviert. Dies kann auch dann verwendet werden, wenndalvik.vm.usejit
„false“ ist. Wenn dies auf "false" gesetzt ist, gilt für den Compiler-Filterspeed-profile
keine Methode mithilfe von AOT kompiliert und entsprichtverify
. Seit JIT-Profile unter Android 14 sind immer aktiviert und können nicht deaktiviert werden.dalvik.vm.jitprithreadweight
(Standardeinstellung:dalvik.vm.jitthreshold
/ 20): Die Gewichtung der JIT-„Proben“. (siehe Jitthreshold) für den Anwendungs-UI-Thread. Zum Beschleunigen der Kompilierung die sich direkt auf die User Experience auswirken,dalvik.vm.jittransitionweight
(Standardeinstellung:dalvik.vm.jitthreshold
/ 10): Die Gewichtung der Methode -Aufruf, der zwischen Kompilierungscode und Interpreter wechselt. Das hilft, Stellen Sie sicher, dass die beteiligten Methoden kompiliert sind, um Übergänge (die teuer sein).dalvik.vm.image-dex2oat-threads
/dalvik.vm.image-dex2oat-cpu-set
(bis Android 11): Die Anzahl der Threads und die Anzahl der CPU-Kerne (siehe unten) für Boot-Images verwendet werden.dalvik.vm.boot-dex2oat-threads
/dalvik.vm.boot-dex2oat-cpu-set
: <ph type="x-smartling-placeholder">- </ph>
- (bis Android 11) Anzahl der Threads und CPU-Kerne (siehe unten) zur Verwendung während des Bootvorgangs für alles außer Boot-Images.
- (seit Android 12) Anzahl der Threads und CPU-Kerne
(siehe unten) zur Verwendung während des Bootvorgangs für alle Elemente, einschließlich Boot-Images.
- Insbesondere entspricht dies seit Android 14 dem
Prioritätsklasse
PRIORITY_BOOT
in ART Service.
- Insbesondere entspricht dies seit Android 14 dem
Prioritätsklasse
dalvik.vm.restore-dex2oat-threads
/dalvik.vm.restore-dex2oat-cpu-set
: <ph type="x-smartling-placeholder">- </ph>
- (seit Android 11 bis Android 13) Anzahl der Threads und CPU-Kerne (siehe unten) für die Wiederherstellung aus der Cloud Back-up.
- (seit Android 14) Anzahl der Threads und CPU-Kerne
(siehe unten) für alles, was latenzempfindlicher als normal ist, einschließlich
Wiederherstellung aus einer Cloud-Sicherung.
- Insbesondere entspricht dies der Prioritätsklasse,
PRIORITY_INTERACTIVE_FAST
in ART Service.
- Insbesondere entspricht dies der Prioritätsklasse,
dalvik.vm.background-dex2oat-threads
/dalvik.vm.background-dex2oat-cpu-set
(seit Android 14): Die Anzahl der Threads und die Anzahl der CPU-Kerne (siehe unten) zur Verwendung im Hintergrund.- Insbesondere entspricht dies der Prioritätsklasse
PRIORITY_BACKGROUND
in ART-Dienst.
- Insbesondere entspricht dies der Prioritätsklasse
dalvik.vm.dex2oat-threads
/dalvik.vm.dex2oat-cpu-set
: Die Anzahl der Threads und die Gruppe von CPU-Kernen, die für alles andere verwendet werden sollen.Dex2OatBackground
(seit Android 14) (übernimmt standardmäßigDex2OatBootComplete
): Steuert die Ressourcen, die im Hintergrund verwendet werden sollen.- Insbesondere entspricht dies der Prioritätsklasse
PRIORITY_BACKGROUND
in ART-Dienst.
- Insbesondere entspricht dies der Prioritätsklasse
Dex2OatBootComplete
: <ph type="x-smartling-placeholder">- </ph>
- (bis Android 13) Steuert die Ressource, die für alle Elemente verwendet werden soll nach dem Booten.
- (seit Android 14) Steuert die Ressource, die für alles verwendet wird
und nicht im Hintergrund.
- Insbesondere entspricht dies der Prioritätsklasse,
PRIORITY_INTERACTIVE_FAST
undPRIORITY_INTERACTIVE
in ART Dienst.
- Insbesondere entspricht dies der Prioritätsklasse,
dalvik.vm.image-dex2oat-Xms
: anfängliche Heap-Größe für Boot-Imagesdalvik.vm.image-dex2oat-Xmx
: Maximale Heap-Größe für Boot-Images.dalvik.vm.dex2oat-Xms
: Anfängliche Heap-Größe für alles andere.dalvik.vm.dex2oat-Xmx
: Maximale Heap-Größe für alles andere.dalvik.vm.image-dex2oat-filter
(bis Android 11): Der Compilerfilter für Boot-Images. Seit Android 12 hat der Compiler Der Filter für Boot-Images ist immerspeed-profile
und kann nicht geändert werden.dalvik.vm.systemservercompilerfilter
(seit Android 13): Der Compilerfilter für den Systemserver. Weitere Informationen finden Sie unter .PRODUCT_SYSTEM_SERVER_COMPILER_FILTER
dalvik.vm.systemuicompilerfilter
(seit Android 13): Der Compilerfilter für das System-UI-Paket.dalvik.vm.dex2oat-filter
(bis Android 6): Der Compilerfilter für alles andere.pm.dexopt.<reason>
(seit Android 7): Der Compilerfilter für alles andere. Weitere Informationen finden Sie unter ART-Dienstkonfiguration für Android 14 und älter oder Paketmanager-Konfiguration für Android 13 und niedriger.dalvik.vm.dex2oat-very-large
(seit Android 7.1): Mindestgesamtgröße DEX-Datei in Bytes deaktiviert, um die AOT-Kompilierung zu deaktivieren.dalvik.vm.dex2oat-swap
(seit Android 7.1) (Standardeinstellung: true): Ermöglicht die Verwendung von Swaps für dex2oat. Dies kann dazu beitragen, Abstürze mit unzureichendem Arbeitsspeicher zu vermeiden. Auch wenn diese Option aktiviert ist, verwendet dex2oat eine Auslagerungsdatei nur unter bestimmten Bedingungen, z. B. wenn die Nummer der DEX-Dateien ist groß und die Bedingungen können sich ändern.dalvik.vm.ps-min-first-save-ms
(seit Android 12): Das Mindestwartezeit, bevor die Laufzeit ein Profil der Anwendung generiert, beim ersten Mal wenn die Anwendung gestartet wird.dalvik.vm.ps-min-save-period-ms
(seit Android 12): Das Mindestwartezeit, bevor das Profil der Anwendung aktualisiert wird.dalvik.vm.dex2oat64.enabled
(seit Android 11) (Standardeinstellung: false): Gibt an, ob die 64-Bit-Version von dex2oat verwendet werden soll.dalvik.vm.bgdexopt.new-classes-percent
(seit Android 12) (Standard: 20): Der Mindestprozentsatz zwischen 0 und 100 neuer Klassen in einem Profil, um eine Neukompilierung auszulösen. Gilt nur für die profilgestützte Kompilierung (speed-profile
), in der Regel während Hintergrunddexopt. Außerdem gilt ein Grenzwert von mindestens 50 neuen Klassen zusätzlich zu den der prozentuale Schwellenwert und ist nicht konfigurierbar.dalvik.vm.bgdexopt.new-methods-percent
(seit Android 12) (Standard: 20): Der Mindestprozentsatz zwischen 0 und 100 neuer Methoden in einem Profil zum Auslösen einer Neukompilierung. Gilt nur für die profilgestützte Kompilierung (speed-profile
), in der Regel während Hintergrunddexopt. Außerdem gilt ein Grenzwert von mindestens 100 neuen Methoden. auf den prozentualen Schwellenwert an. Dieser Parameter kann nicht konfiguriert werden.dalvik.vm.dex2oat-max-image-block-size
(seit Android 10) (Standard: 524288) Maximale feste Blockgröße für komprimierte Bilder. Ein großes Bild wird in einen Satz dass kein Block größer als die maximale Größe ist.dalvik.vm.dex2oat-resolve-startup-strings
(seit Android 10) (Standardeinstellung: true) Falls wahr, löst dex2oat alle const-Strings auf, auf die von Methoden verwiesen wird, die als „Starten“ im Profil.debug.generate-debug-info
(Standardeinstellung: false) Gibt an, ob Informationen zur Fehlerbehebung für das native Debugging generiert werden sollen, z. B. für die Stack-Entspannung Informationen, ELF-Symbole und Zwergabschnitte.dalvik.vm.dex2oat-minidebuginfo
(seit Android 9) (Standardeinstellung: true) Legt fest, ob eine minimale Menge an LZMA-komprimierten Debug-Informationen generiert werden soll, die für Backtraces drucken.
Gibt an, ob dex2oat
in dem auf dem System-Image installierten DEX-Code aufgerufen wird. Standardmäßig aktiviert.
Wenn Sie DONT_DEXPREOPT_PREBUILTS
aktivieren, werden die vordefinierten
dexpreopted. Das sind Apps mit include $(BUILD_PREBUILT)
die in der Android.mk
angegeben sind. Überspringen
Bereitstellung vorkonfigurierter Apps, die wahrscheinlich über Google Play aktualisiert werden
spart Speicherplatz im System-Image, erhöht aber den Zeitaufwand für den ersten Start. Diese Option hat keine Auswirkungen
vordefinierten Apps, die in Android.bp
definiert sind.
PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER
gibt den Standard-Compilerfilter an
für dexpreoptierte Anwendungen. Diese Apps sind in Android.bp
definiert oder wurden
include $(BUILD_PREBUILT)
wurde in der Android.mk
angegeben. Wenn keine Angabe erfolgt, gilt Folgendes:
Der Standardwert ist speed-profile
oder verify
, wenn kein Wert angegeben ist
und es wird kein Profil bereitgestellt.
Wenn Sie WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY
aktivieren, wird nur die
Boot-Klassenpfad und Systemserver-JAR-Dateien.
Dexpreopt kann auch für einzelne Anwendungen aktiviert oder deaktiviert werden.
Angabe der Option LOCAL_DEX_PREOPT
in der Moduldefinition
Dies kann nützlich sein, um das Entfernen von Apps zu deaktivieren, die sofort
Google Play-Updates erhalten, da durch diese Updates
Code im System-Image veraltet ist. Dies ist auch nützlich, um Platz bei wichtigen
OTAs mit Versionsupgrade, da Nutzer möglicherweise bereits neuere Versionen von Apps im
Datenpartitionierung.
LOCAL_DEX_PREOPT
unterstützt die Werte true
oder false
,
dexpreopt aktivieren bzw. deaktivieren. Außerdem kann nostripping
wird angegeben, wenn bei der dexpreopt-Funktion classes.dex
nicht entfernt werden soll.
aus der APK- oder JAR-Datei. Normalerweise wird diese Datei entfernt,
nach dem Expreopting nicht mehr gebraucht. Diese letzte Option ist jedoch erforderlich,
Gültigkeit von Drittanbieter-APK-Signaturen zulassen.
Gibt Optionen an dex2oat
weiter, um zu steuern, wie das Boot-Image ist
kompiliert werden. Damit können benutzerdefinierte Bildklassenlisten, kompilierte
Klassenlisten und Compilerfilter.
Übergibt Optionen an dex2oat
, um zu steuern, wie alles außer dem
Boot-Image kompiliert ist.
Bietet die Möglichkeit, dex2oat
-Optionen für eine bestimmte
und die Produktkonfiguration. Sie wird in der
device.mk
-Datei von $(call add-product-dex-preopt-module-config,<modules>,<option>)
Dabei ist <modules>
eine Liste von LOCAL_MODULE
und
LOCAL_PACKAGE
-Namen für JAR- bzw. APK-Dateien.
Liste der Apps, die als zentraler Bestandteil der Produkte identifiziert wurden
die mit dem Compiler-Filter speed
kompiliert werden können. Für
können persistente Anwendungen wie SystemUI
profilgestützte Kompilierung nur beim nächsten Neustart. Daher ist es besser für den
damit diese Apps immer automatisch kompiliert werden.
Liste der Apps, die vom Systemserver geladen werden. Diese Apps
werden standardmäßig mit dem Compiler-Filter speed
kompiliert.
Gibt an, ob auf dem Gerät eine Debug-Version von ART enthalten sein soll. Standardmäßig ist dies
aktiviert ist. Das Verhalten kann explizit überschrieben werden,
Festlegen der Option auf true
oder false
.
Standardmäßig verwendet das Gerät die Nicht-Debug-Version (libart.so
).
Legen Sie zum Wechseln die Systemeigenschaft persist.sys.dalvik.vm.lib.2
auf
libartd.so
Unter Android 5.1.0 bis Android 6.0.1 kann WITH_DEXPREOPT_PIC
angegeben werden, um den positionsunabhängigen Code (Position-Independent Code, PIC) zu aktivieren. In diesem Zusammenhang
muss der Code des Bildes nicht vom
/system
in /data/dalvik-cache
, wodurch Speicherplatz in der Datenpartition gespart wird.
Es gibt jedoch leichte Auswirkungen auf die Laufzeit, da dadurch eine Optimierung deaktiviert wird, die
von positionsabhängigem Code. Normalerweise werden Geräte, die in /data
Speicherplatz sparen möchten,
die PIC-Kompilierung aktivieren sollten.
In Android 7.0 war die PIC-Kompilierung standardmäßig aktiviert.
Diese Option wurde durch „WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY
“ ersetzt
mit der auch die JARs des Systemservers vorab ausgewählt werden.
Mit dieser Option wird der Compilerfilter für den Systemserver angegeben.
Im Folgenden finden Sie Listen der JARs, die vom Systemserver geladen werden. Die JARs werden mit dem
Compilerfilter angegeben durch PRODUCT_SYSTEM_SERVER_COMPILER_FILTER
Konfiguration des Boot-Klassenpfads
Die Liste der vorinstallierten Klassen enthält die Klassen, in denen Zygote initialisiert wird.
Start-up. Dadurch müssen die einzelnen Apps diese Klasseninitialisierer nicht mehr ausführen.
Dadurch können sie schneller gestartet und Seiten im Arbeitsspeicher gemeinsam genutzt werden. Die
Die Datei mit der vorinstallierten Kursliste befindet sich unter frameworks/base/config/preloaded-classes
und enthält eine Liste mit Informationen zu den typischen Smartphone-Nutzungen. Dies könnte
unterscheiden sich bei anderen Geräten wie Wearables und müssen
entsprechend anpassen. Seien Sie bei der Feinabstimmung vorsichtig: Zu viele Klassenverschwendung
wenn nicht verwendete Klassen geladen werden. Wenn Sie zu wenige Klassen hinzufügen,
eine eigene Kopie erstellen,
was auch viel Arbeitsspeicher verschwendet.
Verwendungsbeispiel (in der device.mk
des Produkts):
PRODUCT_COPY_FILES += <filename>:system/etc/preloaded-classes
Hinweis:Diese Zeile muss vor
Alle Makefiles der Produktkonfiguration werden übernommen, die das Standard-Makefiles abrufen.
build/target/product/base.mk
Laufzeitkonfiguration
JIT-Optionen
Die folgenden Optionen wirken sich nur auf Android-Releases aus, bei denen der ART JIT-Compiler verfügbar ist.
Dex2oat-Optionen
Diese Optionen wirken sich auf die Kompilierung auf dem Gerät aus (auch Dexopt genannt). Einige davon betreffen auch dexpreopt. Die Optionen, die oben im Abschnitt System-ROM-Konfiguration erläutert wurden, auf dexpreopt.
Optionen zur Steuerung der Ressourcennutzung:
Ein Satz von CPU-Kernen sollte als durch Kommas getrennte Liste von CPU-IDs angegeben werden. Zum Ausführen einer auf dex2oat auf CPU-Kernen 0–3 eingestellt:
dalvik.vm.dex2oat-cpu-set=0,1,2,3
Beim Festlegen der CPU-Affinitätseigenschaften empfiehlt es sich, das entsprechende Attribut für die Anzahl der Dex2oat-Threads, die der Anzahl der ausgewählten CPUs entsprechen, um unnötigen Arbeitsspeicher und E/A-Vorgänge zu vermeiden Konflikt:
dalvik.vm.dex2oat-cpu-set=0,1,2,3 dalvik.vm.dex2oat-threads=4
Zusätzlich zu den oben genannten Systemeigenschaften können Sie mit Aufgabenprofilen auch den Ressourcennutzung von dex2oat (siehe Cgroup-Abstraktionsebene)
Unterstützte Aufgabenprofile sind:
Wenn sowohl Systemeigenschaften als auch Aufgabenprofile angegeben sind, werden beide wirksam.
Optionen zum Steuern der Heap-Größe:
Die Optionen, die die anfängliche und maximale Heap-Größe für
dex2oat
sollten nicht reduziert werden, weil dadurch
Anwendungen kompiliert werden können.
Optionen zum Steuern des Compiler-Filters:
Weitere Optionen zur Steuerung der Kompilierung aller Daten außer Boot-Images:
ART Service-Optionen
Seit Android 14 ist die On-Device-OTA-Kompilierung für Apps (auch Dexopt genannt) von ART Service verarbeitet werden. Informationen zum Konfigurieren des ART-Dienstes finden Sie unter Konfiguration des ART-Dienstes.Paketmanager-Optionen
Vor Android 14 ist die On-Device-AOT-Kompilierung für Apps (auch Dexopt genannt) auf dem Gerät Paketmanager verarbeitet werden. Informationen zum Konfigurieren des Paketmanagers für Dexopt Siehe Paketmanager-Konfiguration.A/B-spezifische Konfiguration
ROM-Konfiguration
Ab Android 7.0 können Geräte zwei Systempartitionen verwenden, um A/B-Systemupdates Um die Größe der Systempartition zu sparen, können Sie die vorab optimierten Dateien in folgendem Verzeichnis installieren: die nicht verwendete zweite Systempartition. Anschließend werden sie in die Datenpartition kopiert. beim ersten Start.
Verwendungsbeispiel (in device-common.mk
):
PRODUCT_PACKAGES += \ cppreopts.sh PRODUCT_PROPERTY_OVERRIDES += \ ro.cp_system_other_odex=1
Und im BoardConfig.mk
des Geräts:
BOARD_USES_SYSTEM_OTHER_ODEX := true
Beachten Sie, dass der Bootklassenpfadcode, der Systemservercode und der produktspezifische Core
Anwendungen werden immer in der Systempartition kompiliert. Standardmäßig werden alle anderen
Anwendungen werden in die nicht verwendete zweite Systempartition kompiliert. Dabei kann es sich um
gesteuert mit dem SYSTEM_OTHER_ODEX_FILTER
, der einen Wert hat, der
Standardwert:
SYSTEM_OTHER_ODEX_FILTER ?= app/% priv-app/%
Hintergrund-OTA-Entfernung
Auf A/B-fähigen Geräten können Anwendungen vor dem Neustart im Hintergrund kompiliert werden. Dazu verwenden Sie die Funktion neuen System-Image. Siehe App-Kompilierung in background, um optional das Kompilierungsskript und die Binärdateien in das System-Image aufzunehmen. Die Der für diese Kompilierung verwendete Kompilierungsfilter wird mit folgendem Befehl gesteuert:
pm.dexopt.ab-ota=speed-profile
Wir empfehlen die Verwendung von speed-profile
, um die Vorteile des geführten Profils zu nutzen.
kompilieren und Speicherplatz sparen.
JDWP-Optionen
Die Erstellung von JDWP-Threads (Java Debug Wire Protocol) in UserDebug-Builds wird über die
Systemeigenschaft persist.debug.dalvik.vm.jdwp.enabled
. Standardmäßig wird diese Property
JDWP-Threads werden nur für debug-fähige Apps erstellt. Um JDWP-Threads für beide zu aktivieren
Debug-fähige und nicht Debug-fähige Apps, persist.debug.dalvik.vm.jdwp.enabled
festlegen
an 1
. Das Gerät muss neu gestartet werden, damit die Änderungen an der Eigenschaft wirksam werden.
Wenn Sie Fehler in einer nicht Debug-fähigen App in einem NutzerDebug-Build beheben möchten, aktivieren Sie JDWP, indem Sie folgenden Befehl ausführen: Befehl:
adb shell setprop persist.debug.dalvik.vm.jdwp.enabled 1
adb reboot