Sélection du moteur d'exécution (Dedicated Runtime) : ART vs Dalvik
Description
Depuis l'arrivée de mon Nexus 5 et donc de Android KitKat, je vois du ART par ci, du Dalvik par là avec des arguments qui se défendent et qui se contredisent... J'ai donc décidé de faire le point sur ces 2 moteurs d'exécution pour enfin avoir une vision claire et personnelle de la chose.
Pour info/rappel, cette option se trouve dans Paramètres > Options de développement. Vous n'avez pas "Options de développement" ? Allez dans Paramètres > A propos du téléphone > Appuyez 7 fois sur "Numéro de build".
L'ART est annoncé comme un gain de performance sur le lancement des applications donc beaucoup d'utilisateurs l'ont activé. Mais ART n'est pas stable, des problèmes peuvent apparaître. Si vous avez activé l'ART et que vous constatez des bugs sur votre ROM, ne vous plaignez pas !
Introduction de l'ART par Google :
Spoiler :
ART is a new Android runtime being introduced experimentally in the 4.4 release. This is a preview of work in progress in KitKat that can be turned on in Settings > developer options. This is available for the purpose of obtaining early developer and partner feedback.
Important: Dalvik must remain the default runtime or you risk breaking your Android implementations and third-party applications.
Two runtimes are now available, the existing Dalvik runtime (libdvm.so) and the ART (libart.so). A device can be built using either or both. (You can dual boot from Developer options if both are installed.)
The dalvikvm command line tool can run with either of them now. See runtime_common.mk. That is included from build/target/product/runtime_libdvm.mk or build/target/product/runtime_libdvm.mk or both.
A new PRODUCT_RUNTIMES variable controls which runtimes are included in a build. Include it within either build/target/product/core_minimal.mk or build/target/product/core_base.mk.
Add this to the device makefile to have both runtimes built and installed, with Dalvik as the default: PRODUCT_RUNTIMES := runtime_libdvm_default PRODUCT_RUNTIMES += runtime_libart
C'est quoi Dalvik ?
C'est le process de machine virtuelle dans le système opérationnel Android. C'est le software qui lance les applications sur les appareils Android. Dalvik est donc une partie intégrale d'Android, qui est typiquement utilisé sur les appareils mobiles mais aussi dans les Smart TVs et le streaming. Les programmes sont généralement écris en Java et compilés en bytecode. Ils sont ensuite convertis de fichiers .class "Java Virtual Machine-compatible" en fichier .dex (Dalvik Exécutable) "Dalvik-compatible". avant installation sur l'appareil. Le format compact Dalvik Exécutable est conçu être adapté aux systèmes qui sont limités en termes de mémoire et de rapidité de processeur. Dalvik est un software open-source.
C'est quoi ART ?
ART est un projet sur lequel travaille Google depuis 2 ans. Le but de l'ART était de produire un moteur d'exécution plus rapide qui ne subirait pas les problèmes du Dalvik. Android KitKat 4.4 est le premier OS avec ART inclus dans les options de développement bien que nous ne sachions pas vraiment depuis quand cette option existe.
ART signifie Android RunTime.
OK et c'est quoi la différence alors ?
La principale différence entre ART et Dalvik c'est lorsqu'il ils compilent le code d'une application. Dalvik opère via une méthode de compilation JIT (Just In Time), ce qui veut dire que lorsque les développeurs créent leurs applications, ils compilent partiellement leur code en bytecode, qui est interprété par la machine virtuelle Java. Dalvik convertit le bytecode en machinecode pour que l'application se lance en vue d'améliorer la performance (l'exécution bytecode est plus lente que l'exécution machinecode). ART diffère du Dalvik en réalisant cette compilation dy bytecode vers le machinecode à l'installation de l'application et sauvegarde ces données dans la mémoire du téléphone (et pas la RAM).
Alors pourquoi utiliser ART ?
Uitliser ART au lieu de Dalvik permet au système d'utiliser moins de ressources lors de lu lancement. Quand les applications sont lancées, l'analyse du bytecode n'est pas en-cours d'exécution, ceci peut réduire la charge CPU et l'utilisation de la mémoire. L'effet obtenu est un temps de démarrage de l'application plus rapide (environ 2 fois plus vite) et un gain de performance sur l'application en elle-même.
Il est à noter que les optimisations de performance va uniquement améliorer les composants Java des applications.
Pourquoi ne pas utiliser ART ?
Tout d'abord, la documentation ART de Google suggère de ne PAS utiliser ART car cela peut provoquer des instabilités de l'application ou du système en général. ART reste en phase de développement à l'heure actuelle et n'est pas censé être utilisé au quotidien.
De plus, de part sa nature, l'ART va occuper de l'espace sur votre mémoire interne : entre 10 et 20% du code de l'application. Rappelez-vous aussi que les majorités des applications sont généralement composés de fichiers media (images, vidéos, sons...) donc ces composants ne seront pas affectés. Par exemple, l'application Google+ pèse environ 28Mo or le code fait seulement 7Mo. L'augmentation de la taille de stockage est minime mais reste significative pour être prise en compte.
Ensuite, le premier démarrage après activation de l'ART peut prendre jusqu'à 10min du fait de cette compilation. L'installation des applications prendra également un peu plus de temps (si vous avez un téléphone récent assez "haut de gamme", vous ne sentirez pas trop de différences).
Enfin, l'ART peut provoquer des anomalies sur les sauvegardes et restaurations d'applications.
ROMs Custom et ART
Vu que les développeurs commencent à créer des Roms KitKat depuis la source, ils devront décider s'ils veulent intégrer l'ART dans leurs builds ou pas. Google a créé un module pour inclure l'ART en plus du Dalvik. C'est une simple implantation mais si les sujets de discussion sur les ROMs font remonter des problèmes, il n'est pas illogique de penser que les développeurs excluront l'ART de leurs ROMs.
L'ART ne peut pas fonctionner avec des applications déodexées. Les fichiers .odex sont requis pour la compilation bytecode vers machinecode. Flasher une ROM déodexée ou des GApps avec l'ART activé va générer des fermetures forcées alias Force Close (FC) et faire planter l'interface utilisateur (UI).
De même, le premier démarrage après l'installation d'une nouvelle ROM prendra plus de temps avec l'ART car en faisant le fameux Wipe Data/Factory Reset, le code précompilé stocké par l'ART sera effacé. Dalvik sera toujours activé au démarrage donc le transfert vers l'ART requerra un redémarrage et un peu de patience.
Autres infos
=> Liste des applications qui fonctionnent et qui ne fonctionnent pas avec l'ART activé Source
Dernière édition par Primokorn le Jeu 21 Nov 2013 - 8:59, édité 2 fois
Non pas du tout. Les applications sont toujours écrites en Java, dans les 2 cas.
En gros, Dalvik travaille au lancement des applications et ART travaille à l'installation des applications. Quand le Dalvik travaille, on puise dans la RAM. Quand l'ART travaille, il puise dans les fichiers qu'il a créé à l'installation de l'application. Ce qui fait qu'on utilise moins de RAM mais plus de stockage.
Mais y'a eu du changement A la suite de messages et de nouvelles versions de ROMs Custom, on peut finalement dire que l'ART fonctionne sur les ROMs déodexées. L'ART n'est donc pas uniquement réservée aux versions Android odexées.