Différence entre dexopt et dex2oat?
Google passe de Dalvik à ART (Android Runtime).
J'essayais de comprendre comment cela allait améliorer les performances.
La meilleure explication que j'ai trouvée est l'image ci-dessous:
L’un des composants principaux qui a changé est dexopt en dex2oat.
Étant donné que je n'ai pas la moindre idée de cela, est-ce que quelqu'un peut expliquer la différence et comment cela va améliorer les performances?
dexopt fait quelques optimisations sur le fichier dex. Cela permet, par exemple, de remplacer une instruction d'invocation virtuelle par une version optimisée incluant l'index vtable de la méthode appelée, de sorte qu'il ne soit pas nécessaire d'effectuer une recherche de méthode pendant l'exécution.
Le résultat de dexopt est un fichier odex (dex optimisé). Ceci est très similaire au fichier dex original, à la différence qu’il utilise des opcodes optimisés, comme l’instruction virtuelle invoke optimisée.
dex2oat prend un fichier dex et le compile. Le résultat est essentiellement un fichier elf qui est ensuite exécuté en mode natif. Ainsi, au lieu d’avoir un bytecode interprété par une machine virtuelle, il contient maintenant un code natif qui peut être exécuté de manière native par le processeur. Cela s'appelle une compilation AOT (en avance sur le temps).
Les deux outils sont normalement exécutés au moment de l'installation sur le périphérique .
Un autre facteur à prendre en compte est que dalvik utilisait un compilateur JIT (juste à temps), ce qui signifie qu’elle était également capable de compiler du bytecode en code natif. La principale différence cependant, c’est que ART compile tout à l’avance, alors que dalvik n’a compilé qu’un sous-ensemble du bytecode en utilisant une méthode heuristique pour détecter le code exécuté le plus souvent, puis compilé au cours de l’exécution.
Android Runtime (ART) est un environnement d’exécution utilisé par le système d’exploitation mobile Android. ART remplace Dalvik, qui est la machine virtuelle de processus utilisée à l'origine par Android, et transforme le bytecode de l'application en instructions natives qui sont ensuite exécutées par l'environnement d'exécution du périphérique.
Contrairement à Dalvik, qui depuis Android 2.2 "Froyo" utilise la compilation JIT (Just-In-Time) pour compiler le code intermédiaire chaque fois qu'une application est lancée, ART introduit l'utilisation de la compilation "AOT" en la réalisant lors de l'installation. d'une application. En réduisant la quantité globale de compilation à effectuer lors du fonctionnement d'une application, l'utilisation du processeur d'un périphérique mobile est réduite et la durée de vie de la batterie est améliorée. Dans le même temps, ART apporte des améliorations en termes de performances, de récupération de place, de débogage et de profilage d'applications.
Pour maintenir la compatibilité ascendante, ART utilise le même bytecode d'entrée que Dalvik, fourni via des fichiers .dex standard dans des fichiers APK, tandis que les fichiers .odex sont remplacés par des exécutables ELF (Executable et Linkable Format). Une fois une application compilée à l'aide de l'utilitaire dex2oat intégré à ART, elle est exécutée uniquement à partir de l'exécutable ELF compilé. Cette approche élimine les frais généraux liés à la compilation JIT, mais elle nécessite un temps supplémentaire pour la compilation lors de l'installation d'une application et les applications prennent un peu plus d'espace disque pour stocker le code compilé.