Le runtime ART est le moteur qui exécute la majorité des applications mobiles sur Android. Ses mises à jour via le Play Store ont permis d’améliorer la vitesse de lancement et la stabilité générale.
Ces gains techniques ont un impact concret sur le temps de démarrage des apps Android et sur la perception utilisateur. Les éléments clés suivent pour orienter les choix techniques et les tests pratiques.
Réduction notable du temps de compilation grâce à AOT et profilage JIT
Amélioration de la vitesse de lancement et fluidité d’exécution des apps
Optimisation mémoire et économie d’énergie pour applications mobiles et services
Mises à jour modulaires via Play Store sans mise à jour système complète
ART et runtime Android : impact sur le temps de compilation
Au vu des points clés, il faut examiner comment ART réduit concrètement le temps de compilation des applications. La combinaison de compilation anticipée AOT et du profilage JIT guide l’optimisation efficace.
Comprendre les artefacts produits par dex2oat et libart.so éclaire le choix des filtres de compilation. Cette connaissance conditionne la configuration opérationnelle visant à réduire l’impact perçu par l’utilisateur.
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
Guidage des méthodes chaudes vers AOT
Optimisent méthodes critiques sans recompilation complète
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
Comprendre les artefacts produits par dex2oat
Ce point précise le rôle des artefacts produits par le compilateur et le runtime. Les fichiers .art et .oat contiennent du code optimisé spécifique au matériel, utile au démarrage et à l’exécution.
Selon Android Open Source Project, la précompilation AOT diminue la charge au runtime en déplaçant le coût de compilation hors de l’exécution directe. Selon Android Developers Blog, ART 13 a montré jusqu’à trente pour cent d’amélioration du temps de démarrage sur certains appareils.
« J’ai observé un démarrage d’application plus rapide après l’activation du profilage speed-profile sur nos builds pilotes. »
Alice D.
Paramètres et flags dex2oat en pratique
Ce point relie les artefacts aux choix de flags et à l’affectation CPU pendant la compilation. Ajuster threads et affinité réduit la contention et accélère dex2oat durant les builds.
Selon Android Developers Blog, la configuration des threads et de l’affinité CPU évite des plantages et améliore les temps de compilation mesurables. Tester ces paramètres reste indispensable pour des builds destinés à la production.
« Nous avons choisi speed-profile pour certaines apps système et mesuré un compromis espace/temps favorable. »
Marc L.
A lire également :Le système de fichiers F2FS accélère l'écriture mémoire sous Android
Configurer ART pour réduire le temps de compilation des applications
Armé de la connaissance des artefacts, la configuration devient le levier suivant pour optimiser les builds. Les options dexpreopt et les filtres de compilation permettent des compromis mesurables entre espace et performance.
Selon Android Open Source Project, dexpreopt précompile les applications système lors de la création d’image, réduisant le travail au premier démarrage. Cette étape prépare le passage aux stratégies OTA et à la compilation asynchrone.
Choix de filtres de compilation :
verify vérification du bytecode sans compilation AOT
speed compilation AOT plus complète pour performance initiale
speed-profile compilation guidée par profil JIT puis AOT
everything compilation AOT exhaustive pour performance maximale
Options de dexpreopt et filtres de compilation
Ce volet examine les filtres officiels et leurs usages recommandés pour le développement mobile. Le choix entre verify, speed et speed-profile dépend des contraintes d’espace et d’exigence de démarrage.
Selon Wikipédia, ces filtres existent officiellement depuis Android 8 et restent pertinents en 2026 pour équilibrer empreinte système et amélioration performance. Les tests locaux valident toujours le meilleur compromis pour chaque build.
Filtre
Description
Usage recommandé
verify
Vérifie le bytecode sans compilation AOT
Images avec stockage restreint
speed
Compilation AOT plus complète
Composants 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
« Nous avons choisi speed-profile pour certaines apps système et mesuré un compromis espace/temps favorable. »
Ce point décrit la compilation en arrière-plan et les mises à jour OTA pour limiter l’impact utilisateur. L’approche A/B et la compilation asynchrone permettent de précompiler sans pénaliser l’expérience au premier lancement.
Selon Android Developers Blog, des actions sur les profils et l’OTA ont fourni des gains mesurables sur la constance des démarrages. Intégrer ces scripts dans le pipeline CI aide à maintenir la qualité perçue.
« Après l’intégration des scripts d’OTA, nos builds clients ont montré des démarrages plus constants et plus rapides. »
Sophie R.
Optimisation opérationnelle : compilation en arrière-plan et OTA
Au fur et à mesure que la configuration est stabilisée, l’optimisation opérationnelle devient prioritaire pour limiter l’impact utilisateur. Les profils background et les seuils de recompilation permettent d’automatiser la maintenance sans surcoût visible.
Les paramètres dalvik.vm.bgdexopt.* contrôlent le déclenchement de recompilation en arrière-plan et réduisent le travail inutile. Leur réglage fin permet d’équilibrer latence de compilation et disponibilité CPU pour l’utilisateur.
Réglages opérationnels recommandés :
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
Compilation background et profils de recompilation
Ce point porte sur les seuils et la logique derrière la recompilation en arrière-plan. Les variables percent déclenchent l’action uniquement lorsque le code nouveau justifie une recompilation ciblée.
Selon Android Developers Blog, certaines actions de background ont donné jusqu’à dix-huit pour cent de gains sur le temps de compilation mesurable. Cette approche limite le travail redondant tout en améliorant la performance perçue.
« L’optimisation fine des flags a réduit nos temps de maintenance et amélioré la qualité perçue des apps. »
Jean P.
Cas pratiques, retours d’expérience et recommandations
Ce point rassemble recommandations issues d’expériences terrain et d’études comparatives sur plusieurs devices. Tester différentes combinaisons de filtres et profils reste la méthode la plus sûre pour valider les gains.
Pour les équipes mobiles, activer speed-profile et allouer des threads cohérents apporte un bon rapport performance/empreinte. La mise en place d’OTAs A/B simplifie la distribution des optimisations sans compromettre l’expérience.
