Résoudre les problèmes d'optimisation

Étant donné que les optimisations de R8 mettent à jour le code de votre application, il est important de tester rigoureusement son comportement pour vous assurer qu'elle fonctionne comme prévu. En cas de comportement inattendu, utilisez cette page comme guide pour résoudre les problèmes potentiels après l'optimisation. Pour en savoir plus sur les règles que vous pouvez utiliser pour résoudre les problèmes d'optimisation, consultez Utiliser des règles pour résoudre les problèmes d'optimisation.

Lors de la résolution des problèmes, concentrez-vous sur les situations suivantes :

  • Sur-optimisation entraînant des plantages 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 prévu 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 interrompue. Pour identifier une réflexion interrompue, suivez les consignes ci-dessous :

  • Vous observez une exception qui signifie que la classe, la méthode ou le champ indiqué est utilisé 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 l'utilisation d'un constructeur de classe comme suit : Something::class.constructors.
  • Vous voyez Class.forName(...).

Solution : ajoutez une règle de conservation.

Si votre propre code effectue la réflexion, vous pouvez l'annoter avec des annotations Jetpack Keep au lieu d'ajouter une règle de conservation. Les vérifications lint Jetpack Keep signalent également d'autres appels réflexifs qui ne sont pas annotés, ce qui vous aide à éviter des plantages similaires.

Optimisation peu claire ou insuffisante

Étant donné que les règles sont appliquées à partir de votre application, ainsi que des bibliothèques incluses, vous devrez peut-être obtenir des informations supplémentaires sur les règles appliquées ou une explication sur la raison pour laquelle R8 a conservé certaines sections de code que vous vous attendiez à optimiser.

  • Ambiguïté concernant les règles appliquées : étant donné que les règles des bibliothèques incluses s'appliquent également à votre application et que les options globales de ces bibliothèques se propagent également à votre application, vous ne savez peut-être pas 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 dans ./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, et peut être utilisé pour identifier les règles inefficaces.

  • Trop de code conservé : l'optimisation de R8 peut conserver du code que vous vous attendiez à 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 la pile d'origine : R8 modifie le code de différentes manières, ce qui fait que la trace de la 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 d'Android Studio Otter 3 Feature Drop et AGP 9.0, Logcat désactive automatiquement le désobscurcissement des traces de la pile. Toutefois, si vous utilisez une version antérieure d'Android Studio, vous devez récupérer manuellement la trace de la pile d'origine. Pour récupérer la trace de la pile d'origine, utilisez l' retrace outil de ligne de commande, qui fait partie du package d' outils de ligne de commande.

    Pour utiliser retrace, fournissez à la commande le chemin d'accès à un fichier de mise en correspondance et à un fichier de trace de la pile. Le fichier de mappage, appelé mapping.txt, est automatiquement inclus dans votre Android App Bundle (AAB). Pour en savoir plus, consultez la documentation retrace et l'article du Centre d'aide Play Console sur la désobscurcissement des 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.