ART konfigurieren

Auf dieser Seite wird erläutert, wie ART und seine Kompilierungsoptionen konfiguriert werden. Zu den hier behandelten Themen gehören die Konfiguration der Vorkompilierung des Systemabbilds, dex2oat Kompilierungsoptionen und der Kompromiss zwischen Systempartitionsspeicherplatz, Datenpartitionsspeicherplatz und Leistung.

Informationen zum Arbeiten mit ART finden Sie unter ART und Dalvik sowie im ausführbaren Dalvik-Format . Weitere Informationen finden Sie unter Überprüfen des App-Verhaltens in der Android Runtime (ART), um sicherzustellen, dass Ihre Apps ordnungsgemäß funktionieren.

Wie ART funktioniert

ART verwendet eine AOT-Kompilierung (Ahead-of-Time) und ab Android 7 eine Hybridkombination aus AOT-Kompilierung, JIT-Kompilierung (Just-in-Time) und Interpretation. Die AOT-Kompilierung kann profilgesteuert sein. Die Kombination aller dieser Ausführungsmodi ist konfigurierbar und wird in diesem Abschnitt erläutert. Beispielsweise sind Pixel-Geräte so konfiguriert, dass sie im folgenden Ablauf funktionieren:

  1. Eine Anwendung wird zunächst mit einer vom Play Store verteilten Dex-Metadatendatei ( .dm ) installiert, die ein Cloud-Profil enthält. ART AOT kompiliert die im Cloud-Profil aufgeführten Methoden. Wenn die Anwendung ohne eine Dex-Metadatendatei installiert wird, wird keine AOT-Kompilierung durchgeführt.
  2. Bei den ersten Ausführungen der Anwendung werden Methoden interpretiert, die nicht AOT-kompiliert sind. Von den interpretierten Methoden werden diejenigen, die häufig ausgeführt werden, anschließend JIT-kompiliert. ART generiert auf Grundlage der Ausführung ein lokales Profil und kombiniert es mit dem Cloud-Profil (falls vorhanden).
  3. Wenn das Gerät im Leerlauf ist und aufgeladen wird, wird ein Kompilierungsdämon ausgeführt, um die Anwendung basierend auf dem kombinierten Profil, das während der ersten paar Läufe generiert wurde, neu zu kompilieren.
  4. Bei den nachfolgenden Ausführungen der Anwendung verwendet ART die vom Kompilierungsdämon generierten Artefakte, die mehr AOT-kompilierten Code enthalten als diejenigen, die während des Prozesses generiert wurden. Methoden, die nicht AOT-kompiliert sind, werden weiterhin interpretiert oder JIT-kompiliert. ART aktualisiert die Profilinstallation basierend auf der Ausführung, und das Profil wird dann von nachfolgenden Läufen des Kompilierungsdämons übernommen.

ART besteht aus einem Compiler (dem Tool dex2oat ) und einer Laufzeitumgebung ( libart.so ), die beim Booten geladen wird. Das Tool dex2oat nimmt eine APK-Datei und generiert eine oder mehrere Kompilierungsartefaktdateien, die von der Laufzeit geladen werden. Die Anzahl der Dateien, ihre Erweiterungen und Namen können sich von Version zu Version ändern, aber ab der Version von Android 8 werden diese Dateien generiert:

  • .vdex : enthält einige zusätzliche Metadaten, um die Überprüfung zu beschleunigen, manchmal zusammen mit dem unkomprimierten DEX-Code des APK.
  • .odex : enthält AOT-kompilierten Code für Methoden im APK.
  • .art (optional) enthält ART-interne Darstellungen einiger im APK aufgeführter Zeichenfolgen und Klassen, die zur Beschleunigung des App-Starts verwendet werden.

Zusammenstellungsoptionen

Es gibt zwei Kategorien von Kompilierungsoptionen für ART:

  1. System-ROM-Konfiguration: Welcher Code wird beim Erstellen eines Systemabbilds von AOT kompiliert?
  2. Laufzeitkonfiguration: Wie ART Apps auf einem Gerät kompiliert und ausführt.

