Como as otimizações do R8 atualizam o código do app, é importante testar o comportamento dele para garantir que esteja funcionando como esperado. Em caso de comportamento inesperado, use esta página como um guia para solucionar possíveis problemas após a otimização.
Ao resolver problemas, concentre-se nas seguintes situações:
- Otimização excessiva que causa falhas no app: o app falha porque o R8 otimizou muito código.
- Otimização pouco clara ou insuficiente: o R8 não otimizou seu app tanto quanto você esperava ou você precisa de mais explicações sobre as otimizações.
Falhas no app
Se o app falhar depois de ser otimizado com o R8, geralmente é devido a uma reflexão corrompida. Para identificar reflexos quebrados, siga estas diretrizes:
- Você observa uma exceção, o que geralmente significa que a classe, o método ou o campo indicado está sendo usado por reflexão.
Essas exceções geralmente são uma das seguintes:
ClassNotFoundException,NoSuchMethodException,NoSuchFieldException,NoClassDefFoundError,NoSuchMethodError,NoSuchFieldError. - Você vê um código que faz referência à reflexão com
import kotlin.reflect.*ouimport java.lang.reflect.*. - Você observa um construtor de classe sendo usado da seguinte maneira:
Something::class.constructors. - Você vai ver
Class.forName(...).
Solução: adicione uma regra de permanência.
Otimização confusa ou insuficiente
Como as regras são aplicadas pelo app e pelas bibliotecas incluídas, talvez você precise de mais informações sobre as regras aplicadas ou de uma explicação sobre por que o R8 manteve determinadas seções de código que você esperava que fossem otimizadas.
Ambiguidade sobre as regras aplicadas: como as regras das bibliotecas incluídas também se aplicam ao seu app, e as opções globais dessas bibliotecas também são propagadas para o app, talvez você não saiba quais regras são aplicadas.
Solução: verifique quais regras são aplicadas consultando o relatório de todas as regras que o R8 aplica ao criar seu projeto. Você pode encontrar esse relatório em
./app/build/outputs/mapping/configuration.txt. Esse relatório contém todas as regras mescladas de cada biblioteca e módulo usados para configurar o R8 e pode ser usado para identificar regras ineficientes.Excesso de código mantido: a otimização do R8 pode reter código que você esperava que fosse removido.
Solução: use a opção de configuração
-whyareyoukeepingpara entender por que o código foi mantido. A saída contém um caminho do código mantido para um dos pontos de entrada do app. Para mais informações, consulte-whyareyoukeeping.Dificuldade em entender o stack trace original: o R8 muda o código de várias maneiras, fazendo com que o stack trace não se refira mais ao código original. Por exemplo, os números de linha e os nomes de classes e métodos podem mudar.
Solução: a partir do lançamento de recursos 3 do Android Studio Otter e do AGP 9.0, o Logcat desofusca automaticamente os rastreamentos de pilha. No entanto, se você estiver usando uma versão anterior do Android Studio, será necessário recuperar manualmente o rastreamento de pilha original. Para recuperar o stack trace original, use a ferramenta de linha de comando
retrace, que faz parte do pacote ferramentas de linha de comando.Para usar
retrace, forneça o comando com o caminho para um arquivo de mapeamento e um arquivo de rastreamento de pilha. O arquivo de mapeamento, chamadomapping.txt, é agrupado automaticamente com o Android App Bundle (AAB). Para mais detalhes, consulte a documentação do retrace e o artigo da Central de Ajuda do Play Console sobre como desofuscar stack traces de falhas. Ao usar o Play e o Firebase Crashlytics, use o arquivomapping.txtcom as falhas que o serviço coleta dos usuários do app. O comando a seguir mostra como executarretracena raiz do seu projeto:$ANDROID_HOME/cmdline-tools/latest/bin/retrace app/build/outputs/mapping/$releaseVariant/mapping.txt trace.txt
Informar bugs
Se não for possível resolver um problema com o R8, informe um bug.