ART : qu’est-ce que c’est, environnement d’exécution et comment ça marche

Qu’est-ce qu’ART ?

Android Runtime (ART) est un environnement d’exécution d’applications qui compile le bytecode DEX en code machine natif avant l’exécution. Contrairement à Dalvik, qui utilisait la compilation Just-In-Time pendant l’exécution, ART effectue une compilation Ahead-Of-Time (AOT) lors de l’installation de l’APK. Ce changement architectural fondamental a conduit à une accélération significative des applications et à une réduction de la consommation d’énergie.

ART est apparu pour la première fois comme une option expérimentale dans Android 4.4 KitKat. Les développeurs pouvaient l’activer dans les paramètres développeur et tester leurs applications. Dans Android 5.0 Lollipop, ART est devenu l’environnement d’exécution par défaut et Dalvik a été complètement supprimé de la plateforme. Au moment de la sortie d’Android 7.0 Nougat, ART avait reçu un mode de compilation hybride.

Historique du développement

La décision de remplacer Dalvik par ART n’a pas été soudaine. Le travail sur le nouvel environnement a commencé en 2012 lorsque Google a reconnu les limites de l’approche JIT. Objectifs principaux : accélérer le lancement des applications, réduire la charge du processeur et diminuer la consommation d’énergie. Le développement a été dirigé par le Android Runtime Group, qui travaillait auparavant sur les optimisations de Dalvik.

Changements architecturaux

ART utilise la même architecture basée sur des registres que Dalvik, mais avec un compilateur entièrement repensé. Au lieu d’un interpréteur et d’un compilateur JIT, ART inclut le compilateur AOT dex2oat, qui convertit les fichiers DEX en binaires ELF lors de l’installation. En conséquence, les applications sur ART démarrent immédiatement avec des performances natives, sans phase de préchauffage.

Architecture d’ART : de Dalvik au nouvel environnement

ART a conservé les principes clés de Dalvik : l’isolation des applications via des processus séparés, l’architecture basée sur des registres et le support du format DEX. Cependant, l’implémentation interne a été entièrement réécrite. Au lieu de l’interpréteur Dalvik, ART inclut trois modes d’exécution : interpréteur, compilateur JIT et compilateur AOT dex2oat. La sélection du mode dépend de l’étape du cycle de vie de l’application.

Le composant clé d’ART est dex2oat (dalvik executable to optimized android translator). Cet utilitaire s’exécute lors de l’installation de l’application (depuis Android 7.0 — également lors de l’optimisation en arrière-plan). dex2oat lit les fichiers DEX de l’APK, optimise le bytecode et génère un fichier OAT — un binaire ELF avec du code natif. Les fichiers OAT sont stockés dans le répertoire /data/dalvik-cache/.

# Vérifier les fichiers OAT sur l’appareil
adb shell ls -la /data/dalvik-cache/arm64/

# Recompilation forcée de l’application
adb shell cmd package compile -m speed com.example.app

Composants d’ART

Le système ART se compose de plusieurs modules interconnectés. Le compilateur dex2oat est responsable de la génération de code natif. Le ramasse-miettes (GC) gère la libération de mémoire. L’interpréteur exécute le code rarement appelé sans compilation. Le profileur suit les méthodes actives pour la compilation hybride. Chaque module peut fonctionner indépendamment, ce qui rend ART flexible et évolutif.

Compilation hybride : JIT + AOT + profilage

À partir d’Android 7.0 Nougat, ART utilise une approche hybride de la compilation, combinant les avantages de JIT et d’AOT. Lors de l’installation de l’application, ART n’effectue plus de compilation AOT complète — à la place, l’application s’exécute en mode interprété avec compilation JIT des méthodes actives. Cela réduit le temps d’installation et l’espace de stockage.

Un profileur en arrière-plan travaille en parallèle. Il collecte des statistiques d’exécution : quelles méthodes sont appelées le plus fréquemment, quelles branches de code sont exécutées, quelles classes sont chargées. Après avoir accumulé suffisamment de données (généralement après 2–3 lancements de l’application), ART exécute dex2oat en arrière-plan et compile uniquement les méthodes actives profilées en code natif.

Modes de compilation

ART prend en charge plusieurs modes de compilation, gérés via system_server. Le mode «speed» compile toutes les méthodes avec AOT (performances maximales, installation lente). Le mode «speed-profile» compile uniquement les méthodes actives profilées (équilibre entre vitesse et taille). Le mode «verify» vérifie uniquement le bytecode sans compilation (espace minimal, interprétation). Par défaut, speed-profile est utilisé — optimal pour la plupart des applications.

Profileur ART

Le profileur collecte les données d’exécution dans des fichiers .prof spéciaux. Chaque application stocke son profil dans /data/misc/profiles/. Lorsque le seuil est atteint (généralement 1000 échantillons), le profileur lance dex2oat pour compiler les méthodes actives identifiées. Les profils sont conservés entre les mises à jour de l’application, ce qui accélère la réoptimisation après les mises à jour OTA du système.

Ramasse-miettes dans ART

Le ramasse-miettes dans ART a été considérablement amélioré par rapport à Dalvik. Au lieu du Concurrent Mark and Sweep (CMS) monothreadé, ART utilise un collecteur générationnel avec plusieurs optimisations : collecteur mobile (compactage du tas), espace des grands objets (stockage séparé pour les grands objets) et compactage concurrent (compactage parallèle).