Compiler-Filter

Eine zentrale ART-Option zum Konfigurieren dieser beiden Kategorien sind Compiler-Filter . Compilerfilter steuern, wie ART DEX-Code kompiliert, und sind eine Option, die an das Tool dex2oat übergeben wird. Ab Android 8 gibt es vier offiziell unterstützte Filter:

  • verify : Nur DEX-Codeüberprüfung durchführen (keine AOT-Kompilierung).
  • quicken : (bis Android 11) DEX-Codeüberprüfung durchführen und einige DEX-Anweisungen optimieren, um eine bessere Interpreterleistung zu erzielen.
  • speed : Führen Sie die DEX-Codeüberprüfung durch und kompilieren Sie alle Methoden mit AOT.
  • speed-profile : Führen Sie die in einer Profildatei aufgeführten DEX-Codeüberprüfungs- und AOT-Kompilierungsmethoden aus.

System-ROM-Konfiguration

Vorinstallierte Bibliotheken und Apps werden AOT-kompiliert, wenn ein Systemabbild erstellt wird. Dieser Vorgang wird als expreopt bezeichnet. Solche kompilierten Dateien sind verwendbar, solange alle Abhängigkeiten unverändert bleiben, insbesondere der Boot-Klassenpfad.

Hinweis: Wenn das Gerät Systemmodulaktualisierungen durchführt, ist es sehr wahrscheinlich, dass sich der Boot-Klassenpfad beim nächsten Update ändert, wodurch alle Dexpreopt-Dateien veraltet und unbrauchbar werden.

Für die Konfiguration von Dexpreopt stehen eine Reihe von ART-Build-Optionen zur Verfügung. Wie Sie diese Optionen konfigurieren, hängt vom verfügbaren Speicherplatz für das Systemabbild und der Anzahl der vorinstallierten Anwendungen ab. Die JARs/APKs, die in ein System-ROM kompiliert werden, können in vier Kategorien unterteilt werden:

  • Boot-Klassenpfadcode: standardmäßig mit dem speed-profile Compilerfilter kompiliert.
  • 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):
    • (Android 14 und höher) Standardmäßig mit dem speed-profile Compiler-Filter kompiliert oder mit dem speed Compiler-Filter kompiliert, wenn kein Profil bereitgestellt wird.
    • (Android 13 und niedriger) Standardmäßig mit dem speed Compiler-Filter kompiliert.
    Konfigurierbar über PRODUCT_SYSTEM_SERVER_COMPILER_FILTER (siehe weiter unten in diesem Dokument).
  • Produktspezifische Kern-Apps (siehe PRODUCT_DEXPREOPT_SPEED_APPS weiter unten in diesem Dokument): standardmäßig mit dem speed Compiler-Filter kompiliert.
  • Alle anderen Apps: standardmäßig mit dem speed-profile Compilerfilter kompiliert oder mit dem verify Compilerfilter kompiliert, wenn kein Profil bereitgestellt wird.

    Konfigurierbar über PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (siehe weiter unten in diesem Dokument).

