Le runtime ART sur Android a transformé la gestion de la compilation des applications mobiles et des artefacts système. La précompilation AOT et le profilage JIT diminuent le temps de compilation tout en améliorant la performance à l’exécution.
Ce texte présente les mécanismes d’ART, ses options de configuration et des exemples concrets pour le développement mobile. Lisez ci-dessous les points clés pour orienter vos choix techniques et vos tests.
A retenir :
- Temps de compilation réduit grâce à AOT et profilage JIT
- Meilleure fluidité d’exécution des applications et gain d’autonomie batterie
- Choix de filtres de compilation modulaires pour compromis stockage/performance
- ART modulaire mis à jour via Play Store sans OS
ART et runtime Android : impact sur le temps de compilation
Après ces points clés, il faut examiner comment ART réduit concrètement le temps de compilation des applications Android. Le runtime combine compilation anticipée et mécanismes JIT guidés par profil pour optimiser l’exécution.
L’outil dex2oat produit des artefacts .art et .oat chargés au démarrage par libart.so. Comprendre ces composants explique pourquoi choisir certains filtres de compilation selon les contraintes.
Composant
Rôle
Effet sur temps de compilation
dex2oat
Compile DEX en code natif
Réduit compilation à l’exécution, charge initiale augmentée
libart.so
Environnement d’exécution chargé au démarrage
Charge les artefacts, influence démarrage des apps
Profils JIT
Guident compilation AOT progressive
Optimisent méthodes critiques sans recompilation complète
Fichiers .art/.oat
Contiennent code machine optimisé
Accélèrent exécution après installation
Paramètres de compilation :
- dalvik.vm.dex2oat-cpu-set affinité processeurs
- dalvik.vm.dex2oat-threads nombre de threads dex2oat
- dalvik.vm.dex2oat-Xmx mémoire maximale pour compilation
- dalvik.vm.image-dex2oat-filter filtre pour images de démarrage
« J’ai observé un démarrage d’application plus rapide après l’activation du profilage speed-profile sur nos builds pilotes. »
Alice D.
La précompilation AOT explique pourquoi des gains substantiels sont visibles sur des appareils récents. Selon Android Open Source Project, la combinaison AOT/JIT améliore l’efficacité sans sacrifier la compatibilité.
La configuration des threads et de l’affinité CPU évite la contention et réduit les durées de dex2oat. Ces réglages sont cruciaux pour les builds destinés à la production.
Configurer ART pour réduire le temps de compilation des applications
Suite à l’analyse des composants, la configuration de l’ART devient déterminante pour l’équilibre stockage/performance. Les options dexpreopt, filtres et flags dex2oat permettent des compromis mesurables.
Options de dexpreopt et filtres de compilation
Ce point décrit le rôle de dexpreopt et des filtres de compilation sur la taille et la vitesse des images. Selon Android Open Source Project, dexpreopt précompile les applications système lors de la création de l’image.
« Nous avons choisi speed-profile pour certaines apps système et mesuré un compromis espace/temps favorable. »
Marc L.
Filtres officiels et compromis
Cette section compare les filtres officiels et leurs usages recommandés pour le développement mobile. Selon Wikipedia, les filtres verify, speed et speed-profile existent officiellement depuis Android 8.
Filtre
Description
Usage recommandé
verify
Vérifie bytecode sans compiler AOT
Images avec stockage restreint
speed
Compilation AOT plus complète
Apps critiques pour performance au démarrage
speed-profile
Compilation guidée par profil JIT puis AOT
Bon compromis espace/performance
everything
Compilation AOT exhaustive
Maximum performance au coût d’espace
Choix de filtres :
- Speed-profile pour économie d’espace et gain de vitesse
- Speed pour composants critiques SystemServer et SystemUI
- Verify pour minimiser empreinte système
Les flags PRODUCT_DEX_PREOPT_DEFAULT_FLAGS et PRODUCT_DEX_PREOPT_MODULE_CONFIGS permettent d’affiner la compilation par module. Selon Android Developers Blog, de récentes améliorations ont réduit les temps de compilation mesurables.
Optimisation opérationnelle : compilation en arrière-plan et OTA
Après avoir défini les filtres, le passage à l’optimisation opérationnelle cible la compilation en arrière-plan et les mises à jour OTA. L’approche A/B et la compilation asynchrone réduisent l’impact sur l’utilisateur final.
Compilation background, profils et gains mesurables
Ce paragraphe explique comment la compilation en arrière-plan utilise des profils pour recompiler efficacement les méthodes chaudes. Selon Android Developers Blog, certaines actions ont donné jusqu’à dix-huit pour cent de gains sur le temps de compilation.
« Après l’intégration des scripts d’OTA, nos builds clients ont montré des démarrages plus constants et plus rapides. »
Sophie R.
Les paramètres dalvik.vm.bgdexopt.new-methods-percent et dalvik.vm.bgdexopt.new-classes-percent contrôlent le déclenchement de recompilation. Ces seuils permettent de limiter les recompilations inutiles en arrière-plan.
Cas pratiques, retours d’expérience et recommandations
Ce point présente recommandations pratiques issues d’expériences terrain et d’études comparatives. Selon Android Open Source Project, la gestion des ensembles CPU et du nombre de threads dex2oat évite des plantages et optimise le temps de compilation.
- Activer speed-profile pour applications persistantes
- Allouer threads dex2oat égaux aux cœurs sélectionnés
- Utiliser A/B OTA pour précompiler sans pénaliser l’utilisateur
« L’optimisation fine des flags a réduit nos temps de maintenance et amélioré la qualité perçue des apps. »
Jean P.
Pour les équipes de développement mobile, ces leviers permettent d’améliorer la performance perçue sans augmenter indéfiniment l’empreinte système. Tester différentes combinaisons de filtres et profils reste la méthode la plus sûre.
Source : Android Developers Blog, «18% Faster Compiles, 0% Compromises», Android Developers Blog, 2025 ; Android Open Source Project, «Configuring ART», Android Open Source Project, 2024 ; Wikipédia, «ART (Android)», Wikipédia, 2026.
