DEX : qu'est-ce que c'est, structure et principe de fonctionnement du bytecode

Qu'est-ce que DEX et pourquoi en a-t-on besoin

DEX (Dalvik Executable) est un format de bytecode conçu spécialement pour les appareils mobiles Android. Contrairement au bytecode Java standard (fichiers .class), DEX est optimisé pour les ressources limitées : moins de mémoire, taille réduite et chargement de classes plus rapide.

De Java à DEX

Le code source en Java ou Kotlin est compilé par javac/kotlinc en fichiers .class standard (bytecode Java). Ensuite, l'outil d8 (ou précédemment dx) convertit les .class en un ou plusieurs fichiers DEX. Cette conversion n'est pas un simple réempaquetage — d8 effectue des optimisations : fusion des pools de constantes, réécriture des instructions en architecture à registres et suppression des données en double.

Caractéristiques architecturales

DEX utilise une architecture basée sur les registres (contrairement à la JVM basée sur la pile). Chaque méthode possède un nombre fixe de registres (jusqu'à 65536). Les instructions DEX sont plus courtes — en moyenne 2 octets contre 1 à 4 octets dans la JVM. Cela produit un code plus compact : une application typique passe de 10 à 15 Mo de .class à 4 à 6 Mo de .dex.

Structure du fichier DEX : sections et en-tête

Un fichier DEX a une structure binaire strictement définie. Chaque fichier commence par un en-tête et contient plusieurs sections qui se référencent mutuellement via des décalages.

En-tête DEX

Le nombre magique de DEX est `dex\n035\0` (version 035). Autres versions : 036, 037, 038 (pour Android 8.0+). L'en-tête fait 0x70 octets et contient une somme de contrôle SHA-1 et les décalages de toutes les sections. La validation de l'en-tête est la première étape lors du chargement d'un DEX par la machine virtuelle.

Pools de constantes

string_ids, type_ids, proto_ids, field_ids, method_ids — ce sont des tables indexées. Au lieu de stocker les noms complets dans le code de la méthode, un index de 4 octets est utilisé. C'est une optimisation clé : si une classe est mentionnée 100 fois, son nom est stocké une fois dans string_ids. dex2oat optimise davantage ces tables lors de la compilation ART.

Processus de compilation de Java et Kotlin en DEX

Le processus de conversion du code source en DEX comprend plusieurs étapes. La chaîne d'outils moderne utilise le compilateur D8, qui a remplacé DX en 2018 avec Android Gradle Plugin 3.2.

Étape 1 : Compilation en .class

javac (pour Java) ou kotlinc (pour Kotlin) compile le code source en fichiers .class. Chaque classe est un fichier .class séparé en bytecode Java. À cette étape, la vérification des types, la génération de méthodes pont et l'inlining de constantes sont effectuées.

Étape 2 : Compilation D8

D8 prend tous les fichiers .class et les transforme en bytecode DEX. D8 effectue plusieurs optimisations : suppression des arguments de méthodes inutilisés, fusion des pools de constantes de différents fichiers .class en un seul pool global DEX et conversion des instructions de pile JVM en instructions de registre Dalvik.

// Code source Kotlin
data class User(
    val name: String,
    val email: String
)

fun greet(user: User): String {
    return "Hello, ${user.name}!"
}

Après la compilation D8, ce code se transforme en instructions DEX compactes : const-string pour charger les chaînes, iget-object pour accéder au champ d'un objet, invoke-virtual pour appeler StringBuilder.append.

D8 vs DX

D8 est 2 à 3 fois plus rapide que DX, génère un DEX plus compact (5 à 10% plus petit) et optimise mieux les constructions spécifiques à Kotlin (fonctions inline, lambdas). DX a été déclaré obsolète en 2018 et supprimé d'Android Gradle Plugin 8.0.

Dalvik vs ART : comment l'exécution de DEX a changé

L'exécution du code DEX dans Android a traversé deux phases : la machine virtuelle Dalvik originale (Android 2.2–4.4) et Android Runtime ART (Android 5.0+). La différence d'approche de compilation est fondamentale.

Dalvik VM : compilation JIT

Dalvik utilisait la compilation Just-In-Time (JIT) : le bytecode DEX était interprété et les méthodes fréquemment appelées étaient compilées en code natif à la volée. Avantage — installation rapide. Inconvénient — démarrage plus lent et consommation constante de CPU pour le JIT.

ART : compilation AOT

ART (Android Runtime) compile DEX en code natif lors de l'installation de l'application via dex2oat. C'est une approche Ahead-Of-Time (AOT) : l'installation est plus longue, mais le démarrage est plus rapide et la consommation d'énergie est moindre. Depuis Android 7.0, ART utilise une approche hybride — AOT + JIT + optimisation guidée par profil.

dex2oat : conversion lors de l'installation

L'outil dex2oat s'exécute lors de l'installation ou de la mise à jour d'une application. Il compile DEX en un fichier ELF avec du code natif pour l'architecture de l'appareil. Le résultat — des fichiers .oat et .art dans le répertoire /data/dalvik-cache/. Google améliore constamment dex2oat : sur Android 14, des optimisations pour les appareils pliables ont été ajoutées.

Multidex : dépassement de la limite des 64K méthodes

La limite de 65536 méthodes par fichier DEX est un héritage de l'architecture Dalvik. Le champ method_ids dans l'en-tête DEX occupe 4 octets, donnant un maximum de 2^16 = 65536 références uniques. Les applications modernes avec Google Play Services, Firebase et d'autres SDK dépassent facilement cette limite.

Mécanisme Multidex

Multidex est un mécanisme de division du code en plusieurs fichiers DEX. Le classes.dex principal contient les points d'entrée (classe Application, Activity principale), les autres sont classes2.dex, classes3.dex, etc. Au démarrage, les classes des DEX supplémentaires sont chargées via DexClassLoader.

// build.gradle.kts — activation du multidex
android {
    defaultConfig {
        multiDexEnabled = true
    }
}

// Classe Application avec support multidex
class MyApp : Application() {
    override fun attachBaseContext(base: Context) {
        super.attachBaseContext(base)
        MultiDex.install(this)
    }
}

Problèmes de Multidex

Le chargement de DEX supplémentaires lors du démarrage de l'application peut provoquer un ANR (Application Not Responding) sur les appareils avec Android antérieur à 5.0. Recommandation — utiliser multidex uniquement en cas de nécessité et minimiser les dépendances pour ne pas dépasser la limite.

Optimisation DEX : ProGuard, R8 et obscurcissement

L'optimisation de DEX est une étape standard dans la construction d'une application Android de version. Les outils R8 et ProGuard réduisent la taille du DEX, obscurcissent le code et suppriment les classes inutilisées.

R8 vs ProGuard

R8 est le successeur de ProGuard, intégré à Android Gradle Plugin depuis 2019. R8 effectue la minification, l'obscurcissement et l'optimisation en une seule passe, alors que ProGuard nécessitait deux étapes : ProGuard → D8. ProGuard est toujours pris en charge, mais Google recommande R8 pour les nouveaux projets.

R8 supprime les classes, méthodes et champs inutilisés, les renomme avec des noms courts (a, b, c), intègre les fonctions inline et élimine le code mort. Le résultat — le DEX est réduit de 20 à 40% sans perte de fonctionnalité.

Règles R8

La configuration de R8 est spécifiée dans le fichier proguard-rules.pro. Le développeur peut indiquer quelles classes ne peuvent pas être renommées (par exemple, pour la réflexion ou la sérialisation Gson). Firebase et d'autres SDK fournissent leurs propres règles dans leurs dépendances.

Décompilation DEX : outils et protection

DEX peut être décompilé en code Java. C'est une question de sécurité clé pour les applications Android : sans obscurcissement, le code est restauré à un niveau proche de l'original.

Outils de décompilation

JADX est le décompilateur DEX vers Java le plus populaire. Il restaure les noms de classes, méthodes, champs et la majeure partie de la logique. apktool décompile DEX en code smali (assembleur Dalvik) — une représentation de bas niveau proche des instructions originales. Bytecode Viewer combine plusieurs décompilateurs dans une interface unique.

Méthodes de protection

L'obscurcissement avec R8/ProGuard est la première ligne de défense : les noms de classes et de méthodes deviennent illisibles. DexGuard est un outil commercial avec des méthodes supplémentaires : chiffrement des chaînes, vérification d'intégrité, anti-altération. L'obscurcissement du flux de contrôle (O-LLVM) modifie la structure du code tout en préservant sa fonctionnalité, rendant l'analyse beaucoup plus difficile.