Rozwiązywanie problemów z optymalizacją

Optymalizacje R8 aktualizują kod aplikacji, dlatego ważne jest, aby dokładnie przetestować jej działanie i upewnić się, że działa ona zgodnie z oczekiwaniami. W przypadku nieoczekiwanego zachowania skorzystaj z tej strony jako przewodnika, który pomoże Ci rozwiązać potencjalne problemy po optymalizacji. Więcej informacji o regułach, których możesz użyć do rozwiązywania problemów z optymalizacją, znajdziesz w artykule Rozwiązywanie problemów z optymalizacją za pomocą reguł.

Podczas rozwiązywania problemów skup się na tych sytuacjach:

  • Nadmierna optymalizacja prowadząca do awarii aplikacji: aplikacja ulega awarii, ponieważ R8 zoptymalizował zbyt dużo kodu.
  • Niejasna lub niewystarczająca optymalizacja: R8 nie zoptymalizował aplikacji w takim stopniu, jakiego oczekujesz, lub potrzebujesz dodatkowych wyjaśnień dotyczących optymalizacji.

Awarie aplikacji

Jeśli po zoptymalizowaniu aplikacji za pomocą R8 uległa ona awarii, zwykle jest to spowodowane uszkodzonym odbiciem. Aby zidentyfikować uszkodzone odbicie, postępuj zgodnie z tymi wskazówkami:

  • Obserwujesz wyjątek, który oznacza, że wskazana klasa, metoda lub pole są używane przez odbicie. Te wyjątki to zwykle jeden z tych błędów: ClassNotFoundException, NoSuchMethodException, NoSuchFieldException, NoClassDefFoundError, NoSuchMethodError, NoSuchFieldError.
  • Widzisz kod, który odwołuje się do odbicia za pomocą import kotlin.reflect.* lub import java.lang.reflect.*.
  • Obserwujesz konstruktor klasy używany w ten sposób: Something::class.constructors.
  • Widzisz Class.forName(...).

Rozwiązanie: dodaj regułę keep.

Jeśli odbicie jest wykonywane przez Twój kod, możesz dodać do niego adnotacje Jetpack Keep zamiast reguły keep. Sprawdzanie kodu za pomocą Jetpack Keep wykrywa też inne wywołania odbicia, które nie są oznaczone adnotacjami, co pomaga zapobiegać podobnym awariom.

Niejasna lub niewystarczająca optymalizacja

Reguły są stosowane zarówno w aplikacji, jak i w dołączonych bibliotekach, dlatego możesz potrzebować dodatkowych informacji o stosowanych regułach lub wyjaśnienia, dlaczego R8 zachował niektóre fragmenty kodu, które miały zostać zoptymalizowane.

  • Niejasności dotyczące stosowanych reguł: reguły z dołączonych bibliotek mają zastosowanie również do Twojej aplikacji, a opcje globalne z tych bibliotek są też propagowane do Twojej aplikacji, dlatego możesz nie mieć pewności, które reguły są stosowane.

    Rozwiązanie: sprawdź, które reguły są stosowane, wyświetlając raport wszystkich reguł, które R8 stosuje podczas tworzenia projektu. Ten raport znajdziesz w pliku ./app/build/outputs/mapping/configuration.txt. Zawiera on wszystkie scalone reguły z każdej biblioteki i modułu, które zostały użyte do skonfigurowania R8. Możesz go użyć do identyfikowania nieefektywnych reguł.

  • Zbyt dużo kodu jest zachowywane: optymalizacja R8 może zachować kod, który miał zostać usunięty.

    Rozwiązanie: użyj opcji konfiguracji -whyareyoukeeping, aby dowiedzieć się, dlaczego kod został zachowany. Dane wyjściowe zawierają ścieżkę od zachowanego kodu do jednego z punktów wejścia aplikacji. Więcej informacji znajdziesz w artykule -whyareyoukeeping.

  • Trudności z interpretacją oryginalnego zrzutu stosu: R8 zmienia kod na różne sposoby, przez co zrzut stosu nie odnosi się już do oryginalnego kodu. Mogą się na przykład zmienić numery wierszy oraz nazwy klas i metod.

    Rozwiązanie: od Androida Studio Otter 3 Feature Drop i AGP 9.0 Logcat automatycznie usuwa zaciemnienie zrzutów stosu. Jeśli jednak używasz starszej wersji Androida Studio, musisz ręcznie odzyskać oryginalny ślad stosu. Aby odzyskać oryginalny zrzut stosu, użyj narzędzia wiersza poleceń retrace, które jest dołączone do pakietu narzędzi wiersza poleceń.

    Aby użyć retrace, podaj poleceniu ścieżkę do pliku mapowania i pliku zrzutu stosu. Plik mapowania o nazwie mapping.txt jest automatycznie dołączany do pakietu Android App Bundle (AAB). Więcej informacji znajdziesz w dokumentacji retrace oraz w artykule w Centrum pomocy Konsoli Play o tym, jak usunąć zaciemnienie śladów stosu awarii. Jeśli używasz Konsoli Play i Firebase Crashlytics, użyj pliku mapping.txt z awariami, które usługa zbiera od użytkowników aplikacji. To polecenie pokazuje, jak uruchomić retrace z katalogu głównego projektu:

    $ANDROID_HOME/cmdline-tools/latest/bin/retrace app/build/outputs/mapping/$releaseVariant/mapping.txt trace.txt

Zgłaszanie błędów

Jeśli nie uda Ci się rozwiązać problemu z R8, zgłoś błąd.