Une pause GC typique dans ART est de 2–3 ms contre 5–10 ms dans Dalvik. Cela a été rendu possible grâce à plusieurs mécanismes. Premièrement, ART utilise une barrière de lecture (read-barrier) au lieu de stop-the-world pour les phases concurrentes. Deuxièmement, le collecteur générationnel ne traite que la jeune génération d’objets dans la plupart des cycles, sans toucher à l’ensemble du tas. Troisièmement, l’espace des grands objets (LOS) est alloué séparément et ne participe pas aux cycles GC réguliers.

// Activer les logs GC pour le débogage
System.logV("ART", "GC trigger: allocation failed");

// Appel GC forcé (non recommandé en production)
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
    Debug.getRuntimeIStats();
}

Fuite de mémoire à l’ère d’ART

Malgré l’amélioration du GC, les fuites de mémoire restent un problème pertinent. Une cause spécifique à ART est le chargement de bibliothèques natives via JNI sans libération appropriée. Si le code natif alloue de la mémoire via malloc mais n’appelle pas free, ART ne peut pas libérer cette mémoire — elle se trouve en dehors du tas géré. L’outil AddressSanitizer dans Android NDK aide à identifier ces fuites.

ART vs Dalvik : analyse comparative

ART et Dalvik sont deux implémentations fondamentalement différentes de la même tâche : exécuter des applications Android. Les différences affectent tous les niveaux : de la compilation à la gestion de la mémoire. Vous trouverez ci-dessous une comparaison des principaux paramètres de performance et de compatibilité.

Le principal avantage d’ART est l’élimination du préchauffage JIT. Sur Dalvik, une application pouvait ralentir pendant les 3–10 premières secondes pendant que JIT compilait les méthodes actives. Sur ART, toutes les méthodes sont déjà compilées en code natif (ou seront compilées en arrière-plan). Ceci est particulièrement visible dans les jeux et les applications avec une interface lourde : la différence d’images par seconde peut atteindre 15–20% en faveur d’ART.

Compatibilité

Toutes les applications écrites pour Dalvik fonctionnent sur ART sans modification. Google garantit une compatibilité ascendante totale au niveau du bytecode DEX. L’exception est le code utilisant l’API interne spécifique à Dalvik via la réflexion : les membres de la classe dalvik.system.DexFile marqués avec @hide dans Android SDK. Ce code doit être mis à jour pour utiliser les API publiques.

Prise en charge de Java 8 et désugarisation

ART est devenu le premier environnement d’exécution Android avec prise en charge native des fonctionnalités Java 8. À partir d’Android 7.0, ART inclut la désugarisation — le processus de conversion des constructions Java 8 (lambdas, références de méthode, Stream API) en code Java 7 équivalent. Cela permet d’utiliser une syntaxe moderne sans perdre la compatibilité avec les appareils plus anciens.

La désugarisation est effectuée par le compilateur D8 et fonctionne comme suit. Le code source avec un lambda est converti en une méthode synthétique au sein de la même classe, et le lambda est remplacé par un appel invoke-custom. L’environnement d’exécution d’ART inclut la prise en charge de l’instruction invoke-custom, ajoutée spécifiquement pour Java 8. Sur les appareils avec Android 6.0 et inférieur, les lambdas sont désugarisés en classes anonymes.

// Lambda Java 8 — désugarisation dans ART
button.setOnClickListener(v -> handleClick(v));

// Après désugarisation (équivalent en Java 7)
button.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View v) {
        handleClick(v);
    }
});

Limites de la désugarisation

Toutes les fonctionnalités Java 8 ne sont pas prises en charge par la désugarisation. L’API java.time (dates et heures) n’est disponible que via desugar_jdk_libs — une bibliothèque supplémentaire ajoutée dans build.gradle. Stream API nécessite également desugar_jdk_libs. java.util.function et Optional fonctionnent sans dépendances supplémentaires. La prise en charge complète de Java 8 est disponible sur les appareils avec Android 8.0 et supérieur sans désugarisation.

Optimisation des applications pour ART

Bien qu’ART soit compatible ascendant, certaines pratiques d’optimisation améliorent les performances spécifiquement sur cet environnement. La principale recommandation est de minimiser la réflexion. ART compile les méthodes visibles au moment de la compilation en appels directs de code machine. La réflexion oblige ART à générer des stubs supplémentaires, ce qui ralentit l’exécution de 10–15%.

À partir d’Android 9.0, ART a introduit la prise en charge de l’App Startup Optimization. Le développeur peut marquer les classes d’initialisation dans le manifeste via <initialization>, et ART les préchargera au démarrage de l’application. Cela réduit le temps de démarrage de 5–15% pour les applications avec de nombreux plugins ou bibliothèques.

<!-- App Startup Optimization dans AndroidManifest.xml -->
<application>
    <profileable
        android:shell="true"
        android:enable="true" />
</application>

Tests de performance

Pour mesurer les performances sur ART, utilisez systrace et perfetto. Systrace montre le temps de compilation de dex2oat, la fréquence du GC et la vitesse de rendu des images. Perfetto fournit des informations plus détaillées : distribution des threads, temps des transitions JNI, chargement des bibliothèques natives. Lancement : adb shell perfetto -o /data/misc/perfetto-traces/trace.perfetto -t 10s sched freq idle am wm.