Neben den allgemeinen Aufbewahrungsregeln, zusätzlichen Aufbewahrungsregeltypen und globalen Optionen können Sie bestimmte Regeln verwenden, um Probleme bei der Optimierung zu beheben.
-checkdiscard
Mit der Regel -checkdiscard können Sie prüfen, ob R8 eine Klasse oder ein Mitglied, das Sie entfernen wollten, erfolgreich verworfen hat. Wenn die angegebene Klasse oder das angegebene Element nicht verworfen wird, schlägt der Build fehl.
Die Syntax für -checkdiscard lautet so:
-checkdiscard <class_specification>
Im folgenden Beispiel schlägt der Build fehl, wenn entweder das Feld userId oder die Methode setLabel() aus der Klasse com.example.models.User beibehalten wird:
-checkdiscard class com.example.models.User{
private java.lang.String userId;
public void setLabel(java.lang.String);
}
Der Code der Klasse ist möglicherweise weiterhin in der App vorhanden, wenn die Methoden in andere Klassen inline eingefügt wurden. Damit der Code vollständig entfernt und nicht nur inline eingefügt wird, fügen Sie eine entsprechende Regel hinzu, die verhindert, dass R8 Optimierungen für die Zielklasse ausführt. Kombinieren Sie dazu -checkdiscard mit einer -keep,allowshrinking-Regel. Dadurch werden Optimierungen wie das Zusammenführen von Klassen und das Inlining verhindert. Wenn die -checkdiscard-Regel erfüllt ist, sind keine Inhalte aus den übereinstimmenden Klassen in der optimierten App enthalten.
Das folgende Beispiel veranschaulicht diese Verwendung:
# 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
Mit der Regel -whyareyoukeeping können Sie herausfinden, warum R8 eine bestimmte Klasse, ein bestimmtes Feld oder eine bestimmte Methode im Build Ihrer App beibehalten hat. Ein Element kann aus mehreren Gründen aufbewahrt werden. Diese Regel gibt jedoch nur den Grund an, der den kürzesten Pfad zu dem Element von einem aufbewahrten Element aus erklärt. Wenn Sie diesen Pfad aus Ihrem Code entfernen, wird der Artikel möglicherweise aus einem anderen Grund beibehalten.
Mögliche Gründe:
Eine Keep-Regel: Die Keep-Regel kann aus der App, einer verwendeten Bibliothek oder von AAPT (Android Asset Packaging Tool) generierten Regeln stammen.
Transitive Referenzen aus beibehaltenem Code oder beibehaltenen Ressourcen: Wenn Code oder XML (z. B. Layouts) von R8 beibehalten wird, wird alles, worauf statisch verwiesen wird, ebenfalls beibehalten.
Die Syntax lautet:
-whyareyoukeeping <class_specification>
Beispiel:
-whyareyoukeeping class com.example.foo.MainActivity {
private void setLabel(...);
}
Die Ausgabe wird in der Konsole angezeigt.
Wenn Sie keine Regel haben, die setLabel() beibehält, sieht die Ausgabe so aus:
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()
Wenn Sie eine Aufbewahrungsregel für setLabel() haben, sieht die Ausgabe in etwa so aus:
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