Résoudre les problèmes d'optimisation

Étant donné que les optimisations de R8 modifient le code de votre application, il est important de tester son comportement de manière approfondie pour vous assurer qu'elle fonctionne comme prévu. En cas de comportement inattendu, utilisez cette page pour résoudre les problèmes potentiels après l'optimisation.

Lors du dépannage, concentrez-vous sur les situations suivantes :

  • L'optimisation excessive entraîne le plantage de l'application : votre application plante, car R8 a optimisé trop de code.
  • Optimisation peu claire ou insuffisante : R8 n'a pas optimisé votre application autant que vous l'espériez ou vous avez besoin d'explications supplémentaires sur les optimisations.

L'application plante

Si votre application a planté après avoir été optimisée avec R8, cela est généralement dû à une réflexion cassée. Pour identifier une réflexion cassée, suivez les consignes suivantes :

  • Vous observez une exception, ce qui signifie généralement que la classe, la méthode ou le champ indiqués sont utilisés par réflexion. Ces exceptions sont généralement l'une des suivantes : ClassNotFoundException, NoSuchMethodException, NoSuchFieldException, NoClassDefFoundError, NoSuchMethodError, NoSuchFieldError.
  • Vous voyez du code qui fait référence à la réflexion avec import kotlin.reflect.* ou import java.lang.reflect.*.
  • Vous observez un constructeur de classe utilisé comme suit : Something::class.constructors.
  • Vous voyez alors le message : Class.forName(...).

Solution : ajoutez une règle de conservation.

Optimisation peu claire ou insuffisante

Étant donné que les règles sont appliquées à partir de votre application, ainsi qu'aux bibliothèques incluses, vous aurez peut-être besoin de plus de clarté sur les règles appliquées ou d'une explication sur la raison pour laquelle R8 a conservé certaines sections de code que vous pensiez optimiser.

  • Ambiguïté concernant les règles appliquées : les règles des bibliothèques incluses s'appliquent également à votre application, et les options globales de ces bibliothèques se propagent également à votre application. Vous pouvez donc ne pas savoir quelles règles sont appliquées.

    Solution : Vérifiez les règles appliquées en consultant le rapport de toutes les règles appliquées par R8 lors de la compilation de votre projet. Vous trouverez ce rapport sur ./app/build/outputs/mapping/configuration.txt. Ce rapport contient toutes les règles fusionnées de chaque bibliothèque et module utilisés pour configurer R8. Il peut être utilisé pour identifier les règles inefficaces.

  • Trop de code conservé : l'optimisation de R8 peut conserver du code que vous pensiez supprimer.

    Solution : utilisez l'option de configuration -whyareyoukeeping pour comprendre pourquoi le code a été conservé. La sortie contient un chemin d'accès du code conservé à l'un des points d'entrée de votre application. Pour en savoir plus, consultez -whyareyoukeeping.

  • Difficulté à comprendre la trace de pile d'origine : R8 modifie le code de différentes manières, ce qui fait que la trace de pile ne fait plus référence au code d'origine. Par exemple, les numéros de ligne et les noms des classes et des méthodes peuvent changer.

    Solution : À partir de la mise à jour groupée d'Android Studio Otter 3 et d'AGP 9.0, Logcat désobfusque automatiquement les traces de pile. Toutefois, si vous utilisez une version antérieure d'Android Studio, vous devez récupérer manuellement la trace de pile d'origine. Pour récupérer la trace de pile d'origine, utilisez l'outil de ligne de commande retrace, qui est fourni avec le package Outils de ligne de commande.

    Pour utiliser retrace, fournissez à la commande le chemin d'accès à un fichier de mappage et à un fichier de trace de pile. Le fichier de mappage, appelé mapping.txt, est automatiquement fourni avec votre Android App Bundle (AAB). Pour en savoir plus, consultez la documentation retrace et l'article du centre d'aide de la Play Console qui explique comment désobscurcir les traces de la pile de plantage. Lorsque vous utilisez Play et Firebase Crashlytics, utilisez le fichier mapping.txt avec les plantages que le service collecte auprès des utilisateurs de l'application. La commande suivante montre comment exécuter retrace à partir de la racine de votre projet :

    $ANDROID_HOME/cmdline-tools/latest/bin/retrace app/build/outputs/mapping/$releaseVariant/mapping.txt trace.txt

Signaler des bugs

Si vous ne parvenez pas à résoudre un problème avec R8, signalez un bug.