Możesz włączyć StrictMode na poziomie API 9 i wyższym.

StrictMode jest najczęściej używany do przechwytywania przypadkowego dysku lub sieci dostęp do głównego wątku aplikacji, gdzie operacje UI są odbierane i animacje odbywają się. Utrzymując główny wątek aplikacji responsywny, zapobiegasz również wyświetlaniu użytkownikom okien dialogowych ANR .

public void onCreate() {
    StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
                           .detectAll()
                           .penaltyLog()
                           .penaltyDeath()
                           .build());
    super.onCreate();
}

Używając penaltyLog() możesz oglądać wyjście adb logcat podczas użyj swojego wniosek, aby zobaczyć naruszenia, jak się zdarzają.

Zastanawiasz się, które zadanie posiada wątek UI. Plik śledzenia daje podpowiedź, aby znaleźć zadanie. musisz zbadać stan każdego wątku

Stan wątku

• uruchamianie-wykonywanie kodu aplikacji
• spanie-tzw. wątek.sleep ()
• monitor-oczekiwanie na uzyskanie blokady monitora
• obiekt oczekujący.wait ()
• native-wykonywanie kodu natywnego
• vmwait-oczekiwanie na zasób VM
• Zombie-wątek jest w trakcie umierania
• INIT-thread jest inicjalizujący (nie powinieneś tego widzieć)
• starting-thread zaraz się rozpocznie (tego też nie powinieneś widzieć)

Skoncentruj się na zawieszeniu, stanie monitora. Stan monitora wskazuje, który wątek jest badany, a stan zawieszenia wątku jest prawdopodobnie głównym powodem blokady.

Podstawowe kroki

1. Znajdź " czekanie na blokadę"
   • można znaleźć Stan monitora "wątek segregatora #15" prio=5 tid=75 MONITOR
   • masz szczęście, jeśli znajdziesz "czekanie na blokadę"
   • przykład: waiting to lock (a com.foo.A) trzymane przez threadid=74
2. możesz zauważyć, że" tid=74 " wstrzymuje zadanie. Więc przejdź do tid=74
3. tid = 74 znajdź główny powód!

Trace nie zawsze zawiera "waiting to lock". w tym przypadku trudno jest znaleźć główny powód.

Od kilku miesięcy uczę się Androida, więc daleko mi do eksperta, ale naprawdę zawiodłem się na dokumentacji ANRs.

Większość porad wydaje się być nastawiona na unikanie ich lub naprawianie przez ślepe przeglądanie kodu, co jest świetne, ale nie mogłem znaleźć nic na analizę śladu.

Są trzy rzeczy, których naprawdę musisz szukać z dziennikami ANR.

1) Deadlocks: gdy wątek jest w stanie oczekiwania, można spojrzeć poprzez szczegóły, aby dowiedzieć się, kto to jest " heldby=". Przez większość czasu będzie trzymana sama, ale jeśli będzie trzymana przez inny wątek, prawdopodobnie będzie to znak zagrożenia. Spójrz na ten wątek i zobacz, co go trzyma. Możesz znaleźć pętlę, która jest wyraźnym znakiem, że coś poszło nie tak. Jest to dość rzadkie, ale to pierwszy punkt, ponieważ kiedy to się dzieje, to koszmar

2) główny wątek oczekujący: jeśli główny wątek jest w stanie oczekiwania, sprawdź, czy jest utrzymywany przez inny wątek. To nie powinno się zdarzyć, ponieważ wątek interfejsu użytkownika nie powinien być utrzymywany przez wątek w tle.

Oba te scenariusze oznaczają, że musisz znacząco przerobić kod.

3) ciężkie operacje na głównym wątku: jest to najczęstsza przyczyna ANRs, ale czasami jedna z trudniejszych do znalezienia i naprawienia. Spójrz na szczegóły głównego wątku. Przewiń ślad stosu w dół, aż zobaczysz rozpoznane klasy(z aplikacji). Spójrz na metody w śledzeniu i dowiedz się, czy tworzysz sieć wywołania, wywołania db itp. w tych miejscach.

Wreszcie i przepraszam za bezwstydne podpięcie własnego kodu, możesz użyć pythonowego analizatora logów, który napisałem pod https://github.com/HarshEvilGeek/Android-Log-Analyzer to przejrzy Twoje pliki dziennika, otworzy pliki ANR, znajdzie martwe punkty, znajdzie oczekujące główne wątki, znajdzie nieobciążone wyjątki w dziennikach agenta i wydrukuje to wszystko na ekranie w stosunkowo łatwy do odczytania sposób. Przeczytaj plik ReadMe (który zamierzam dodać), aby dowiedzieć się, jak żeby go użyć. Pomogło mi to w zeszłym tygodniu!

