Niestety MyApp przestała działać. Jak mogę to rozwiązać?
Rozwijam aplikację i za każdym razem, gdy ją uruchamiam, otrzymuję komunikat:
Niestety, MyApp przestał działać.
Co mogę zrobić, aby rozwiązać ten problem?
O tym pytaniu - oczywiście zainspirowane artykułem Co to jest ślad stosu i jak mogę go użyć do debugowania błędów aplikacji? , istnieje wiele pytań bez dalszych szczegółów, które wskazują, że ich aplikacja uległa awarii. To pytanie ma na celu poinstruowanie początkujących programistów Androida, jak samodzielnie próbować rozwiązać swoje problemy lub zadawać właściwe pytania.
Odpowiedzi
Ta odpowiedź opisuje proces pobierania śladu stosu. Masz już ślad stosu? Przeczytaj informacje o śladach stosu w sekcji „ Co to jest ślad stosu i jak mogę go użyć do debugowania błędów aplikacji? ”
Problem
Twoja aplikacja została zamknięta, ponieważ RuntimeException
wyrzucono nieprzechwycony .
Najczęstszym z nich jest NullPointerException
.
Jak to rozwiązać?
Za każdym razem, gdy aplikacja na Androida ulegnie awarii (lub jakakolwiek aplikacja Java w tym zakresie), Stack trace
do konsoli (w tym przypadku logcat) jest zapisywane a. Ten ślad stosu zawiera istotne informacje potrzebne do rozwiązania problemu.
Android Studio
W dolnym pasku okna kliknij Logcat
przycisk. Alternatywnie możesz nacisnąć alt+ 6. Upewnij się, że w Devices
panelu jest wybrany emulator lub urządzenie . 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 (przy użyciu kosza po prawej stronie) i ponowne zawieszenie aplikacji.
Znalazłem ślad stosu, co teraz?
Yay! Jesteś w połowie drogi do rozwiązania swojego problemu.
Musisz tylko dowiedzieć się, co dokładnie spowodowało awarię aplikacji, analizując ślad stosu.
Przeczytaj informacje o śladach stosu w sekcji „ Co to jest ślad stosu i jak mogę go użyć do debugowania błędów aplikacji? ”
Nadal nie mogę rozwiązać swojego problemu!
Jeśli znalazłeś swój Exception
i wiersz, w którym wystąpił, i nadal nie możesz dowiedzieć się, jak to naprawić, nie wahaj się zadać pytania na StackOverflow.
Postaraj się być tak zwięzły, jak to tylko możliwe: umieść ślad stosu i odpowiedni kod (np. Kilka wierszy do wiersza, który wyrzucił Exception
).
Można użyć narzędzia ADB Google , aby Logcat file
przeanalizować problem.
adb logcat > logcat.txt
otwórz logcat.txt
plik i wyszukaj nazwę swojej aplikacji. Powinny być informacje o tym, dlaczego się nie powiodło, numer linii, nazwa klasy itp.
Najpierw sprawdź, w którym momencie Twoja aplikacja uległa awarii ( Unfortunately, MyApp has stopped.
). W tym celu możesz użyć Log.e("TAG", "Message");
, używając tego wiersza, możesz zobaczyć dziennik aplikacji w logcat.
Następnie dowiesz się, w którym momencie zatrzymała się Twoja aplikacja, co jest bardzo łatwe do rozwiązania po Twojej stronie.
Po prostu sprawdź błąd w log cat.
Dostajesz opcję log cat z eclipse:
okno-> pokaż widok-> inne-> Android-> Logcat
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:
kliknij prawym przyciskiem myszy projekt-> debuguj jako-> aplikację na Androida
Uwaga: ta odpowiedź dotyczy Android Studio 2.2.2
Uwaga 2: Rozważam, że twoje urządzenie zostało pomyślnie podłączone.
Pierwszą rzeczą, którą robisz, gdy aplikacja się zawiesza, jest zajrzenie do LogCata, na dole Android Studio znajduje się pasek narzędzi z listą menu:
Kliknij „Monitor Android” (ten, który podkreśliłem na powyższym obrazku. ^)
Teraz otrzymasz coś takiego:
Zmień „ Verbose
” na „ Error
” Teraz pokaże tylko zarejestrowane błędy. Nie martw się o wszystkie te błędy (jeśli je masz) teraz.
Ok. Teraz zrób to, co zrobiłeś, aby zawiesić swoją aplikację. Po awarii aplikacji przejdź do logcat. Powinieneś znaleźć nowy dziennik awarii, który zawiera dużo at:x.x.x
: i Caused by: TrumpIsPresidentException
na przykład. Przejdź do tego Caused by:
oświadczenia w swoim logcat.
Oprócz tego Caused By:
powinien istnieć wyjątek, który się wydarzył. W moim przypadku jest to a, RuntimeException
a pod nim powinna znajdować się linia zawierająca niebieski link, np .:
Jeśli toCaused by:
NIE MA linii z niebieskim tekstem gdzieś pod nią, poszukaj innej, Caused by:
która ją zawiera.
Kliknij ten niebieski link . Powinien zaprowadzić Cię do miejsca, w którym wystąpił problem. W moim przypadku było to spowodowane tą linią:
throw new RuntimeException();
Więc teraz wiem, dlaczego się zawiesza. To dlatego, że sam rzucam wyjątek. To był oczywisty błąd .
Powiedzmy jednak, że mam inny błąd:
java.lang.NullPointerException
Sprawdziłem mojego logcata, kliknąłem w niebieski link, który mi dał i zabrał mnie tutaj:
mTextView.setText(myString);
Więc teraz chcę debugować. Zgodnie z tym pytaniem StackOverflow , wyjątek NullPointerException mówi, że coś jest null
.
Więc dowiedzmy się, co jest null . Są dwie możliwości. Albo mTextView
jest null, albo myString
jest null. Aby się dowiedzieć, przed mTextView.setText(mString)
linią dodaję te dwie linie:
Log.d("AppDebug","mTextView is null: " + String.valueOf(mTextView == null);
Log.d("AppDebug","myString is null: " + String.valueOf(myString== null);
Teraz, podobnie jak poprzednio (zmieniliśmy opcję Verose na Error), chcemy zmienić „Error” na „Debug”. Ponieważ rejestrujemy się przez debugowanie. Oto wszystkie metody logowania:
Log.
d means Debug
e means error
w means warning
v means verbose
i means information
wtf means "What a terrible failure". This is similar to Log.e
Tak więc od kiedy używaliśmy Log.d
, sprawdzamy Debugowanie. Dlatego zmieniliśmy to na debugowanie.
Uwaga Log.d
ma pierwszy parametr, w naszym przypadku „AppDebug”. Kliknij menu rozwijane „Brak filtrów” w prawym górnym rogu logcat. Wybierz „Edytuj konfigurację filtru”, nadaj nazwę swojemu filtrowi i w polu „Log Tag” wpisz „App Debug”. Kliknij OK". Teraz powinieneś zobaczyć dwie linie w logcat:
yourPackageNameAndApp: mTextView is null: true
yourPackageNameAndApp: myString is null: false
Więc teraz wiemy, że mTextView jest null.
Obserwuję swój kod, teraz coś zauważam.
private TextView mTextView
Deklarowałem, że jestem najlepszy w mojej klasie. Ale ja tego nie definiuję.
Zasadniczo zapomniałem zrobić to w moim onCreate ():
mTextView = (TextView) findViewById(R.id.textview_id_in_xml);
Dlatego właśnie mTextView
jest zerowa, ponieważ zapomniałem powiedzieć mojej aplikacji, co to jest. Więc dodaję tę linię, uruchamiam moją aplikację i teraz aplikacja nie ulega awarii.
To wyskakujące okienko jest wyświetlane tylko wtedy, gdy w kodzie pojawi się krytyczny wyjątek, który zatrzymuje wykonywanie aplikacji. To może być żadnego wyjątku NullPointerException
, OutOfMemoryException
etc.
Najlepszym sposobem sprawdzenia jest Logcat, jeśli nadal tworzysz aplikację w Android Studio, co jest szybkim sposobem na odczytanie śladu stosu i sprawdzenie przyczyny aplikacji.
Jeśli Twoja aplikacja już działa, nie możesz użyć logcat . W tym celu możesz zaimplementować, Crashlytics
aby dostarczać raporty o błędach dla każdego wystąpienia wyjątku.
Sprawdź swoją Logcat
wiadomość i przejrzyj Manifest
plik. Powinno brakować czegoś takiego jak zdefiniowanie Activity,
uprawnień użytkownika, itp.
Możesz użyć dowolnego z tych narzędzi:
adb logcat
adb logcat> logs.txt (możesz używać edytorów do otwierania i wyszukiwania błędów).
eclipse logcat (jeśli nie jest widoczny w eclipse, przejdź do Windows-> Show View-> Others-> Android-> LogCat)
Android Debug Monitor lub Android Device Monitor (wpisz monitor poleceń lub otwórz przez interfejs użytkownika)
- Android Studio
Proponuję skorzystać z Android Debug Monitor , jest dobrze. Ponieważ zaćmienie zawiesza się, gdy jest zbyt wiele dzienników i przez filtr adb logcat i wszystko jest trudne.
Musisz sprawdzić Stack trace
Jak to zrobić?
na swoim IDE Sprawdź formularz systemu Windows LOGCAT
Jeśli nie widzisz okien logcat, przejdź do tej ścieżki i otwórz ją
window->show view->others->Android->Logcat
jeśli korzystasz z Google-Api, przejdź do tej ścieżki
adb logcat> logcat.txt
W poniższej metodzie showToast () musisz przekazać inny parametr dla kontekstu lub kontekstu aplikacji, robiąc to, możesz to wypróbować.
public void showToast(String error, Context applicationContext){
LayoutInflater inflater = getLayoutInflater();
View view = inflater.inflate(R.layout.custom_toast, (ViewGroup)
findViewById(R.id.toast_root));
TextView text = (TextView) findViewById(R.id.toast_error);
text.setText(error);
Toast toast = new Toast(applicationContext);
toast.setGravity(Gravity.TOP | Gravity.FILL_HORIZONTAL, 0, 0);
toast.setDuration(Toast.LENGTH_SHORT);
toast.setView(view);
toast.show();
}
Pozwólcie, że udostępnię podstawową analizę Logcat dotyczącą sytuacji, gdy napotkasz wymuszone zamknięcie (gdy aplikacja przestanie działać).
DOCS
Podstawowym narzędziem systemu Android do zbierania / analizowania dzienników jest logcat.
TUTAJ jest strona Androida o logcat
Jeśli korzystasz z Android Studio, możesz również sprawdzić to LINK .
Przechwytywanie
Zasadniczo możesz RĘCZNIE przechwycić logcat za pomocą następującego polecenia (lub po prostu sprawdź okno AndroidMonitor w AndroidStudio):
adb logcat
Istnieje wiele parametrów, które możesz dodać do polecenia, które pomagają filtrować i wyświetlać żądaną wiadomość ... To jest osobiste ... Zawsze używam poniższego polecenia, aby uzyskać znacznik czasu wiadomości:
adb logcat -v time
Możesz przekierować dane wyjściowe do pliku i przeanalizować je w edytorze tekstu.
Analizowanie
Jeśli Twoja aplikacja się zawiesza, otrzymasz coś takiego:
07-09 08:29:13.474 21144-21144/com.example.khan.abc D/AndroidRuntime: Shutting down VM
07-09 08:29:13.475 21144-21144/com.example.khan.abc E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.example.khan.abc, PID: 21144
java.lang.NullPointerException: Attempt to invoke virtual method 'void android.support.v4.app.FragmentActivity.onBackPressed()' on a null object reference
at com.example.khan.abc.AudioFragment$1.onClick(AudioFragment.java:125)
at android.view.View.performClick(View.java:4848)
at android.view.View$PerformClick.run(View.java:20262)
at android.os.Handler.handleCallback(Handler.java:815)
at android.os.Handler.dispatchMessage(Handler.java:104)
at android.os.Looper.loop(Looper.java:194)
at android.app.ActivityThread.main(ActivityThread.java:5631)
at java.lang.reflect.Method.invoke(Native Method)
at java.lang.reflect.Method.invoke(Method.java:372)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:959)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:754)
07-09 08:29:15.195 21144-21144/com.example.khan.abc I/Process: Sending signal. PID: 21144 SIG: 9
Ta część dziennika zawiera wiele informacji:
- Kiedy pojawił się problem:
07-09 08:29:13.475
Ważne jest, aby sprawdzić, kiedy wystąpił problem ... W dzienniku możesz znaleźć kilka błędów ... musisz być pewien, że sprawdzasz odpowiednie komunikaty :)
- Która aplikacja uległa awarii:
com.example.khan.abc
W ten sposób wiesz, która aplikacja uległa awarii (aby mieć pewność, że sprawdzasz dzienniki dotyczące wiadomości)
- Który BŁĄD:
java.lang.NullPointerException
Błąd wyjątku wskaźnika NULL
- Szczegółowe informacje o błędzie:
Attempt to invoke virtual method 'void android.support.v4.app.FragmentActivity.onBackPressed()' on a null object reference
Próbowałeś wywołać metodę onBackPressed()
z FragmentActivity
obiektu. Jednak ten obiekt był, null
kiedy to zrobiłeś.
Stack Trace: Stack Trace pokazuje kolejność wywołań metody ... Czasami błąd występuje w metodzie wywołującej (a nie w wywołanej metodzie).
at com.example.khan.abc.AudioFragment $ 1, onClick (AudioFragment.java:125)
Wystąpił błąd w pliku com.example.khan.abc.AudioFragment.java
, wewnątrz onClick()
metody w linii: 125
(stacktrace pokazuje wiersz, w którym wystąpił błąd)
Został wezwany przez:
at android.view.View.performClick(View.java:4848)
Który został wezwany przez:
at android.view.View$PerformClick.run(View.java:20262)
który został wezwany przez:
at android.os.Handler.handleCallback(Handler.java:815)
itp....
Przegląd
To był tylko przegląd ... Nie wszystkie dzienniki są proste, ale błąd podaje konkretny problem, a szczegółowe pokazuje cały problem ... Służy tylko do podzielenia się pomysłem i dostarczenia podstawowych informacji ...
Mam nadzieję, że mógłbym ci jakoś pomóc ... Pozdrawiam
Użyj LogCat i spróbuj znaleźć przyczynę awarii aplikacji.
Aby zobaczyć Logcat, jeśli używasz Android Studio, naciśnij ALT + 6 lub
jeśli używasz Eclipse, wybierz Window -> Open Perspective -> Other - LogCat
Przejdź do LogCat, z menu rozwijanego wybierz błąd. Będzie zawierał wszystkie wymagane informacje, które pomogą Ci debugować. Jeśli to nie pomoże, opublikuj LogCat jako poprawkę do swojego pytania, a ktoś ci pomoże.
Jeśli z jakiegoś powodu Twoja aplikacja ulega awarii bez dobrego śledzenia stosu. Spróbuj zdebugować go od pierwszego wiersza i przejdź wiersz po wierszu, aż do awarii. Wtedy otrzymasz odpowiedź, która linia sprawia ci kłopoty. Prawdopodobnie możesz wtedy opakować go w blok try catch i wydrukować wyjście błędu.
Możesz również otrzymać ten komunikat o błędzie samodzielnie, bez śladu stosu lub jakiegokolwiek innego komunikatu o błędzie.
W takim przypadku musisz upewnić się, że manifest systemu Android jest poprawnie skonfigurowany (w tym wszelkie łączenie manifestu z biblioteki i wszelkie działania, które pochodzą z biblioteki) i zwrócić szczególną uwagę na pierwsze działanie wyświetlane w aplikacji w plikach manifestu .
Awaria podczas rozwoju
Wypróbuj mój ulubiony widok dziennika narzędzia, aby uzyskać dzienniki i przeanalizować je podczas programowania.
Pamiętaj, aby oznaczyć ./logview
i ./lib/logview.jar
jako wykonywalne podczas pracy w systemie Linux.
Jeśli ci się to nie podoba, istnieje wiele alternatywnych przeglądarek dzienników pulpitu dla Androida .
Rozbij się na wolności
Zintegruj narzędzie do raportowania awarii w czasie rzeczywistym, takie jak Firebase Crashlytics , aby uzyskać ślady stosu nieobsłużonych wyjątków, które wystąpiły na urządzeniach użytkowników.
Przeczytaj artykuł Jak wydać aplikację Buggy (i przeżyć, aby opowiedzieć historię ), aby dowiedzieć się więcej o obsłudze błędów w terenie.
Ludzie popełniają błędy, a więc także podczas kodowania.
Kiedy kiedykolwiek coś się error
wydarzyło, zawsze sprawdzaj w logcatie tekst w kolorze czerwonym, jednak możesz znaleźć prawdziwy problem w tekście w kolorze niebieskim z podkreśleniem w tekście w kolorze czerwonym.
Upewnij się, że jeśli utworzysz nowy activity
, zawsze deklaruj activity
w AndroidManifest
pliku.
Jeśli dodajesz uprawnienia, zadeklaruj je również w AndroidMainifest
pliku.
Logcat - Aby sprawdzić dzienniki w fazie rozwoju Android Studio
Najpierw wyczyść Logcat i pozwól aplikacji ponownie się zawiesić, aby uzyskać tylko szczegóły dziennika awarii. Musisz sprawdzić ślad stosu
Niestety, MyApp przestał działać. Jest ku temu wiele powodów. Możesz sprawdzić to samo w dziennikach. W tym celu możesz użyć Log.e ("TAG", "Message");
Typowy błąd podczas awarii aplikacji, taki jak:
- Błąd w kodowaniu (niewłaściwe użycie słów kluczowych).
- Niezgodna nazwa właściwości.
- Nieobsługiwana wtyczka (być może).
- Niezgodna wersja (być może).
- Brak aktywności w pliku AndroidManifest.
- Brak uprawnień w pliku AndroidManifest.
- Najczęstsze wyjątki NullPointerException.
- Zadeklarowane, ale nie zdefiniowane.
Aby rozwiązać błąd awarii aplikacji:
- Pamiętaj o powyższych punktach i przejdź przez to.
- Wraz z błędem otrzymasz nazwę pliku również w kolorze niebieskim (kliknij na nie i przejdź do kodu z błędu).
Po pierwsze, trzeba sprawdzić, gdzie i dlaczego aplikacja została rozbił (Unfortunately, MyApp has stopped.).
Z pomocą LOG
można zrozumieć to, co poszło źle.
Następnie dowiesz się, w którym momencie Twoja aplikacja przestała to naprawiać.
Jeśli nie masz żadnego interesującego loginu na swoim terminalu (lub nie są one bezpośrednio związane z twoją aplikacją), być może przyczyną problemu jest natywna biblioteka. W takim przypadku powinieneś sprawdzić pliki „tombstone” w swoim terminalu.
Domyślna lokalizacja plików reliktów zależy od każdego urządzenia, ale w takim przypadku będziesz mieć dziennik zawierający: Tombstone written to: /data/tombstones/tombstone_06
Więcej informacji znajdziesz na https://source.android.com/devices/tech/debug .
Uruchomienie tego polecenia w terminalu może również pomóc w znalezieniu problemu:
gradlew build > log.txt 2>details.txt
następnie powinieneś udać się do lokalizacji pliku gradlew i przeczytać dwa powyższe pliki dziennika.