Además de las reglas de conservación generales, los tipos de reglas de conservación adicionales y las opciones globales, puedes usar ciertas reglas para solucionar problemas relacionados con tu optimización.
-checkdiscard
La regla -checkdiscard te permite verificar si R8 descartó correctamente una clase o un miembro que esperabas que se quitaran. Si no se descarta la clase o el miembro especificados, la compilación fallará.
La sintaxis de -checkdiscard es la siguiente:
-checkdiscard <class_specification>
En el siguiente ejemplo, la compilación falla si se retiene el campo userId o el método setLabel() de la clase com.example.models.User:
-checkdiscard class com.example.models.User{
private java.lang.String userId;
public void setLabel(java.lang.String);
}
Es posible que el código de la clase siga presente en la app si sus métodos se insertaron en otras clases. Para asegurarte de que el código se haya quitado por completo y no solo se haya insertado en línea, agrega una regla correspondiente que impida que R8 realice optimizaciones en la clase de destino combinando -checkdiscard con una regla -keep,allowshrinking. Esto prohíbe optimizaciones como la combinación y la intercalación de clases. Si se aprueba la regla -checkdiscard, ninguno de los contenidos de las clases coincidentes estará en la app optimizada.
En el siguiente ejemplo, se demuestra este uso:
# 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
Usa la regla -whyareyoukeeping para determinar por qué R8 conservó una clase, un campo o un método específicos en la compilación de tu app. Un elemento se puede conservar por varios motivos. Sin embargo, esta regla solo proporciona el que explica la ruta más corta al elemento desde un elemento conservado. Si quitas esta ruta de acceso de tu código, es posible que sigas viendo el elemento retenido, pero por un motivo diferente.
Las posibles razones son las siguientes:
Una regla de conservación: La regla de conservación puede provenir de la app, de una biblioteca consumida o de reglas generadas por AAPT (Android Asset Packaging Tool).
Referencias transitivas desde código o recursos conservados: Si R8 conserva código o XML (como diseños), se conserva todo lo que haga referencia de forma estática.
La sintaxis es la siguiente:
-whyareyoukeeping <class_specification>
Por ejemplo:
-whyareyoukeeping class com.example.foo.MainActivity {
private void setLabel(...);
}
El resultado se imprime en la consola.
Si no tienes ninguna regla que conserve setLabel(), el resultado será el siguiente:
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 tienes una regla de conservación que segmenta setLabel(), el resultado es similar al siguiente:
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