Makefile-Optionen

  • WITH_DEXPREOPT

    • Ob dex2oat auf DEX-Code aufgerufen wird, der auf dem Systemabbild installiert ist. Standardmäßig aktiviert.

  • DONT_DEXPREOPT_PREBUILTS (Android 5 und höher)

    • Durch die Aktivierung DONT_DEXPREOPT_PREBUILTS wird verhindert, dass die vorgefertigten Elemente expreoptiert werden. Dabei handelt es sich um Apps, in deren Android.mk include $(BUILD_PREBUILT) angegeben ist. Das Überspringen von Dexpreopt vorgefertigter Apps, die wahrscheinlich über Google Play aktualisiert werden, spart Platz im Systemabbild, verlängert jedoch die Zeit für den ersten Start. Beachten Sie, dass diese Option keine Auswirkung auf vorgefertigte Apps hat, die in Android.bp definiert sind.

  • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (Android 9 und höher)

    • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER gibt den Standard-Compilerfilter für Dexpreopted-Anwendungen an. Diese Apps sind in Android.bp definiert oder haben in ihrer Android.mk include $(BUILD_PREBUILT) angegeben. Wenn nicht angegeben, ist der Standardwert speed-profile , oder verify , ob der Wert nicht angegeben ist und kein Profil bereitgestellt wird.

  • WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY (seit Android 8 MR1)

    • Durch die Aktivierung von WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY werden nur der Boot-Klassenpfad und die Systemserver-JARs expreoptiert.

  • LOCAL_DEX_PREOPT

    • Dexpreopt kann auch auf individueller App-Basis aktiviert oder deaktiviert werden, indem die Option LOCAL_DEX_PREOPT in der Moduldefinition angegeben wird. Dies kann nützlich sein, um Dexpreopt von Apps zu deaktivieren, die möglicherweise sofort Google Play-Updates erhalten, da die Updates den Dexpreopt-Code im System-Image überflüssig machen würden. Dies ist auch nützlich, um bei OTAs für Hauptversions-Upgrades Platz zu sparen, da Benutzer möglicherweise bereits neuere Versionen von Apps in der Datenpartition haben.

    LOCAL_DEX_PREOPT unterstützt die Werte „true“ oder „false“, um Dexpreopt zu aktivieren bzw. zu deaktivieren. Darüber hinaus kann „nostripping“ angegeben werden, wenn dexpreopt die Datei „ classes.dex nicht aus der APK- oder JAR-Datei entfernen soll. Normalerweise wird diese Datei entfernt, da sie nach expreopt nicht mehr benötigt wird, aber diese letzte Option ist notwendig, damit APK-Signaturen von Drittanbietern gültig bleiben.

  • PRODUCT_DEX_PREOPT_BOOT_FLAGS

    • Übergibt Optionen an dex2oat , um zu steuern, wie das Boot-Image kompiliert wird. Es kann verwendet werden, um benutzerdefinierte Bildklassenlisten, kompilierte Klassenlisten und Compilerfilter anzugeben.

  • PRODUCT_DEX_PREOPT_DEFAULT_FLAGS

    • Übergibt Optionen an dex2oat , um zu steuern, wie alles außer dem Boot-Image kompiliert wird.

  • PRODUCT_DEX_PREOPT_MODULE_CONFIGS

    • Bietet die Möglichkeit, dex2oat Optionen für eine bestimmte Modul- und Produktkonfiguration zu übergeben. Es wird in der Datei device.mk eines Produkts durch $(call add-product-dex-preopt-module-config,<modules>,<option>) festgelegt, wobei <modules> eine Liste von LOCAL_MODULE und LOCAL_PACKAGE -Namen für JAR- und APK-Dateien ist , jeweils.

  • PRODUCT_DEXPREOPT_SPEED_APPS (seit Android 8)

    • Liste der Apps, die als zentral für die Produkte identifiziert wurden und die mit dem speed Compiler-Filter kompiliert werden sollten. Beispielsweise erhalten persistente Apps wie SystemUI erst beim nächsten Neustart die Möglichkeit, die profilgesteuerte Kompilierung zu verwenden. Daher ist es für das Produkt möglicherweise besser, diese Apps immer AOT-kompiliert zu haben.

  • PRODUCT_SYSTEM_SERVER_APPS (seit Android 8)

    • Liste der Apps, die vom Systemserver geladen werden. Diese Apps werden standardmäßig mit dem speed Compiler-Filter kompiliert.

  • PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD (seit Android 8)

    • Ob eine Debug-Version von ART auf dem Gerät eingebunden werden soll. Standardmäßig ist dies für Userdebug- und Eng-Builds aktiviert. Das Verhalten kann überschrieben werden, indem die Option explizit auf true oder false gesetzt wird.

    Standardmäßig verwendet das Gerät die Nicht-Debug-Version ( libart.so ). Um zu wechseln, setzen Sie die Systemeigenschaft persist.sys.dalvik.vm.lib.2 auf libartd.so .

  • WITH_DEXPREOPT_PIC (bis Android 7)

    • In Android 5.1.0 bis Android 6.0.1 kann WITH_DEXPREOPT_PIC angegeben werden, um positionsunabhängigen Code (PIC) zu aktivieren. Dadurch muss kompilierter Code aus dem Image nicht von /system nach /data/dalvik-cache verschoben werden, wodurch Platz in der Datenpartition gespart wird. Es gibt jedoch leichte Auswirkungen auf die Laufzeit, da dadurch eine Optimierung deaktiviert wird, die positionsabhängigen Code nutzt. Normalerweise sollten Geräte, die Platz in /data sparen möchten, die PIC-Kompilierung aktivieren.

    In Android 7.0 war die PIC-Kompilierung standardmäßig aktiviert.

  • WITH_DEXPREOPT_BOOT_IMG_ONLY (bis Android 7 MR1)

    • Diese Option wurde durch WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY ersetzt, die auch die Systemserver-JARs vorab auswählt.

  • PRODUCT_SYSTEM_SERVER_COMPILER_FILTER

    • Diese Option gibt den Compilerfilter für den Systemserver an.

    • (Android 14 und höher) Wenn nicht angegeben, wird der speed-profile Compiler-Filter verwendet, oder der speed Compiler-Filter, wenn kein Profil bereitgestellt wird.
    • (Android 13 und niedriger) Wenn nicht angegeben, wird der speed Compiler-Filter verwendet.
    • Bei der Einstellung speed wird der speed Compiler-Filter verwendet.
    • Bei Einstellung auf speed-profile wird der speed-profile Compilerfilter verwendet, oder der verify -Compilerfilter, wenn kein Profil bereitgestellt wird.
    • Bei der Einstellung verify wird der verify Compilerfilter verwendet.

  • PRODUCT_SYSTEM_SERVER_JARS , PRODUCT_APEX_SYSTEM_SERVER_JARS , PRODUCT_STANDALONE_SYSTEM_SERVER_JARS , PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS

    • Im Folgenden finden Sie Listen der JARs, die vom Systemserver geladen werden. Die JARs werden mit dem durch PRODUCT_SYSTEM_SERVER_COMPILER_FILTER angegebenen Compilerfilter kompiliert

    • (Erforderlich) PRODUCT_SYSTEM_SERVER_JARS : Liste der Systemserver-Klassenpfad-JARs auf der Plattform (d. h. als Teil von SYSTEMSERVERCLASSPATH ). Das Hinzufügen von Systemserver-Klassenpfad-JARs zu dieser Liste ist erforderlich. Wenn der Liste Systemserver-Klassenpfad-JARs nicht hinzugefügt werden, werden diese JARs nicht geladen.
    • (Erforderlich) PRODUCT_APEX_SYSTEM_SERVER_JARS : Liste der Systemserver-Klassenpfad-JARs, die mit APEX bereitgestellt werden (d. h. als Teil von SYSTEMSERVERCLASSPATH ). Das Format ist <apex name>:<jar name> . Das Hinzufügen von APEX-Systemserver-Klassenpfad-JARs zu dieser Liste ist erforderlich. Wenn dieser Liste keine APEX-Systemserver-Klassenpfad-JARs hinzugefügt werden, werden diese JARs nicht geladen.
    • (Optional, Android 13 und niedriger) PRODUCT_STANDALONE_SYSTEM_SERVER_JARS : Liste der JARs, die der Systemserver mithilfe separater Klassenlader dynamisch lädt (über SystemServiceManager.startServiceFromJar ). Das Hinzufügen eigenständiger Systemserver-JARs zu dieser Liste ist nicht erforderlich, wird jedoch dringend empfohlen, da dadurch die JARs kompiliert werden und daher eine gute Laufzeitleistung aufweisen.
    • (erforderlich, seit Android 13) PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS : Liste der mit APEX bereitgestellten JARs, die der Systemserver dynamisch mithilfe separater Klassenlader lädt (d. h. über SystemServiceManager.startServiceFromJar oder deklariert als <apex-system-service> ). Das Format ist <apex name>:<jar name> . Das Hinzufügen eigenständiger APEX-Systemserver-JARs zu dieser Liste ist erforderlich. Wenn eigenständige APEX-Systemserver-JARs nicht zu dieser Liste hinzugefügt werden, führt dies zu einem Startfehler.

    Konfiguration des Boot-Klassenpfads

    Die Liste der vorinstallierten Klassen ist eine Liste von Klassen, die Zygote beim Start initialisiert. Dies erspart es jeder App, diese Klasseninitialisierer separat auszuführen, sodass sie schneller starten und Seiten im Speicher gemeinsam nutzen können. Die Listendatei der vorinstallierten Klassen befindet sich standardmäßig unter frameworks/base/config/preloaded-classes und enthält eine Liste, die für die typische Telefonnutzung optimiert ist. Dies kann bei anderen Geräten wie Wearables anders sein und muss entsprechend angepasst werden. Seien Sie vorsichtig, wenn Sie dies einstellen. Durch das Hinzufügen zu vieler Klassen wird Speicher verschwendet, wenn nicht verwendete Klassen geladen werden. Das Hinzufügen zu weniger Klassen zwingt jede App dazu, eine eigene Kopie zu haben, was wiederum Speicher verschwendet.

    Beispielverwendung (in device.mk des Produkts):

    PRODUCT_COPY_FILES += <filename>:system/etc/preloaded-classes

    Hinweis: Sie müssen diese Zeile platzieren, bevor Sie Produktkonfigurations-Makefiles erben, die das Standard-Makefile von build/target/product/base.mk erhalten.

    Laufzeitkonfiguration

    JIT-Optionen

    Die folgenden Optionen wirken sich nur auf Android-Versionen aus, bei denen der ART JIT-Compiler verfügbar ist.

    • dalvik.vm.usejit : Ob JIT aktiviert ist oder nicht.
    • dalvik.vm.jitinitialsize (Standard 64 KB): Die anfängliche Kapazität des Code-Cache. Der Code-Cache führt regelmäßig eine GC durch und erhöht sich bei Bedarf.
    • dalvik.vm.jitmaxsize (Standard 64 MB): Die maximale Kapazität des Code-Cache.
    • dalvik.vm.jitthreshold (Standard 10000): Der Schwellenwert, den der „Hotness“-Zähler einer Methode überschreiten muss, damit die Methode JIT-kompiliert werden kann. Der „Hotness“-Zähler ist eine laufzeitinterne Metrik. Dazu gehören die Anzahl der Anrufe, Rückwärtsverzweigungen und andere Faktoren.
    • dalvik.vm.usejitprofiles (bis Android 13): Ob JIT-Profile aktiviert sind oder nicht; Dies kann auch dann verwendet werden, wenn dalvik.vm.usejit falsch ist. Beachten Sie, dass, wenn dies falsch ist, der Compiler-Filter speed-profile keine Methode AOT-kompiliert und mit verify äquivalent ist. Seit Android 14 sind JIT-Profile immer aktiviert und können nicht deaktiviert werden.
    • dalvik.vm.jitprithreadweight (standardmäßig dalvik.vm.jitthreshold / 20): Das Gewicht der JIT-„Beispiele“ (siehe jitthreshold) für den Anwendungs-UI-Thread. Verwenden Sie diese Option, um die Kompilierung von Methoden zu beschleunigen, die sich direkt auf das Benutzererlebnis bei der Interaktion mit der App auswirken.
    • dalvik.vm.jittransitionweight (standardmäßig dalvik.vm.jitthreshold / 10): Das Gewicht des Methodenaufrufs, der zwischen Kompilierungscode und Interpreter wechselt. Dadurch wird sichergestellt, dass die beteiligten Methoden kompiliert werden, um (kostspielige) Übergänge zu minimieren.

    Dex2oat-Optionen

    Diese Optionen wirken sich auf die Kompilierung auf dem Gerät aus (auch bekannt als „dexopt “), und einige davon wirken sich auch auf „dexpreopt“ aus, wohingegen die im Abschnitt „System-ROM-Konfiguration“ oben besprochenen Optionen nur „expreopt“ betreffen.

    Optionen zur Steuerung der Ressourcennutzung:

    • dalvik.vm.image-dex2oat-threads / dalvik.vm.image-dex2oat-cpu-set (bis Android 11): Die Anzahl der Threads und der Satz von CPU-Kernen (siehe unten), die für Boot-Images verwendet werden sollen.
    • dalvik.vm.boot-dex2oat-threads / dalvik.vm.boot-dex2oat-cpu-set :
      • (bis Android 11) Die Anzahl der Threads und die Menge der CPU-Kerne (siehe unten), die während des Startvorgangs für alles außer Start-Images verwendet werden sollen.
      • (seit Android 12) Die Anzahl der Threads und der Satz an CPU-Kernen (siehe unten), die während des Startvorgangs für alles verwendet werden sollen, einschließlich Start-Images.
        • Konkret entspricht dies seit Android 14 der Prioritätsklasse PRIORITY_BOOT im ART Service.
    • dalvik.vm.restore-dex2oat-threads / dalvik.vm.restore-dex2oat-cpu-set :
      • (seit Android 11, bis Android 13) Die Anzahl der Threads und die Menge der CPU-Kerne (siehe unten), die für die Wiederherstellung aus der Cloud-Sicherung verwendet werden sollen.
      • (seit Android 14) Die Anzahl der Threads und der Satz an CPU-Kernen (siehe unten), die für alles verwendet werden sollen, was latenzempfindlicher als normal ist, einschließlich der Wiederherstellung aus einem Cloud-Backup.
        • Konkret entspricht dies der Prioritätsklasse PRIORITY_INTERACTIVE_FAST im ART Service.
    • dalvik.vm.background-dex2oat-threads / dalvik.vm.background-dex2oat-cpu-set (seit Android 14): Die Anzahl der Threads und der Satz an CPU-Kernen (siehe unten), die im Hintergrund verwendet werden sollen.
      • Konkret entspricht dies der Prioritätsklasse PRIORITY_BACKGROUND im ART Service.
    • dalvik.vm.dex2oat-threads / dalvik.vm.dex2oat-cpu-set : Die Anzahl der Threads und die Menge der CPU-Kerne, die für alles andere verwendet werden sollen.

    Eine Reihe von CPU-Kernen sollte als durch Kommas getrennte Liste von CPU-IDs angegeben werden. Um beispielsweise dex2oat auf den CPU-Kernen 0–3 auszuführen, legen Sie Folgendes fest:

    dalvik.vm.dex2oat-cpu-set=0,1,2,3

    Beim Festlegen der CPU-Affinitätseigenschaften empfehlen wir, die entsprechende Eigenschaft für die Anzahl der dex2oat-Threads so anzupassen, dass sie mit der Anzahl der ausgewählten CPUs übereinstimmt, um unnötigen Speicher- und E/A-Konflikt zu vermeiden:

    dalvik.vm.dex2oat-cpu-set=0,1,2,3
