Configuration de l'ART

Cette page explique comment configurer ART et ses options de compilation. Les sujets abordés ici incluent la configuration de la pré-compilation de l'image système, les options de compilation dex2oat et la manière de négocier l'espace de partition système, l'espace de partition de données et les performances.

Voir ART et Dalvik , la forme Dalvik Executable , et les autres pages sur source.android.com à travailler avec ART. Voir Vérification App Comportement sur le Runtime Android (ART) pour vous assurer que vos applications fonctionnent correctement.

Comment fonctionne l'ART

ART utilise la compilation à l'avance (AOT) et à partir d'Android 7.0 (Nougat ou N), il utilise une combinaison hybride d'AOT, de compilation juste à temps (JIT) et de compilation guidée par profil. La combinaison de tous ces modes de compilation est configurable et sera discutée dans cette section. Par exemple, les appareils Pixel sont configurés avec le flux de compilation suivant :

  1. Une application est initialement installée sans aucune compilation AOT. Les premières fois que l'application s'exécute, elle sera interprétée et les méthodes fréquemment exécutées seront compilées JIT.
  2. Lorsque l'appareil est inactif et en charge, un démon de compilation s'exécute pour compiler AOT le code fréquemment utilisé en fonction d'un profil généré lors des premières exécutions.
  3. Le prochain redémarrage d'une application utilisera le code guidé par le profil et évitera de faire une compilation JIT à l'exécution pour les méthodes déjà compilées. Les méthodes compilées par JIT lors des nouvelles exécutions seront ajoutées au profil, qui sera ensuite récupéré par le démon de compilation.

ART comprend un compilateur (le dex2oat outil) et un moteur d' exécution ( libart.so ) qui est chargé pour le démarrage du zygote. Le dex2oat outil prend un fichier APK et génère un ou plusieurs fichiers d'artefact de compilation que les charges de l'exécution. Le nombre de fichiers, leurs extensions et leurs noms sont susceptibles de changer d'une version à l'autre, mais à partir de la version Android O, les fichiers générés sont :

  • .vdex : contient le code non compressé de DEX de l'APK, avec quelques métadonnées supplémentaires pour accélérer la vérification.
  • .odex : contient le code compilé AOT pour les méthodes de l'APK.
  • .art (optional) en .art (optional) : contient ART représentations internes de certaines chaînes et classes énumérées dans l'APK, utilisés pour le démarrage de l' application de la vitesse.

Options de compilation

Les options de compilation pour ART sont de deux catégories :

  1. Configuration de la ROM système : quel code est compilé par AOT lors de la création d'une image système.
  2. Configuration d'exécution : comment ART compile et exécute des applications sur un appareil.

Un noyau option ART pour configurer ces deux catégories est filtres compilateur. Filtres compilateur comment conduire ART compile le code DEX et est une option passée à l' dex2oat outil. À partir d'Android O, il existe quatre filtres officiellement pris en charge :

  • vérifier: exécuter uniquement la vérification du code DEX.
  • Quicken: exécuter la vérification du code de DEX et d' optimiser des instructions de DEX pour obtenir une meilleure performance d' un interprète.
  • vitesse: vérification du code d' exécution DEX et AOT-compiler toutes les méthodes.
  • vitesse profil: vérification du code DEX et exécuter AOT décompiler méthodes répertoriées dans un fichier de profil.

Configuration de la ROM système

Il existe un certain nombre d'options de construction ART disponibles pour configurer une ROM système. Comment configurer ces options dépend de l'espace de stockage disponible pour le /system et le nombre d'applications pré-installées. Les JAR/APK compilés dans une ROM système peuvent être divisés en quatre catégories :

  • Boot Code classpath: compilé avec le filtre du compilateur de vitesse par défaut.
  • Code du serveur Système: compilé avec le filtre du compilateur de vitesse par défaut.
  • Applications de base propres aux produits: compilé avec le filtre de compilateur de vitesse par défaut.
  • Toutes les autres applications: compilé avec le filtre du compilateur Quicken par défaut.

