Esegui il debug della tua app per Android in base ai tag ANR nella dashboard di Crashlytics

Gli errori L'applicazione non risponde (ANR) vengono attivati quando il thread dell'interfaccia utente dell'applicazione non risponde per più di 5 secondi. Puoi leggere altre informazioni sugli errori ANR e sulla loro diagnosi nella documentazione di Android.

Inoltre, Crashlytics può aiutarti a individuare thread problematici specifici. Analizziamo gli ANR e poi, nella dashboard DevOps e coinvolgimento > Crashlytics, tagghiamo i thread applicabili per fornire suggerimenti su come eseguire il debug dell'ANR.

Le sezioni seguenti di questa pagina spiegano il significato di ogni tag ANR, mostrano un esempio di ANR con quel tag e forniscono una soluzione consigliata per eseguire il debug dell'ANR.

Triggered ANR

Un thread bloccato troppo a lungo e che ha attivato l'errore ANR è annotato con questo tag Triggered ANR.

Il thread problematico può essere il thread principale dell'app o qualsiasi thread che non risponde. Tuttavia, il thread taggato come Triggered ANR potrebbe essere o meno la causa effettiva dell'errore ANR. Per fornire informazioni per il debug e la correzione di questi errori ANR, Crashlytics tagga anche tutti gli altri thread coinvolti nell'errore ANR. Nelle sezioni seguenti di questa pagina, scopri gli altri tag che potrebbero essere applicati a un thread.

Deadlocked

Tutti i thread coinvolti in un deadlock che ha causato l'errore ANR sono annotati con questo tag Deadlocked.

Un deadlock si verifica quando un thread entra in uno stato di attesa perché una risorsa richiesta è detenuta da un altro thread, che a sua volta è in attesa di una risorsa detenuta dal primo thread. Se il thread principale dell'app si trova in questa situazione, è probabile che si verifichino errori ANR.

Suggerimento

Esamina i thread coinvolti nel deadlock e controlla le risorse/i blocchi acquisiti da questi thread. Per possibili soluzioni, consulta Deadlock e Algoritmi di prevenzione dei deadlock.

IO Root blocking

Qualsiasi thread che eseguiva operazioni di I/O lente e bloccava il thread Triggered ANR è annotato con il tag IO Root blocking. Se il thread Triggered ANR non è bloccato da altri thread, allora anche il thread IO Root blocking è un thread Root blocking.

Suggerimento

In generale, l'app non deve eseguire operazioni di I/O costose sul thread principale. Nel caso in cui il thread principale sia IO Root blocking, puoi anche utilizzare la modalità Strict per identificare eventuali operazioni di I/O involontarie che si verificano sul thread principale.

Root blocking

Qualsiasi thread che ha bloccato il thread taggato come Triggered ANR è annotato con il tag Root blocking. Se un thread è taggato sia come Root blocking sia come Triggered ANR, non esistono altri thread che lo bloccano.

Se alcuni thread Triggered ANR erano in attesa (magari in modo transitivo) di altri thread, sono Root blocking. Esistono vari motivi per cui un thread è la causa principale dell'errore ANR.

Suggerimento

Minimizza il lavoro che richiede un uso intensivo della CPU nel thread principale. Utilizza thread di worker o in background per eseguire attività che richiedono un utilizzo elevato della CPU.

Riduci al minimo il lavoro intensivo di I/O, come il caricamento da un database, nel thread principale.

Unknown root cause

Un thread viene contrassegnato con il tag Unknown root cause se è stato il thread che ha attivato l'errore ANR, ma era inattivo nel processo quando si è verificato l'errore ANR. Crashlytics non dispone di informazioni sufficienti per determinare la causa principale. Non esiste un motivo evidente per cui si è verificato questo errore ANR.

Suggerimento

Segui i consigli generali su come evitare gli errori ANR. Ad esempio, identifica i punti del codice in cui il thread principale dell'app può essere occupato per più di 5 secondi.

Waiting for binder call

Qualsiasi thread in attesa di una chiamata binder e che ha bloccato il thread Triggered ANR è annotato con il tag Waiting for binder call. Se il thread Triggered ANR non è bloccato da altri thread, allora anche il thread Waiting for binder call è un thread Root blocking.

Suggerimento

Poiché la latenza di una chiamata a Binder può essere imprevedibile, tratta le chiamate a Binder come operazioni di I/O ed evita di eseguirle nel thread principale, se possibile. Sposta il codice che attiva le chiamate a Binder (incluse le chiamate API della piattaforma che generano transazioni Binder) in un thread in background o memorizza nella cache i risultati se la chiamata dal thread principale è inevitabile.