dalvik.vm.dex2oat-threads=4

    Zusätzlich zu den oben genannten Systemeigenschaften können Sie auch Aufgabenprofile verwenden, um die Ressourcennutzung von dex2oat zu steuern (siehe Cgroup Abstraction Layer ).

    Unterstützte Aufgabenprofile sind:

    • Dex2OatBackground (seit Android 14) (erbt standardmäßig Dex2OatBootComplete ): Steuert die im Hintergrund zu verwendenden Ressourcen.
      • Konkret entspricht dies der Prioritätsklasse PRIORITY_BACKGROUND im ART Service.
    • Dex2OatBootComplete :
      • (bis Android 13) Steuert die Ressource, die nach dem Booten für alles verwendet wird.
      • (seit Android 14) Steuert die Ressource, die nach dem Booten für alles verwendet wird und nicht im Hintergrund.
        • Konkret entspricht dies den Prioritätsklassen PRIORITY_INTERACTIVE_FAST und PRIORITY_INTERACTIVE im ART Service.

    Wenn sowohl Systemeigenschaften als auch Aufgabenprofile angegeben werden, werden beide wirksam.

    Optionen zum Steuern der Heap-Größe:

    • dalvik.vm.image-dex2oat-Xms : Anfängliche Heap-Größe für Boot-Images.
    • dalvik.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.

    Die Optionen, die die anfängliche und maximale Heap-Größe für dex2oat steuern, sollten nicht reduziert werden, da sie die kompilierbaren Anwendungen einschränken könnten.

    Optionen zur Steuerung des Compiler-Filters:

    • dalvik.vm.image-dex2oat-filter (bis Android 11): Der Compiler-Filter für Boot-Images. Seit Android 12 ist der Compiler-Filter für Boot-Images immer speed-profile und kann nicht geändert werden.
    • dalvik.vm.systemservercompilerfilter (seit Android 13): Der Compilerfilter für Systemserver. Siehe 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 Compiler-Filter für alles andere.
    • pm.dexopt.<reason> (seit Android 7): Der Compiler-Filter für alles andere. Siehe ART-Service-Konfiguration für Android 14 und höher oder Paket-Manager-Konfiguration für Android 13 und höher.

    Weitere Optionen zur Steuerung der Kompilierung von allem außer Boot-Images:

    • dalvik.vm.dex2oat-very-large (seit Android 7.1): Mindestgesamtgröße der Dex-Datei in Bytes, um die AOT-Kompilierung zu deaktivieren.
    • dalvik.vm.dex2oat-swap (seit Android 7.1) (Standard: true): Ermöglicht die Verwendung einer Auslagerungsdatei für dex2oat. Dies kann dazu beitragen, Abstürze aufgrund von Speichermangel zu vermeiden. Beachten Sie, dass selbst wenn diese Option aktiviert ist, dex2oat eine Auslagerungsdatei nur unter bestimmten Bedingungen verwendet, z. B. wenn die Anzahl der Dex-Dateien groß ist und sich die Bedingungen ändern können.
    • dalvik.vm.ps-min-first-save-ms (seit Android 12): Die minimale Wartezeit, bevor die Laufzeit beim ersten Start der Anwendung ein Profil der Anwendung generiert.
    • dalvik.vm.ps-min-save-period-ms (seit Android 12): Die Mindestwartezeit, bevor das Profil der Anwendung aktualisiert wird.
    • dalvik.vm.dex2oat64.enabled (seit Android 11) (Standard: false): 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 profilgesteuerte Kompilierung ( speed-profile ), normalerweise während der Hintergrund-Dexopt. Beachten Sie, dass es neben dem prozentualen Schwellenwert auch einen Schwellenwert von mindestens 50 neuen Klassen gibt, der nicht konfigurierbar ist.
    • dalvik.vm.bgdexopt.new-methods-percent (seit Android 12) (Standard: 20): Der Mindestprozentsatz (zwischen 0 und 100) neuer Methoden in einem Profil, um eine Neukompilierung auszulösen. Gilt nur für die profilgesteuerte Kompilierung ( speed-profile ), normalerweise während der Hintergrund-Dexopt. Beachten Sie, dass es neben dem prozentualen Schwellenwert auch einen Schwellenwert von mindestens 100 neuen Methoden gibt, der nicht konfigurierbar ist.
    • 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 eine Reihe fester Blöcke aufgeteilt, sodass kein Block größer als die maximale Größe ist.
    • dalvik.vm.dex2oat-resolve-startup-strings (seit Android 10) (Standard: true) Wenn true, löst dex2oat alle const-strings auf, auf die von Methoden verwiesen wird, die im Profil als „startup“ markiert sind.
    • debug.generate-debug-info (Standard: false) Gibt an, ob Debuginformationen für das native Debuggen generiert werden sollen, z. B. Informationen zum Stapelabwickeln, ELF-Symbole und Zwergabschnitte.
    • dalvik.vm.dex2oat-minidebuginfo (seit Android 9) (Standard: true) Gibt an, ob die minimale Menge an LZMA-komprimierten Debug-Informationen generiert werden soll, die zum Drucken von Backtraces erforderlich sind.

    ART-Serviceoptionen

    Seit Android 14 wird die geräteinterne AOT-Kompilierung für Apps (auch Dexopt genannt) vom ART Service übernommen. Informationen zum Konfigurieren des ART-Dienstes finden Sie unter ART-Dienstkonfiguration .

    Optionen des Paketmanagers

    Vor Android 14 wurde die geräteinterne AOT-Kompilierung für Apps (auch Dexopt genannt) vom Paketmanager verwaltet. Informationen zum Konfigurieren des Paketmanagers für Dexopt finden Sie unter Paketmanagerkonfiguration .

    A/B-spezifische Konfiguration

    ROM-Konfiguration

    Ab Android 7.0 können Geräte zwei Systempartitionen verwenden, um A/B-Systemaktualisierungen zu ermöglichen. Um die Größe der Systempartition zu sparen, können die vorab ausgewählten Dateien in der nicht verwendeten zweiten Systempartition installiert werden. Sie werden dann beim ersten Start in die Datenpartition kopiert.

    Beispielverwendung (in device-common.mk ):

    PRODUCT_PACKAGES += \
     cppreopts.sh
