Le runtime ART d’Android change la façon dont le code Java s’exécute sur mobile et influence directement la performance des applications Android. Ce système remplace l’ancienne machine virtuelle Dalvik et privilégie des stratégies de compilation différentes pour optimiser l’exécution au profit de l’utilisateur.
Comprendre les fichiers .art et .oat éclaire leur rôle dans la chaîne de compilation et d’exécution des applications Android. Ces éléments techniques méritent attention avant d’aborder les points clés qui suivent
A retenir :
- Démarrage d’applications nettement plus rapide grâce à la compilation AOT
- Moindre consommation CPU et batterie pour l’exécution prolongée
- Fichiers .art et .oat contenant code natif et métadonnées précompilées
- Sécurité renforcée par vérification stricte du bytecode précompilé
Fonctionnement du runtime ART sur Android
Compilation AOT et rôle de dex2oat
Ce point explique pourquoi dex2oat intervient lors de l’installation d’une application afin de produire du code exécutable natif. L’outil assure la conversion du .dex en code adapté à l’architecture du processeur présent sur l’appareil.
Le résultat de cette compilation est stocké dans des fichiers reconnus par le système et lisibles par le runtime. Ces fichiers incluent souvent un exécutable au format ELF ainsi que des métadonnées nécessaires à l’exécution.
Étape
Entrée
Sortie
Emplacement typique
Compilation dex2oat
classes.dex
fichiers .oat/.art
/data/dalvik-cache
Génération code natif
bytecode
ELF intégré
/data/app
Image de classes
VM image
fichier .art
/system/framework
Cache d’exécution
optimisations
fichiers optimisés
/data/dalvik-cache
Rôles principaux d’ART :
- Compilation Ahead-of-Time pour code natif
- Gestion mémoire et garbage collection optimisée
- Vérification stricte des classes et du bytecode
- Mécanismes de profilage pour optimisations ciblées
« J’ai observé des lancements d’applications nettement plus rapides sur mon Pixel après les optimisations ART »
Alice R.
Flux d’installation et cache dalvik
Ce processus d’installation remplace la recompilation continue par un précompilage, réduisant la charge CPU lors de l’exécution. Selon Android Open Source Project, cette approche vise à diminuer la latence et la consommation énergétique en production.
Le système conserve les résultats dans des caches dédiés pour accélérer les démarrages suivants et permettre le paging des pages rares. Ce comportement conduit naturellement à distinguer les formats .art, .oat et .dex, sujet que nous traitons ensuite.
Fichiers .art, .oat et ELF : différences pratiques
Comparaison fonctionnelle des formats
En conséquence, la gestion des caches expose des rôles distincts pour chaque format et explique leur coexistence sur Android. Selon Google, .dex reste le bytecode tandis que .oat et .art servent l’exécution optimisée.
Format
Contenu principal
Usage
Localisation
.dex
bytecode Java/Kotlin
embarquée dans l’APK
APK / classes.dex
.odex
fragments optimisés (legacy)
cache Dalvik historique
/system/framework (anciens)
.oat
code natif + métadonnées
exécution optimisée
/data/app ou dalvik-cache
.art
image de classes précompilées
accélération VM au démarrage
/system/framework ou /data
Comparaisons de formats :
- Format intermédiaire versus code natif
- Rôle historique de .odex dans Dalvik
- Image .art pour accélération de la VM
- .oat pour exécution spécifique au CPU
« Sur notre flotte d’appareils, la batterie tient mieux depuis l’adoption d’ART et son profiling »
Marc L.
ELF et présence du code machine
La présence d’exécutables au format ELF dans les .oat rend l’exécution directe possible sans interprétation supplémentaire. Selon Wikipédia, l’ELF est le standard sur Linux et sert à stocker le code machine exécutable.
Un aperçu visuel aide à saisir ces différences et à expliquer pourquoi certains fichiers restent système et d’autres user-facing. L’étape suivante traite les implications pour les développeurs et l’optimisation applicative.
Impact pour développeurs et optimisation des applications Android
Gain de performance mesurable et profilage
Le passage à des compilations guidées par profil permet d’équilibrer performance et taille finale, choix aujourd’hui répandu sur Android N et versions ultérieures. Selon Google I/O, la compilation guidée par profil cible les méthodes chaudes pour maximiser le rapport coût bénéfice.
Optimisations recommandées :
- Activer le profilage pour méthodes critiques
- Utiliser Cloud Profiles pour démarrages rapides
- Minimiser le code rarement exécuté
- Tester sur architectures ARM et x86 représentatives
« La compilation guidée par profil équilibre la vitesse initiale et la taille d’installation, avantage concret pour l’utilisateur »
Claire D.
Bonnes pratiques de packaging et distribution
Pour limiter l’empreinte disque, il est conseillé d’extraire et modulariser les composants rarement utilisés et de privilégier les librairies partagées lorsque cela est pertinent. Selon Android Open Source Project, la fragmentation des artefacts aide à réduire la surcompilation inutile.
Bonnes pratiques packaging :
- Séparer modules fonctionnels lourds
- Fournir profils cloud pour expériences rapides
- Automatiser tests sur images ARM et x86
- Surveiller taille .oat/.art après build
« Pour nous, ART a amélioré la fluidité générale des applications publiées sur le store »
Paul N.
Source : Android Open Source Project, « Android Runtime and Dalvik », Android Open Source Project, 2018 ; Google, « Understanding Android Runtime (ART) », Android Developers, 2019 ; Wikipédia, « ART (Android) », Wikipédia, 2024.
