Optymalizacje R8 aktualizują kod aplikacji, dlatego ważne jest, aby dokładnie przetestować jej działanie i upewnić się, że działa zgodnie z oczekiwaniami. W przypadku nieoczekiwanego zachowania skorzystaj z tej strony, aby rozwiązać potencjalne problemy po optymalizacji.
Podczas rozwiązywania problemów skup się na tych sytuacjach:
- Nadmierna optymalizacja powodująca awarie aplikacji: aplikacja ulega awarii, ponieważ R8 zoptymalizował zbyt dużo kodu.
- Niejasna lub niewystarczająca optymalizacja: R8 nie zoptymalizował Twojej aplikacji w takim stopniu, jak oczekiwałeś(-aś), 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 nieprawidłowym odbiciem. Aby zidentyfikować uszkodzone odbicie, postępuj zgodnie z tymi wskazówkami:
- Obserwujesz wyjątki, co zwykle oznacza, że wskazana klasa, metoda lub pole są używane przez odbicie.
Wyjątki te to zwykle:
ClassNotFoundException,NoSuchMethodException,NoSuchFieldException,NoClassDefFoundError,NoSuchMethodError,NoSuchFieldError. - Widzisz kod, który odwołuje się do odbicia za pomocą
import kotlin.reflect.*lubimport java.lang.reflect.*. - Widzisz, że konstruktor klasy jest używany w ten sposób:
Something::class.constructors. - Zobaczysz
Class.forName(...).
Rozwiązanie: dodaj regułę zachowywania.
Niejasna lub niewystarczająca optymalizacja
Reguły są stosowane w aplikacji, a także w dołączonych bibliotekach, więc możesz potrzebować dodatkowych informacji o stosowanych regułach lub wyjaśnienia, dlaczego R8 zachował niektóre sekcje kodu, które miały zostać zoptymalizowane.
Niejasności dotyczące stosowanych reguł: ponieważ 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, 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 ze wszystkimi regułami, które R8 stosuje podczas tworzenia projektu. Ten raport znajdziesz pod adresem
./app/build/outputs/mapping/configuration.txt. Ten raport zawiera wszystkie scalone reguły z każdej biblioteki i każdego modułu, które zostały użyte do skonfigurowania R8. Można go używać do identyfikowania nieefektywnych reguł.Zbyt dużo zachowanego kodu: optymalizacja R8 może zachować kod, który powinien 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 sekcji-whyareyoukeeping.Trudność w zrozumieniu oryginalnego śladu stosu: R8 zmienia kod na różne sposoby, przez co ślad stosu nie odnosi się już do oryginalnego kodu. Mogą się na przykład zmienić numery wierszy oraz nazwy klas i metod.
Rozwiązanie: począwszy od pakietu funkcji Android Studio Otter 3 i AGP 9.0, Logcat automatycznie usuwa zaciemnienie śladów stosu. Jeśli jednak używasz starszej wersji Androida Studio, musisz ręcznie odzyskać oryginalny ślad stosu. Aby odzyskać oryginalny ślad stosu, użyj narzędzia wiersza poleceń
retrace, które jest dołączone do pakietu narzędzi wiersza poleceń.Aby użyć polecenia
retrace, podaj ścieżkę do pliku mapowania i pliku śledzenia stosu. Plik mapowania o nazwiemapping.txtjest 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 odszyfrować ślady stosu błędów. Jeśli korzystasz z usług Play i Firebase Crashlytics, używaj plikumapping.txtz awariami, które usługa zbiera od użytkowników aplikacji. To polecenie pokazuje, jak uruchomićretracez katalogu głównego projektu:$ANDROID_HOME/cmdline-tools/latest/bin/retrace app/build/outputs/mapping/$releaseVariant/mapping.txt trace.txt
Zgłoś błędy
Jeśli nie możesz rozwiązać problemu z R8, zgłoś błąd.