Options de makefile

  • WITH_DEXPREOPT
  • Que dex2oat est invoqué sur le code DEX installé sur l'image du système. Activé par défaut.

  • DONT_DEXPREOPT_PREBUILTS (depuis Android L)
  • L' activation de DONT_DEXPREOPT_PREBUILTS empêche le prebuilts d'être pré-optimisé. Ce sont des applications qui ont include $(BUILD_PREBUILT) spécifié dans leur Android.mk , tels que Gmail. Skipping pré-optimisation des applications préconfigurés qui sont susceptibles d'être mis à jour via Google Play sauve /system d' espace , mais ne ajoute au premier démarrage.

  • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (depuis les applications 9)
  • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER spécifie le filtre du compilateur par défaut pour les applications pré-optimisées. Ce sont des applications qui ont include $(BUILD_PREBUILT) spécifié dans leur Android.mk , tels que Gmail. Si non spécifié, la valeur par défaut est quicken.

  • WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY (nouveau dans les applications O MR1)
  • Activation WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY pré-optimise seulement le classpath de démarrage et des pots de serveur système.

  • LOCAL_DEX_PREOPT
  • Pré-optimisation peut également être activée ou désactivée sur une base de chaque application en spécifiant l' LOCAL_DEX_PREOPT option dans la définition du module. Cela peut être utile pour désactiver la pré-optimisation des applications qui peuvent recevoir immédiatement des mises à jour de Google Play, car les mises à jour rendraient le code pré-optimisé dans l'image système obsolète. Ceci est également utile pour économiser de l'espace sur les OTA de mise à niveau de version majeure, car les utilisateurs peuvent déjà disposer de versions plus récentes d'applications dans la partition de données.

    LOCAL_DEX_PREOPT soutient les valeurs de vrai »ou « faux » pour activer ou désactiver pré-optimisation, respectivement. En outre, « nostripping » peut être spécifié si pré-optimisation ne doit pas dépouiller le classes.dex fichier à partir du fichier APK ou JAR. Normalement, ce fichier est supprimé car il n'est plus nécessaire après la pré-optimisation, mais cette dernière option est nécessaire pour permettre aux signatures APK tierces de rester valides.

  • PRODUCT_DEX_PREOPT_BOOT_FLAGS
  • Laissez - passer des options pour dex2oat pour contrôler la façon dont l'image de démarrage est compilé. Il peut être utilisé pour spécifier des listes de classes d'images personnalisées, des listes de classes compilées et des filtres de compilateur.

  • PRODUCT_DEX_PREOPT_DEFAULT_FLAGS
  • Laissez - passer des options à dex2oat pour contrôler la façon dont tout en plus l'image de démarrage est compilé.

  • PRODUCT_DEX_PREOPT_MODULE_CONFIGS
  • Offre la possibilité de passer dex2oat options pour un module particulier et la configuration du produit. Il est situé dans un de produit device.mk fichier par $(call add-product-dex-preopt-module-config,<modules>,<option>)<modules> est une liste de noms de LOCAL_MODULE et LOCAL_PACKAGE pour JAR et APK fichiers, respectivement.

  • PRODUCT_DEXPREOPT_SPEED_APPS (New in Android O)
  • Liste des applications qui ont été identifiées comme base aux produits et qui sont souhaitables pour compiler avec le filtre du compilateur de vitesse. Par exemple, les applications persistantes telles que SystemUI ont la possibilité d'utiliser la compilation guidée par profil uniquement au prochain redémarrage, il peut donc être préférable que le produit ait toujours ces applications compilées AOT.

  • PRODUCT_SYSTEM_SERVER_APPS (New in Android O)
  • Liste des applications chargées par le serveur système. Ces applications seront compilées par défaut avec le filtre du compilateur de vitesse.

  • PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD(Post Android O)
  • S'il faut inclure une version de débogage d'ART sur l'appareil. Par défaut, ceci est activé pour les builds userdebug et eng. Le comportement peut être remplacée en définissant explicitement l'option true ou false.

    Par défaut, l'appareil utilisera la version non-debug (libart.so). Pour commutateur, définissez la propriété du système persist.sys.dalvik.vm.lib.2 à libartd.so.

  • WITH_DEXPREOPT_PIC (Removed in Android O)
  • Dans les applications à travers les applications 5.1.0 6.0.1, WITH_DEXPREOPT_PIC peut être spécifié pour activer le code indépendant de la position (PIC). Avec cela, le code compilé à partir de l'image n'a pas besoin d'être déplacé de /system vers /data/dalvik-cache, économisant de l'espace dans la partition de données. Cependant, il y a un léger impact sur l'exécution car cela désactive une optimisation qui tire parti du code dépendant de la position. En règle générale, les périphériques souhaitant économiser de l'espace dans /data doivent activer la compilation PIC.

    Dans Android 7.0, la compilation PIC était activée par défaut.

  • WITH_DEXPREOPT_BOOT_IMG_ONLY (enlevé dans les applications O MR1)
  • Cette option a été remplacée par WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY qui préactive également les fichiers jar du serveur système.

