R8 : qu'est-ce que c'est, fonctionnalités et comparaison avec ProGuard

Qu'est-ce que R8 ?

R8 est un programme de traitement et de transformation de bytecode développé par Google en remplacement de ProGuard dans l'écosystème Android. Contrairement à ProGuard, qui fonctionne comme un outil séparé au stade des fichiers class, R8 est intégré directement dans le compilateur DEX (D8/R8). Cela permet à R8 d'effectuer une analyse et une optimisation à un niveau plus profond, inaccessible aux outils externes.

Architecture de R8

R8 reçoit du bytecode Java sous forme de fichiers class ou d'archives JAR en entrée et le convertit en code DEX optimisé en un seul passage. L'optimiseur intégré de R8 effectue plus de 50 types différents de transformations — des simples (inline de constantes) aux complexes (analyse d'atteignabilité des types avec une précision au niveau du champ). Selon Google, l'architecture de R8 est spécialement conçue pour fonctionner en mode multithread, garantissant une vitesse de compilation élevée.

Historique de développement

R8 a été annoncé lors de Google I/O 2018 et inclus pour la première fois dans Android Gradle Plugin 3.4 (2019) en remplacement optionnel de ProGuard. Dans AGP 7.0, R8 est devenu l'outil par défaut pour tous les projets, et dans AGP 8.0 (2023), le support de ProGuard a été complètement supprimé du plugin. En 2025, R8 est le seul outil officiel d'obfuscation et d'optimisation pour Android recommandé par Google.

Fonctionnalités clés de R8

R8 offre aux développeurs un ensemble de capacités puissantes qui surpassent significativement ProGuard en efficacité. Examinons les principales.

Minification et compression de code

R8 effectue une analyse globale du code de l'application et de toutes ses dépendances, déterminant les classes et méthodes atteignables via un graphe d'appels à partir des points d'entrée. L'analyse de R8 est plus précise que celle de ProGuard grâce à l'accès à la représentation DEX du code. R8 peut supprimer non seulement des classes et méthodes entières, mais aussi des champs individuels qui ne sont jamais utilisés. Selon les tests de Google, R8 supprime en moyenne 15% de code en plus que ProGuard sur les mêmes projets.

Desugaring Java 8+

Le desugaring intégré est une fonctionnalité unique de R8 absente de ProGuard. R8 convertit automatiquement les expressions lambda, les références de méthodes, les interfaces avec méthodes default et try-with-resources de Java 8+ en code rétrocompatible fonctionnant sur tous les niveaux d'API Android. Cela évite au développeur d'ajouter une bibliothèque séparée desugar_jdk_libs et de configurer manuellement le desugaring.

Optimisation au niveau DEX

Puisque R8 voit le format DEX final, il peut effectuer des optimisations impossibles pour ProGuard. R8 fusionne les constantes de chaîne identiques, supprime les exceptions inutilisées, optimise les constructions switch et effectue un inline agressif avec réécriture du graphe d'appels. Ces optimisations non seulement réduisent la taille de l'APK, mais améliorent également les performances d'exécution du code sur ART.

// Activer R8 explicitement dans build.gradle (optionnel dans AGP 8.0+)
android {
    compileSdk 34
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile(
                'proguard-android-optimize.txt'
            ), 'proguard-rules.pro'
        }
    }
}

// gradle.properties — forcer l'activation de R8
android.enableR8.fullMode=true

Comparaison R8 vs ProGuard

Le choix entre R8 et ProGuard n'est pertinent que pour les projets utilisant AGP antérieur à 8.0. Pour comprendre les différences architecturales, examinons la comparaison par paramètres clés.

Taille finale de l'APK

Les tests de Google sur un échantillon de 100 applications populaires du Play Store ont montré que R8 réduit la taille de l'APK en moyenne de 18% par rapport à ProGuard. Dans certains projets avec une utilisation intensive de la syntaxe Java 8+ et de bibliothèques tierces, la différence atteignait 28%. Pour une application de 40 Mo, cela signifie une économie de 5 à 11 Mo, ce qui est critique pour les utilisateurs à bande passante limitée.

Compatibilité avec Kotlin

