Tworzę aplikację i za każdym razem, gdy ją uruchamiam, pojawia się komunikat:
Niestety MyApp przestał działać.
Co mogę zrobić, aby to rozwiązać?
O tym pytaniu - oczywiście zainspirowanym przez Co to jest ślad stosu i jak mogę go użyć do debugowania błędów aplikacji? , istnieje wiele pytań stwierdzających, że ich aplikacja uległa awarii, bez dalszych szczegółów. To pytanie ma na celu poinstruowanie początkujących programistów Androida, jak samodzielnie rozwiązać problemy lub zadać właściwe pytania.
Odpowiedzi:
Ta odpowiedź opisuje proces pobierania śladu stosu. Masz już ślad stosu? Przeczytaj o śladach stosu w „ Co to jest ślad stosu i jak mogę go użyć do debugowania błędów aplikacji? ”
Problem
Twoja aplikacja
RuntimeException
została zakończona, ponieważ został wyrzucony nieprzechwycony .Najczęstszym z nich jest
NullPointerException
.Jak to rozwiązać?
Za każdym razem, gdy następuje awaria aplikacji Android (lub dowolnej innej aplikacji Java),
Stack trace
do konsoli zapisywany jest znak a (w tym przypadku logcat). Ten ślad stosu zawiera istotne informacje do rozwiązania problemu.Android Studio
W dolnym pasku okna kliknij
Logcat
przycisk. Możesz też nacisnąć alt+ 6. Upewnij się, że emulator lub urządzenie jest wybrane wDevices
panelu. Następnie spróbuj znaleźć ślad stosu, który jest pokazany na czerwono. W logcat może być zalogowanych wiele rzeczy, więc może być konieczne przewinięcie. Łatwym sposobem na znalezienie śladu stosu jest wyczyszczenie logcat (za pomocą kosza po prawej stronie) i ponowne uruchomienie aplikacji.Znalazłem ślad stosu, co teraz?
Tak! Jesteś w połowie drogi do rozwiązania problemu.
Musisz tylko dowiedzieć się, co dokładnie spowodowało awarię aplikacji, analizując ślad stosu.
Przeczytaj o śladach stosu w „ Co to jest ślad stosu i jak mogę go użyć do debugowania błędów aplikacji? ”
Nadal nie mogę rozwiązać mojego problemu!
Jeśli znalazłeś swój
Exception
i linię, w której wystąpił, i nadal nie możesz dowiedzieć się, jak to naprawić, nie wahaj się zadać pytania na StackOverflow.Staraj się być jak najbardziej zwięzły: opublikuj ślad stosu i odpowiedni kod (np. Kilka linii do linii, która rzuciła
Exception
).źródło
Android > Devices|Logcat
i dodać nowy filtr ( i.imgur.com/145dtkx.png ), i przefiltrować goby Log Message
tutaj, możesz umieścićFATAL EXCEPTION
( i.imgur.com/HpELhaU .png ), dzięki czemu w tym polu możesz przeczytać wszystkieExceptions
wyrzucone przez twoją aplikację. Dzięki temu nie musisz wyczyścić logcata i ponownie wykonać awarii. Myślę, że Android Studio też ma tę opcję.Można użyć narzędzia ADB Google , aby
Logcat file
przeanalizować problem.otwórz
logcat.txt
plik i wyszukaj nazwę swojej aplikacji. Powinny być informacje o przyczynie niepowodzenia, numer linii, nazwa klasy itp.źródło
-d
, w przeciwnym razie będziesz musiał przejść do ctrl-C, aby wyjść z logcat. Robięadb logcat -v time -d > filename.txt
Najpierw sprawdzasz, w którym momencie aplikacja się zawiesiła (
Unfortunately, MyApp has stopped.
). W tym celu możesz użyćLog.e("TAG", "Message");
, korzystając z tego wiersza, możesz zobaczyć, jak aplikacja loguje się do logcat.Następnie dowiesz się, w którym momencie Twoja aplikacja została zatrzymana, a rozwiązanie tego problemu jest bardzo łatwe.
źródło
Wystarczy sprawdzić błąd w logu cat.
Dostajesz opcję dziennika kota z zaćmienia:
Log cat zawiera błąd.
W przeciwnym razie możesz również sprawdzić błąd, uruchamiając aplikację w trybie debugowania. Najpierw ustaw punkt przerwania, wykonując:
źródło
Uwaga: w tej odpowiedzi jest używany Android Studio 2.2.2
Uwaga 2: Rozważam, że Twoje urządzenie zostało pomyślnie podłączone.
Pierwszą rzeczą, którą robisz po awarii aplikacji, jest zajrzenie do LogCat, na dole Android Studio znajduje się pasek narzędzi z listą menu:
Kliknij „Android Monitor” (ten, który podkreśliłem na obrazku powyżej.)
Teraz otrzymasz coś takiego:
Zmień „
Verbose
” na „Error
”. Teraz będą wyświetlane tylko zarejestrowane błędy. Nie martw się teraz wszystkimi tymi błędami (jeśli je masz).Ok. Teraz zrób to, co zrobiłeś, aby zawiesić aplikację. Po awarii aplikacji przejdź do logcat. Powinieneś znaleźć nowy dziennik awarii, który ma wiele
at:x.x.x
: iCaused by: TrumpIsPresidentException
na przykład. Przejdź do tegoCaused by:
oświadczenia w logcat.Oprócz tego
Caused By:
powinien istnieć wyjątek. W moim przypadku jest toRuntimeException
a pod nim powinna znajdować się linia zawierająca niebieski link, taki jak:Jeśli to
Caused by:
NIE MA gdzieś pod nim linii z niebieskim tekstem, poszukaj innej,Caused by:
która ma.Kliknij ten niebieski link . Powinien Cię zabrać tam, gdzie wystąpił problem. W moim przypadku było to spowodowane tym wierszem:
Więc teraz wiem, dlaczego się zawiesza. To dlatego, że sam rzucam wyjątek. To był oczywisty błąd .
Powiedzmy jednak, że dostałem kolejny błąd:
Sprawdziłem logcat, kliknąłem niebieski link, który mi dał, i zabrałem mnie tutaj:
Więc teraz chcę debugować. Zgodnie z tym pytaniem StackOverflow NullPointerException mówi, że coś jest
null
.Dowiedzmy się, co jest zerowe . Istnieją dwie możliwości. Albo
mTextView
jest zerowy, albomyString
jest zerowy. Aby się dowiedzieć, przedmTextView.setText(mString)
linią dodaję te dwie linie:Teraz, podobnie jak poprzednio (zmieniliśmy Verose na Error), chcemy zmienić „Error” na „Debug”. Ponieważ logujemy się przez debugowanie. Oto wszystkie metody dziennika:
Odkąd użyliśmy
Log.d
, sprawdzamy w Debugowaniu. Dlatego zmieniliśmy to na debugowanie.Powiadomienie
Log.d
ma pierwszy parametr, w naszym przypadku „AppDebug”. Kliknij menu „Brak filtrów” w prawym górnym rogu logcat. Wybierz „Edytuj konfigurację filtra”, nadaj nazwę swojemu filtrowi, aw „Log Tag” wpisz „App Debug”. Kliknij OK". Teraz powinieneś zobaczyć dwie linie w logcat:Teraz wiemy, że mTextView ma wartość NULL.
Obserwuję mój kod, teraz coś zauważam.
Mam
private TextView mTextView
zadeklarowane na szczycie mojej klasy. Ale nie definiuję tego.Zasadniczo zapomniałem zrobić to w mojej funkcji onCreate ():
Dlatego TO
mTextView
jest zero, ponieważ zapomniałem powiedzieć mojej aplikacji, co to jest. Dodam więc ten wiersz, uruchomię aplikację, a teraz aplikacja nie ulega awarii.źródło
To okienko wyskakujące pokazuje się tylko wtedy, gdy w kodzie pojawia się krytyczny wyjątek, który zatrzymuje działanie aplikacji. To może być żadnego wyjątku
NullPointerException
,OutOfMemoryException
etc.Najlepszym sposobem sprawdzenia jest Logcat, jeśli nadal rozwijasz aplikację w Android Studio, co jest szybkim sposobem na odczytanie śladu stosu i sprawdzenie przyczyny aplikacji.
Jeśli Twoja aplikacja jest już aktywna, nie możesz użyć logcat . W tym celu możesz wdrożyć
Crashlytics
raporty o błędach dotyczące każdego wyjątku, który wystąpi.źródło
Sprawdź swoją
Logcat
wiadomość i zobacz swójManifest
plik. Powinno być czegoś brakuje, np. OkreślenieActivity,
uprawnień użytkownika itp.źródło
Możesz użyć dowolnego z tych narzędzi:
Sugeruję używać Androida Debug Monitor , jest dobry. Ponieważ zaćmienie zawiesza się, gdy jest tam zbyt wiele dzienników, i przez filtr logcat adb i wszystko jest trudne.
źródło
Musisz sprawdzić
Stack trace
Jak to zrobić?
na swoim IDE Sprawdź okna z LOGCAT
Jeśli nie widzisz okien logcat, przejdź do tej ścieżki i otwórz ją
jeśli używasz Google-API, przejdź do tej ścieżki
adb logcat> logcat.txt
źródło
W poniższej metodzie showToast () musisz przekazać inny parametr kontekstu lub kontekstu aplikacji, abyś mógł spróbować.
źródło
Pozwól, że podzielę się podstawową analizą Logcat, gdy napotkasz wymuszenie zamknięcia (gdy aplikacja przestanie działać).
DOCS
Podstawowym narzędziem systemu Android do zbierania / analizowania dzienników jest logcat.
TUTAJ to strona Androida o logcat
Jeśli używasz Androida Studio, możesz również sprawdzić ten LINK .
Przechwytywanie
Zasadniczo możesz RĘCZNIE przechwycić logcat za pomocą następującego polecenia (lub po prostu sprawdź okno AndroidMonitor w AndroidStudio):
Do polecenia można dodać wiele parametrów, które pomagają filtrować i wyświetlać żądaną wiadomość ... To jest sprawa osobista ... Zawsze używam poniższego polecenia, aby uzyskać znacznik czasu wiadomości:
Możesz przekierować dane wyjściowe do pliku i przeanalizować je w edytorze tekstu.
Analizować
Jeśli Twoja aplikacja ulega awarii, otrzymasz coś takiego:
Ta część dziennika pokazuje wiele informacji:
07-09 08:29:13.475
Ważne jest, aby sprawdzić, kiedy wystąpił problem ... W dzienniku może znajdować się kilka błędów ... musisz mieć pewność, że sprawdzasz poprawne komunikaty :)
com.example.khan.abc
W ten sposób wiesz, która aplikacja uległa awarii (aby mieć pewność, że sprawdzasz dzienniki swojej wiadomości)
java.lang.NullPointerException
Błąd wyjątku wskaźnika NULL
Attempt to invoke virtual method 'void android.support.v4.app.FragmentActivity.onBackPressed()' on a null object reference
Próbowano wywołać metodę
onBackPressed()
zFragmentActivity
obiektu. Jednak ten obiekt byłnull
wtedy, gdy to zrobiłeś.Stack Trace: Stack Trace pokazuje kolejność wywoływania metod ... Czasami błąd zdarza się w metodzie wywołującej (a nie w metodzie wywoływanej).
na com.example.khan.abc.AudioFragment $ 1.onClick (AudioFragment.java:125)
Wystąpił błąd w pliku
com.example.khan.abc.AudioFragment.java
, wewnątrzonClick()
metody w linii:125
(stacktrace pokazuje linię, w której wystąpił błąd)Zostało nazwane przez:
Który został nazwany przez:
który został nazwany przez:
itp....
Przegląd
To był tylko przegląd ... Nie wszystkie dzienniki są proste itp. ... Wystarczy podzielić się pomysłem i dostarczyć podstawowe informacje ...
Mam nadzieję, że mógłbym ci jakoś pomóc ... Pozdrawiam
źródło
Użyj LogCat i spróbuj znaleźć przyczynę awarii aplikacji.
Aby zobaczyć Logcat, jeśli korzystasz z Android Studio, naciśnij ALT + 6 lub
jeśli używasz Eclipse, to Window -> Open Perspective -> Other - LogCat
Przejdź do LogCat, z rozwijanego menu wybierz błąd. Będzie zawierał wszystkie wymagane informacje, które pomogą ci w debugowaniu. Jeśli to nie pomoże, opublikuj LogCat jako edycję swojego pytania, a ktoś ci pomoże.
źródło
Jeśli aplikacja z jakiegoś powodu ulega awarii bez dobrego śledzenia stosu. Spróbuj debugować od pierwszej linii i przechodzić linia po linii do awarii. Następnie otrzymasz odpowiedź, która linia powoduje problemy. Prawdopodobnie możesz następnie zapakować go w try catch catch i wydrukować błąd.
źródło
Ten komunikat o błędzie można również uzyskać samodzielnie, bez żadnych śladów stosu ani żadnego dodatkowego komunikatu o błędzie.
W takim przypadku musisz upewnić się, że manifest Androida jest poprawnie skonfigurowany (w tym wszelkie manifesty łączące się z biblioteki i wszelkie działania pochodzące z biblioteki), a także zwrócić szczególną uwagę na pierwszą aktywność wyświetlaną w aplikacji w plikach manifestu .
źródło
Awaria podczas programowania
Wypróbuj mój ulubiony widok dziennika narzędzi, aby uzyskać dzienniki i przeanalizować je podczas programowania.
Pamiętaj, aby zaznaczyć
./logview
i./lib/logview.jar
jako wykonywalny podczas działania w systemie Linux.Jeśli Ci się nie podoba, istnieje wiele alternatywnych przeglądarek dzienników pulpitu dla Androida .
Crash na wolności
Zintegruj narzędzie do raportowania awarii w czasie rzeczywistym, takie jak Firebase Crashlytics , aby uzyskać stosy nieobsługiwanych wyjątków, które wystąpiły na urządzeniach użytkowników.
Przeczytaj, jak wydać Buggy App (i Live to Tell the Tale), aby dowiedzieć się więcej o rozwiązywaniu problemów w terenie.
źródło
Ludzie popełniają błędy, a więc i kodują.
Kiedykolwiek coś
error
takiego się zdarzy, zawsze sprawdzaj za pomocą logcat z tekstem w kolorze czerwonym, jednak możesz znaleźć prawdziwy problem w kolorze niebieskim z podkreśleniem w tekście w kolorze czerwonym.Upewnij się, że jeśli tworzysz nowy
activity
, zawsze deklarujactivity
wAndroidManifest
pliku.Jeśli dodajesz uprawnienia, zadeklaruj je również w
AndroidMainifest
pliku.źródło
Logcat - Aby sprawdzić dzienniki w fazie rozwoju Android Studio
Najpierw wyczyść Logcat i pozwól aplikacji ponownie się zawiesić, abyś mógł uzyskać tylko szczegółowe dane dziennika awarii. Musisz sprawdzić ślad stosu
Typowy błąd podczas awarii aplikacji, taki jak:
Aby rozwiązać błąd awarii aplikacji:
źródło
Najpierw musisz sprawdzić, gdzie i dlaczego aplikacja się zawiesiła.
(Unfortunately, MyApp has stopped.).
Za pomocąLOG
możesz dowiedzieć się, co poszło nie tak.Następnie dowiesz się, w którym punkcie Twoja aplikacja przestała to naprawiać.
źródło
Jeśli nie masz żadnego interesującego dziennika w swoim terminalu (lub nie są one bezpośrednio związane z twoją aplikacją), być może twój problem jest spowodowany rodzimą biblioteką. W takim przypadku powinieneś sprawdzić pliki „nagrobka” w swoim terminalu.
Domyślna lokalizacja plików nagrobków zależy od każdego urządzenia, ale w takim przypadku będziesz mieć dziennik z informacją:
Tombstone written to: /data/tombstones/tombstone_06
Aby uzyskać więcej informacji, sprawdź https://source.android.com/devices/tech/debug .
źródło
Również uruchomienie tego polecenia w terminalu może pomóc w znalezieniu problemu:
gradlew build > log.txt 2>details.txt
następnie powinieneś przejść do lokalizacji pliku gradlew w czytaniu dwóch powyższych plików dziennika.
źródło