Configuration du chemin de classe de démarrage

  • Liste des classes préchargées
  • La liste des classes préchargées est une liste des classes que le zygote initialise au démarrage. Cela évite à chaque application d'avoir à exécuter ces initialiseurs de classe séparément, ce qui leur permet de démarrer plus rapidement et de partager des pages en mémoire. Les classes préchargé fichier de liste se trouve à frameworks/base/config/preloaded-classes par défaut, et il contient une liste qui est accordée pour l' utilisation du téléphone typique. Cela peut être différent pour d'autres appareils tels que les appareils portables, et doit être réglé en conséquence. Soyez prudent lorsque vous réglez cela ; ajouter trop de classes gaspille de la mémoire lorsque des classes inutilisées sont chargées. L'ajout de trop peu de classes oblige chaque application à avoir sa propre copie, ce qui, encore une fois, gaspille de la mémoire.

    Exemple d'utilisation (dans le fichier device.mk du produit) :

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

    Note: Cette ligne doit être placé avant d' hériter des makefiles de configuration du produit qui obtiennent une par défaut à partir de : build/target/product/base.mk

  • Liste des classes d'images
  • La liste des classes d'images est une liste de classes que dex2oat initialise à l'avance et stocke dans le fichier boot.art. Cela permet au zygote de charger ces résultats à partir du fichier boot.art au démarrage au lieu d'exécuter lui-même les initialiseurs de ces classes pendant le préchargement. Une caractéristique clé de ceci est que les pages chargées à partir de l'image et partagées entre les processus peuvent être propres, ce qui permet de les remplacer facilement dans des situations de faible mémoire. En L, par défaut, la liste des classes d'images utilise la même liste que la liste des classes préchargées. À partir de post-L dans AOSP, une liste de classes d'images personnalisées peut être spécifiée en utilisant :

    PRODUCT_DEX_PREOPT_BOOT_FLAGS
    

    Exemple d' utilisation (dans le produit de device.mk ):

    PRODUCT_DEX_PREOPT_BOOT_FLAGS += --image-classes=<filename>
    
  • Liste des classes compilées
  • Dans le post-L AOSP, un sous-ensemble de classes du chemin de classe de démarrage peut être spécifié pour être compilé lors de la pré-optimisation à l'aide de la liste des classes compilées. Cela peut être une option utile pour les appareils dont l'espace est très restreint et qui ne peuvent pas contenir l'intégralité de l'image de démarrage pré-optimisée. Cependant, les classes de notes non spécifiées par cette liste ne seront pas compilées - même pas sur le périphérique - et doivent être interprétées, ce qui pourrait affecter les performances d'exécution. Par défaut, dex2oat recherchera une liste de classes compilées dans $OUT/system/etc/compiled-classes, afin qu'une liste personnalisée puisse être copiée à cet emplacement par le device.mk. Un emplacement de fichier particulier peut également être spécifié en utilisant:

    PRODUCT_DEX_PREOPT_BOOT_FLAGS
    

    Exemple d' utilisation (dans le produit de device.mk ):

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

    Note: Cette ligne doit être placé avant d' hériter des makefiles de configuration du produit qui obtiennent une par défaut à partir de : build/target/product/base.mk

Configuration d'exécution

Options d'ajustement