Gdy analizujesz problemy z czasem, debugowanie często nie pomaga, ponieważ zamrożenie aplikacji w punkcie przerwania sprawi, że problem zniknie.

Najlepiej wstawić wiele połączeń logowania (Log.XXX()) w różnych wątkach i wywołaniach aplikacji i zobacz, gdzie jest opóźnienie. Jeśli potrzebujesz stacktrace, utwórz nowy wyjątek (wystarczy utworzyć instancję) i zaloguj go.

Co wywołuje ANR?

Ogólnie, system wyświetla ANR, jeśli aplikacja nie może odpowiedzieć na dane użytkownika.

W każdej sytuacji, w której aplikacja wykonuje potencjalnie długą operację, nie należy wykonywać pracy nad wątkiem interfejsu użytkownika, ale zamiast tego utworzyć wątek roboczy i wykonać większość pracy w nim. Dzięki temu wątek interfejsu użytkownika (który napędza pętlę zdarzeń interfejsu użytkownika) jest uruchomiony i uniemożliwia systemowi stwierdzenie, że Twój kod został zamrożony.

Jak uniknąć ANRs

Aplikacje na Androida normalnie działają w całości na pojedynczym wątku domyślnie "wątek UI" lub "wątek główny"). Oznacza to, że wszystko, co aplikacja robi w wątku interfejsu użytkownika, które zajmuje dużo czasu, może wywołać okno dialogowe ANR, ponieważ aplikacja nie daje sobie szansy na obsługę zdarzenia wejściowego lub transmisji intencyjnych.

Dlatego każda metoda uruchamiana w wątku UI powinna wykonać jak najmniej pracy w tym wątku. W szczególności działania powinny zrobić jak najmniej w kluczowych metodach cyklu życia, takich jak OnCreate () i onResume (). Potencjalnie długotrwałe operacje, takie jak operacje sieciowe lub bazodanowe, lub kosztowne obliczeniowo obliczenia, takie jak zmiana rozmiaru bitmap, powinny być wykonywane w wątku roboczym (lub w przypadku operacji bazodanowych, poprzez żądanie asynchroniczne).

Code: worker thread with the AsyncTask class

private class DownloadFilesTask extends AsyncTask<URL, Integer, Long> {
    // Do the long-running work in here
    protected Long doInBackground(URL... urls) {
        int count = urls.length;
        long totalSize = 0;
        for (int i = 0; i < count; i++) {
            totalSize += Downloader.downloadFile(urls[i]);
            publishProgress((int) ((i / (float) count) * 100));
            // Escape early if cancel() is called
            if (isCancelled()) break;
        }
        return totalSize;
    }

    // This is called each time you call publishProgress()
    protected void onProgressUpdate(Integer... progress) {
        setProgressPercent(progress[0]);
    }

    // This is called when doInBackground() is finished
    protected void onPostExecute(Long result) {
        showNotification("Downloaded " + result + " bytes");
    }
}

Code: Execute worker thread

Aby wykonać ten wątek roboczy, wystarczy tworzenie instancji i wywołanie execute ():

new DownloadFilesTask().execute(url1, url2, url3);

Źródło

Http://developer.android.com/training/articles/perf-anr.html

Mój problem z ANR, po wielu pracach dowiedziałem się, że wątek wywołuje zasób , który nie istniał w układzie, zamiast zwracać wyjątek, dostałem ANR ...

Musisz poszukać "waiting to lock" w /data/anr/traces.txt Plik

Więcej szczegółów: Inżynier ds. wysokiej wydajności Z Narzędziami z Androida i Play (Google I / O'17)

Basic na @Horyun Lee odpowiedź, napisałem mały skrypt Pythona , aby pomóc zbadać ANR z traces.txt.

ANRs będzie wyświetlany jako grafika przez graphviz, jeśli zainstalowałeś grapvhviz w swoim systemie.

$ ./anr.py --format png ./traces.txt

Png wyświetli się jak poniżej, jeśli w pliku traces.txt wykryto ANRs. To bardziej intuicyjne.

Przykładowy plik traces.txt użyty powyżej został pobrany z tutaj .

Rozważ użycie biblioteki ANR-Watchdog do dokładnego śledzenia i przechwytywania śladów stosu ANR z wysokim poziomem szczegółowości. Następnie możesz wysłać je do biblioteki raportowania awarii. Polecam użycie setReportMainThreadOnly() w tym scenariuszu. Możesz albo sprawić, że aplikacja rzuci nie-fatalny wyjątek punktu zamrożenia, albo zmusić aplikację do zamknięcia, gdy wystąpi ANR.

Należy pamiętać, że standardowe raporty ANR wysyłane do konsoli programisty Google Play często nie są wystarczająco dokładne, aby dokładnie określić problem. Dlatego potrzebna jest biblioteka innej firmy.