En plus des règles de conservation générales, des types de règles de conservation supplémentaires et des options globales, vous pouvez utiliser certaines règles pour résoudre les problèmes d'optimisation.
-checkdiscard
La règle -checkdiscard vous permet de vérifier si R8 a bien supprimé une classe ou un membre que vous pensiez voir disparaître. Si la classe ou le membre spécifié ne sont pas supprimés, la compilation échoue.
Voici la syntaxe à utiliser pour -checkdiscard :
-checkdiscard <class_specification>
Dans l'exemple suivant, la compilation échoue si le champ userId ou la méthode setLabel() de la classe com.example.models.User sont conservés :
-checkdiscard class com.example.models.User{
private java.lang.String userId;
public void setLabel(java.lang.String);
}
Le code de la classe peut toujours être présent dans l'application si ses méthodes ont été intégrées à d'autres classes. Pour vous assurer que le code a été complètement supprimé et pas seulement intégré, ajoutez une règle correspondante qui empêche R8 d'effectuer des optimisations sur la classe cible, en combinant -checkdiscard avec une règle -keep,allowshrinking. Cela interdit les optimisations telles que la fusion et l'intégration de classes. Si la règle -checkdiscard est respectée, aucun contenu des classes correspondantes ne se trouve dans l'application optimisée.
L'exemple suivant illustre cette utilisation :
# Either keep or remove the class, don't rename or otherwise optimize it
-keep,allowshrinking class com.example.foo { *; }
# Verify that the class and all of its fields and methods are removed.
-checkdiscard class com.example.foo
-whyareyoukeeping
Utilisez la règle -whyareyoukeeping pour déterminer pourquoi R8 a conservé une classe, un champ ou une méthode spécifiques dans le build de votre application. Un élément peut être conservé pour plusieurs raisons. Toutefois, cette règle ne fournit que celle qui explique le chemin le plus court vers l'élément à partir d'un élément conservé. Si vous supprimez ce chemin d'accès de votre code, il est possible que l'élément soit toujours conservé, mais pour une autre raison.
Voici les raisons possibles :
Règle de conservation : la règle de conservation peut provenir de l'application, d'une bibliothèque consommée ou de règles générées par AAPT (Android Asset Packaging Tool).
Références transitives à partir de code ou de ressources conservés : si du code ou du code XML (comme des mises en page) sont conservés par R8, tout ce qu'ils référencent de manière statique est conservé.
La syntaxe est la suivante :
-whyareyoukeeping <class_specification>
Exemple :
-whyareyoukeeping class com.example.foo.MainActivity {
private void setLabel(...);
}
La sortie est imprimée sur la console.
Si vous n'avez aucune règle de conservation pour setLabel(), le résultat est le suivant :
com.example.foo.MainActivity
|- is referenced in keep rule:
| /app/build/intermediates/aapt_proguard_file/release/processReleaseResources/aapt_rules.txt:4:1
Nothing is keeping void com.example.foo.MainActivity.setLabel()
Si vous avez une règle de conservation ciblant setLabel(), le résultat ressemble à ce qui suit :
com.example.foo.MainActivity
|- is referenced in keep rule:
| /app/proguard-rules.pro:23:1
void com.example.foo.MainActivity.setLabel()
|- is referenced in keep rule:
| /app/proguard-rules.pro:23:1