Les options suivantes affectent les versions Android uniquement lorsque le compilateur ART JIT est disponible.

  • dalvik.vm.usejit : si le JIT est activé ou non.
  • dalvik.vm.jitinitialsize (64K par défaut) : la capacité initiale du cache de code. Le cache de code sera régulièrement GC et augmentera si nécessaire.
  • dalvik.vm.jitmaxsize (par défaut 64M) : la capacité maximale du cache de code.
  • dalvik.vm.jitthreshold : (par défaut 10000) - Il s'agit du seuil que le compteur "hotness" d'une méthode doit franchir pour que la méthode soit compilée JIT. Le compteur "hotness" est une métrique interne au runtime. Il comprend le nombre d'appels, les branches vers l'arrière et d'autres facteurs.
  • dalvik.vm.usejitprofiles : si les profils JIT sont activés ou non ; cela peut être utilisé même si dalvik.vm.usejit est faux. Notez que si cela est faux, le filtre du compilateur vitesse profil ne AOT-compiler toute méthode et équivaut à vivifier.
  • dalvik.vm.jitprithreadweight (valeur par défaut dalvik.vm.jitthreshold / 20) - Le poids des "échantillons" JIT (voir jitthreshold) pour le thread d'interface utilisateur de l'application. À utiliser pour accélérer la compilation des méthodes qui affectent directement l'expérience des utilisateurs lorsqu'ils interagissent avec l'application.
  • dalvik.vm.jittransitionweight : (valeur par défaut dalvik.vm.jitthreshold / 10) le poids de l'invocation de méthode qui effectue la transition entre le code de compilation et l'interpréteur. Cela permet de s'assurer que les méthodes impliquées sont compilées pour minimiser les transitions (qui sont coûteuses).

Options du gestionnaire de paquets

Depuis Android 7.0, il existe un moyen générique de spécifier le niveau de compilation/vérification qui s'est produit à différentes étapes. Les niveaux de compilation peuvent être configurés via les propriétés système, les valeurs par défaut étant :

  • pm.dexopt.install=speed-profile
  • Il s'agit du filtre de compilation utilisé lors de l'installation d'applications via Google Play. Nous vous recommandons de définir le filtre d'installation sur speed-profile afin de permettre l'utilisation de profils à partir des fichiers de métadonnées dex. A noter que si un profil n'est pas fourni ou s'il est vide speed-profile est équivalent à quicken.

  • pm.dexopt.bg-dexopt=speed-profile
  • Il s'agit du filtre de compilation utilisé lorsque l'appareil est inactif, en charge et complètement chargé. Essayez le filtre du compilateur profil de vitesse pour tirer parti de la compilation guidée profil et enregistrer sur le stockage.

  • pm.dexopt.boot=verify
  • Le filtre de compilation utilisé après une mise à jour sans fil. Nous vous recommandons vivement de vérifier le filtre compilateur pour cette option pour éviter de très longues durées de démarrage.

  • pm.dexopt.first-boot=quicken
  • Le filtre de compilation pour la première fois que l'appareil démarre. Le filtre utilisé ici n'affectera que le temps de démarrage après l'usine. Nous vous recommandons le filtre pour vivifier pour éviter de longs temps avant qu'un utilisateur est autorisé à utiliser le téléphone pour la première fois. Notez que si toutes les applications de /system sont déjà compilés avec le filtre du compilateur Quicken ou sont compilés avec le filtre du compilateur profil de vitesse ou la vitesse, la pm.dexopt.first-boot n'a pas d' effet.

Options Dex2oat

Notez que ces options affectent dex2oat lors de la compilation sur l'appareil, ainsi que lors de la pré-optimisation, alors que la plupart des options discutées ci - dessus affectent uniquement pré-optimisation.

Pour contrôler dex2oat alors qu'il compile l'image de démarrage:

  • dalvik.vm.image-dex2oat-Xms : taille initiale du tas
  • dalvik.vm.image-dex2oat-Xmx : taille maximale du segment de mémoire
  • dalvik.vm.image-dex2oat-filter : option de filtre du compilateur
  • dalvik.vm.image-dex2oat-threads : nombre de threads à utiliser

Pour contrôler dex2oat alors qu'il compile tout en plus de l'image de démarrage:

  • dalvik.vm.dex2oat-Xms : taille initiale du tas
  • dalvik.vm.dex2oat-Xmx : taille maximale du segment de mémoire
  • dalvik.vm.dex2oat-filter : option de filtre du compilateur

