Поскольку оптимизации R8 обновляют код вашего приложения, важно тщательно протестировать его поведение, чтобы убедиться, что оно работает так, как ожидается. В случае непредвиденного поведения используйте эту страницу в качестве руководства по устранению потенциальных проблем после оптимизации.
При устранении неполадок обратите внимание на следующие ситуации:
- Избыточная оптимизация приводит к сбоям приложения : ваше приложение аварийно завершает работу, потому что R8 оптимизировал слишком много кода.
- Неясная или недостаточная оптимизация : R8 не оптимизировал ваше приложение так, как вы ожидали, или вам нужны дополнительные объяснения по поводу оптимизаций.
Сбои приложения
Если ваше приложение вылетает после оптимизации с помощью R8, это обычно связано с нарушением рефлексии. Чтобы определить нарушение рефлексии, следуйте следующим рекомендациям:
- Вы наблюдаете исключение, которое обычно означает, что указанный класс, метод или поле используется через рефлексию. Обычно это одно из следующих исключений:
ClassNotFoundException,NoSuchMethodException,NoSuchFieldException,NoClassDefFoundError,NoSuchMethodError,NoSuchFieldError. - Вы видите код, который ссылается на отражение с помощью
import kotlin.reflect.*илиimport java.lang.reflect.*. - Вы видите, что конструктор класса используется следующим образом:
Something::class.constructors. - Вы видите
Class.forName(...).
Решение : добавьте правило сохранения .
Неясная или недостаточная оптимизация
Поскольку правила применяются из вашего приложения, а также из включенных библиотек, вам может потребоваться дополнительная информация о применяемых правилах или объяснение того, почему R8 сохранил определенные разделы кода, которые, как вы ожидали, будут оптимизированы.
Неопределенность в отношении применяемых правил : поскольку правила из включенных библиотек также применяются к вашему приложению, а глобальные параметры из этих библиотек также распространяются на ваше приложение, вы можете быть не уверены в том, какие правила применяются.
Решение : Проверьте, какие правила применяются, просмотрев отчёт обо всех правилах, применяемых R8 при сборке вашего проекта. Этот отчёт можно найти по адресу
./app/build/outputs/mapping/configuration.txt. Этот отчёт содержит все объединённые правила из каждой библиотеки и модуля, использованных для настройки R8, и может быть использован для выявления неэффективных правил.Слишком много сохраняемого кода : оптимизация R8 может сохранить код, который вы ожидали удалить.
Решение : используйте параметр конфигурации
-whyareyoukeeping, чтобы понять, почему код был сохранён. Вывод содержит путь от сохранённого кода к одной из точек входа вашего приложения. Подробнее см. в разделе-whyareyoukeeping.Сложность понимания исходного стека трассировки : R8 изменяет код различными способами, из-за чего стек трассировки больше не ссылается на исходный код. Например, могут измениться номера строк, имена классов и методов.
Решение : Начиная с Android Studio Otter 3 Feature Drop и AGP 9.0, Logcat автоматически деобфусцирует трассировки стека. Однако, если вы используете более раннюю версию Android Studio, вам необходимо вручную восстановить исходную трассировку стека. Для этого используйте утилиту командной строки
retrace, входящую в пакет инструментов командной строки .Чтобы использовать
retrace, укажите команде путь к файлу сопоставления и файлу трассировки стека. Файл сопоставления, называемыйmapping.txt, автоматически добавляется в ваш Android App Bundle (AAB). Подробнее см. документацию по retrace и статью в справочном центре Play Console о том, как деобфусцировать трассировки стека сбоев . При использовании Play и Firebase Crashlytics используйте файлmapping.txtс данными о сбоях, которые сервис собирает у пользователей приложения. Следующая команда показывает, как запуститьretraceиз корневого каталога вашего проекта:$ANDROID_HOME/cmdline-tools/latest/bin/retrace app/build/outputs/mapping/$releaseVariant/mapping.txt trace.txt
Сообщить об ошибках
Если вы не можете решить проблему с R8, сообщите об ошибке .