Les deux outils traitent correctement le code Kotlin, mais R8 optimise mieux les constructions spécifiques à Kotlin : lambdas, fonctions inline, coroutines et types null-safe. R8 comprend la sémantique des métadonnées Kotlin et peut supprimer en toute sécurité les vérifications null inutiles et intégrer les fonctions inline. Pour les projets Kotlin, R8 est l'outil recommandé par Google.

Configuration de R8 dans un projet Android

La configuration de R8 nécessite des modifications minimales de la configuration de compilation, car dans AGP 8.0+ l'outil est utilisé par défaut. Examinons les aspects clés de la configuration.

Mode complet de R8

R8 full mode (android.enableR8.fullMode=true) active des optimisations plus agressives qui offrent une réduction supplémentaire de 5 à 10% de la taille de l'APK. Dans ce mode, R8 effectue une analyse de code plus approfondie, supprimant les classes et méthodes que ProGuard considérerait comme atteignables. Le mode complet peut nécessiter des règles -keep supplémentaires pour les bibliothèques utilisant la réflexion.

# gradle.properties — activer le mode complet de R8
android.enableR8.fullMode=true

# Règles supplémentaires pour le mode complet
-keep class com.example.reflection.** { *; }
-keep class * implements android.os.Parcelable {
    public static final android.os.Parcelable$Creator *;
}

Débogage des problèmes R8

Lorsque des erreurs se produisent dans une compilation release avec R8, Google recommande : vérifier le fichier mapping pour la désobfuscation de la stack trace, désactiver temporairement fullMode pour isoler le problème, ajouter -whyareyoukeeping pour comprendre pourquoi une classe n'est pas supprimée et utiliser le flag --info de Gradle pour obtenir un journal détaillé du traitement R8.

Intégration CI/CD

Pour automatiser les compilations avec R8 dans CI/CD, il est important de conserver les fichiers mapping comme artefacts de compilation. Chaque fichier mapping doit être lié au numéro de version et à la variante de compilation. Google recommande d'archiver build/outputs/mapping/ avec APK/AAB dans le système de gestion des artefacts. Cela garantira la capacité de désobfusquer les crashes de n'importe quelle version de l'application.

Meilleures pratiques avec R8

Des années d'expérience avec R8 dans la communauté Android ont produit un ensemble de pratiques éprouvées qui aident à éviter les problèmes typiques et à tirer le meilleur parti de l'outil.

Adoption progressive

Lors de la migration de ProGuard vers R8, il est recommandé de commencer avec AGP 7.x, où R8 est activé par défaut mais fullMode est désactivé. Après avoir vérifié la stabilité de la compilation sur un ensemble complet d'appareils et de scénarios, fullMode peut être activé. Chaque étape nécessite de tester la compilation release sur des appareils physiques avec différentes versions d'Android.

Surveillance des fichiers mapping

Les fichiers mapping de R8 ont le même format que ProGuard mais contiennent plus d'informations grâce à une analyse plus détaillée. Google recommande : conserver les fichiers mapping indéfiniment — ils sont nécessaires pour désobfusquer les crashes des anciennes versions ; intégrer les fichiers mapping avec Firebase Crashlytics via un téléchargement automatique ; vérifier régulièrement que la désobfuscation dans la console Firebase restaure correctement les noms des classes.

Tests avec R8 full mode

Le mode complet de R8 peut supprimer du code considéré comme atteignable en mode standard. Domaines critiques pour les tests : écrans avec WebView (R8 peut supprimer les classes d'interface bridge), applications avec plugins via classLoader, bibliothèques d'analyse et de rapport de crashes et vues personnalisées dans les fichiers layout créées via inflate.

Surveillance de la taille de compilation

Google recommande de suivre la taille de l'APK après application de R8 dans chaque compilation. Utilisez APK Analyzer dans Android Studio pour comparer la taille des composants individuels : classes.dex, resources.arsc et bibliothèques de code natif. R8 peut affecter la taille des fichiers DEX de manière non linéaire — parfois l'optimisation agressive entraîne une augmentation de taille due à l'inline. Une surveillance régulière aide à détecter rapidement les anomalies et à ajuster les règles d'obfuscation.

// Exemple de classe conservée pour Firebase Crashlytics
@Keep
class CrashLogger {
    fun logException(e: Throwable) {
        FirebaseCrashlytics.getInstance().recordException(e)
    }
}

// rules.pro — conserver toutes les classes avec @Keep
// -keep @androidx.annotation.Keep class * { *; }