Sur les versions via Android 6.0, une option supplémentaire est fournie pour tout compiler en dehors de l'image de démarrage :

  • dalvik.vm.dex2oat-threads : nombre de threads à utiliser

À partir d'Android 6.1, cela devient deux options supplémentaires pour tout compiler en dehors de l'image de démarrage :

  • dalvik.vm.boot-dex2oat-threads : nombre de threads à utiliser pendant le démarrage
  • dalvik.vm.dex2oat-threads : nombre de threads à utiliser après le démarrage

À partir d'Android 7.1, deux options sont fournies pour contrôler l'utilisation de la mémoire lors de la compilation de tout en dehors de l'image de démarrage :

  • dalvik.vm.dex2oat-very-large : taille minimale du fichier dex total en octets pour désactiver la compilation AOT
  • dalvik.vm.dex2oat-swap : utilisez le fichier d'échange dex2oat (pour les appareils à faible mémoire)

Les options qui contrôlent la taille de tas initiale et maximale pour dex2oat ne doivent pas être réduits car ils pourraient limiter ce que les applications peuvent être compilées.

À partir d'Android 11, trois options d'affinité du processeur sont fournies pour permettre aux threads du compilateur d'être limités à un groupe spécifique de processeurs :

  • dalvik.vm.boot-dex2oat-cpu-set : processeurs exécutant les threads dex2oat pendant le démarrage
  • dalvik.vm.image-dex2oat-cpu-set : processeurs exécutant dex2oat lors de la compilation de l'image de démarrage
  • dalvik.vm.dex2oat-cpu-set : processeurs exécutant les threads dex2oat après le démarrage

Les CPU doivent être spécifiés sous la forme d'une liste d'ID de CPU séparés par des virgules. Par exemple, pour exécuter sur dex2oat sur les CPU 0-3, définissez :

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

Lors de la définition des propriétés d'affinité du processeur, nous vous recommandons de faire correspondre la propriété correspondante pour le nombre de threads dex2oat pour correspondre au nombre de processeurs sélectionnés pour éviter la mémoire inutile et les conflits d'E/S :

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

À partir d'Android 12, les options suivantes ont été ajoutées :

  • dalvik.vm.ps-min-first-save-ms : le temps d'attente pour que le runtime génère un profil de l'application, la première fois que l'application est lancée
  • dalvik.vm.ps-min-save-period-ms : le temps minimum à attendre avant de mettre à jour le profil d'une application
  • dalvik.vm.systemservercompilerfilter : le filtre du compilateur que l'appareil utilisera lors de la recompilation du serveur système

Configuration spécifique A/B

configuration de la ROM

A partir de Android 7.0, les périphériques peuvent utiliser deux partitions système pour activer les mises à jour du système A / B . Pour économiser sur la taille de la partition système, les fichiers pré-optés peuvent être installés dans la deuxième partition système inutilisée. Ils sont ensuite copiés sur la partition de données lors du premier démarrage.

Exemple d' utilisation (en device-common.mk ):

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

Et dans l' appareil est BoardConfig.mk :

BOARD_USES_SYSTEM_OTHER_ODEX := true

Notez que le code du chemin de classe de démarrage, le code du serveur système et les applications principales spécifiques au produit se compilent toujours sur la partition système. Par défaut, toutes les autres applications sont compilées sur la deuxième partition système inutilisée. Cela peut être contrôlé par l' SYSTEM_OTHER_ODEX_FILTER , qui a une valeur par défaut:

SYSTEM_OTHER_ODEX_FILTER ?= app/% priv-app/%

Contexte dexopt OTA

Avec les appareils compatibles A/B, les applications peuvent être compilées en arrière-plan pour la mise à jour vers la nouvelle image système. Voir la compilation en arrière - plan App pour éventuellement inclure le script de compilation et les fichiers binaires dans l'image du système. Le filtre de compilation utilisé pour cette compilation est contrôlé avec :

pm.dexopt.ab-ota=speed-profile

Nous vous recommandons d' utiliser profil de vitesse pour tirer parti de la compilation guidée de profil et enregistrer sur le stockage.