PRODUCT_PROPERTY_OVERRIDES += \
     ro.cp_system_other_odex=1

    Und in BoardConfig.mk des Geräts:

    BOARD_USES_SYSTEM_OTHER_ODEX := true

    Beachten Sie, dass Boot-Klassenpfadcode, Systemservercode und produktspezifische Kernanwendungen immer auf der Systempartition kompiliert werden. Standardmäßig werden alle anderen Apps auf der nicht verwendeten zweiten Systempartition kompiliert. Dies kann mit SYSTEM_OTHER_ODEX_FILTER gesteuert werden, der standardmäßig den Wert hat:

    SYSTEM_OTHER_ODEX_FILTER ?= app/% priv-app/%

    Hintergrund OTA Dexopt

    Auf A/B-fähigen Geräten können Anwendungen vor dem Neustart mit dem neuen Systemabbild im Hintergrund kompiliert werden. Sehen Sie sich die App-Kompilierung im Hintergrund an, um optional das Kompilierungsskript und die Binärdateien in das Systemabbild einzubinden. Der für diese Kompilierung verwendete Kompilierungsfilter wird gesteuert mit:

    pm.dexopt.ab-ota=speed-profile

    Wir empfehlen die Verwendung von speed-profile um die profilgesteuerte Kompilierung zu nutzen und Speicherplatz zu sparen.

    JDWP-Optionen

    Die Erstellung von Java Debug Wire Protocol (JDWP)-Threads in Userdebug-Builds wird über die Systemeigenschaft persist.debug.dalvik.vm.jdwp.enabled gesteuert. Standardmäßig ist diese Eigenschaft nicht festgelegt und JDWP-Threads werden nur für debuggbare Apps erstellt. Um JDWP-Threads sowohl für debuggbare als auch für nicht debuggbare Apps zu aktivieren, setzen Sie persist.debug.dalvik.vm.jdwp.enabled auf 1 . Das Gerät muss neu gestartet werden, damit Änderungen an der Eigenschaft wirksam werden.

    Um eine nicht debuggbare App in einem Userdebug-Build zu debuggen, aktivieren Sie JDWP, indem Sie den folgenden Befehl ausführen:

      adb shell setprop persist.debug.dalvik.vm.jdwp.enabled 1
  adb reboot
    Für Geräte mit Android 13 und niedriger erstellt die Laufzeit JDWP-Threads für debuggbare und nicht debuggbare Apps in Userdebug-Builds. Dies bedeutet, dass es möglich ist, einen Debugger anzuhängen oder jede App in Userdebug-Builds zu profilieren.