I diversi LogCatmetodi sono:
Log.v(); // Verbose
Log.d(); // Debug
Log.i(); // Info
Log.w(); // Warning
Log.e(); // ErrorQuali sono le situazioni appropriate per utilizzare ciascun tipo di registrazione? So che forse è solo un po 'di semantica e forse non ha molta importanza, ma per il LogCatfiltraggio in Android Studio ed Eclipse, sarebbe bello sapere che sto usando i metodi corretti nei momenti appropriati.
Risposte:
Andiamo in ordine inverso:
Log.e : questo è per quando accadono cose brutte. Utilizzare questo tag in luoghi come all'interno di un'istruzione catch. Si sa che un errore si è verificato e quindi si sta accedendo un errore.
Log.w : usalo quando sospetti che stia succedendo qualcosa di losco. Potrebbe non essere completamente completo in modalità errore, ma forse ti sei ripreso da un comportamento imprevisto. Fondamentalmente, usa questo per registrare cose che non ti aspettavi che accadessero, ma non è necessariamente un errore. Un po 'come un "ehi, è successo, ed è strano , dovremmo esaminarlo".
Log.i : utilizzare questa opzione per pubblicare informazioni utilinel registro. Ad esempio: che ti sei connesso correttamente a un server. Fondamentalmente usalo per segnalare i successi.
Log.d : utilizzare questo perscopi di debug . Se vuoi stampare un sacco di messaggi in modo da poter registrare l'esatto flusso del tuo programma, usa questo. Se si desidera mantenere un registro di valori variabili, utilizzare questo.
Log.v : usalo quando vuoi andare assolutamente fuori di testa con la tua registrazione. Se per qualche motivo hai deciso di registrare tutto in una parte particolare della tua app, usa il tag Log.v.
E come bonus ...
Log.wtfnemmeno di aver controllato un paio di volte e ho riso davvero ad alta voce .. Secondo me, tutte le API dovrebbero avere qualcosa del genere all'interno
I diversi metodi sono indicazioni di priorità. Come li hai elencati, stanno andando dal meno importante. Penso che il modo in cui li associ specificatamente ai log di debug nel tuo codice dipende dal componente o dall'app su cui stai lavorando, nonché dal modo in cui Android li tratta su diversi stili di build (eng, userdebug e user). Ho lavorato parecchio nei demoni nativi su Android, ed è così che lo faccio. Potrebbe non essere applicabile direttamente alla tua app, ma potrebbe esserci un terreno comune. Se la mia spiegazione sembra vaga, è perché parte di questo è più un'arte che una scienza. La mia regola di base è quella di essere il più efficiente possibile, assicurarti di poter ragionevolmente eseguire il debug del tuo componente senza uccidere le prestazioni del sistema e controllare sempre gli errori e registrarli.
V - Stampe di stato a intervalli diversi o su qualsiasi evento che si verifichi elabora il mio componente. Stampe forse anche molto dettagliate dei payload di messaggi / eventi che il mio componente riceve o invia.
D - Dettagli di eventi minori che si verificano all'interno del mio componente, nonché payload di messaggi / eventi che il mio componente riceve o invia.
I - L'intestazione di tutti i messaggi / eventi che il mio componente riceve o invia, nonché di eventuali parti importanti del payload che sono fondamentali per il funzionamento del mio componente.
W: Tutto ciò che accade è insolito o sospetto, ma non necessariamente un errore.
E - Errori, ovvero cose che non dovrebbero accadere quando le cose funzionano come dovrebbero.
L'errore più grande che vedo fare è che usano troppe cose come V, D e I, ma non usano mai W o E. Se un errore, per definizione, non dovrebbe accadere o dovrebbe accadere molto raramente, allora è estremamente economico per te per registrare un messaggio quando si verifica. D'altra parte, se ogni volta che qualcuno preme un tasto si esegue un Log.i (), si sta abusando della risorsa di registrazione condivisa. Naturalmente, usa il buon senso e fai attenzione con i log degli errori per cose al di fuori del tuo controllo (come errori di rete) o contenuti in loop stretti.
Forse male
Log.i("I am here");Buona
Log.e("I shouldn't be here");Tenendo presente tutto ciò, più il codice si avvicina alla "produzione pronta", più è possibile limitare il livello di registrazione di base per il codice (è necessario V in alpha, D in beta, I in produzione o eventualmente anche W in produzione ). Dovresti passare attraverso alcuni semplici casi d'uso e visualizzare i log per assicurarti di poter ancora capire cosa sta succedendo mentre applichi un filtro più restrittivo. Se corri con il filtro qui sotto, dovresti comunque essere in grado di dire cosa sta facendo la tua app, ma forse non ottenere tutti i dettagli.
logcat -v threadtime MyApp:I *:SIl codice sorgente fornisce alcune indicazioni di base:
L'ordine in termini di verbosità, dal minimo alla maggior parte è ERRORE, AVVISO, INFO, DEBUG, VERBOSE. Verbose non deve mai essere compilato in un'applicazione se non durante lo sviluppo. I registri di debug vengono compilati ma eliminati in fase di esecuzione. I registri di errori, avvisi e informazioni vengono sempre mantenuti.
Per maggiori dettagli, la risposta di Kurtis è morta. Vorrei solo aggiungere: non registrare alcuna informazione personale o privata su INFOo sopra ( WARN/ ERROR). Altrimenti, le segnalazioni di bug o qualsiasi altra cosa che includa la registrazione potrebbe essere inquinata.
È possibile utilizzare LOG come:
Log.e(String, String) (error)
Log.w(String, String) (warning)
Log.i(String, String) (information)
Log.d(String, String) (debug)
Log.v(String, String) (verbose)codice di esempio:
private static final String TAG = "MyActivity";
...
Log.i(TAG, "MyClass.getView() — get item number " + position);Penso che il punto di questi diversi tipi di registrazione sia se desideri che la tua app autolami automaticamente i propri registri. Quindi Verbose potrebbe registrare assolutamente tutto ciò che è importante nella tua app, quindi il livello di debug registrerebbe un sottoinsieme dei registri dettagliati e quindi il livello Info registrerà un sottoinsieme dei registri di debug. Quando si arriva ai log degli errori, si desidera semplicemente registrare qualsiasi tipo di errore che potrebbe essersi verificato. C'è anche un livello di debug chiamato Fatal per quando qualcosa colpisce davvero il fan nella tua app.
In generale, hai ragione, è sostanzialmente arbitrario e spetta a te definire ciò che è considerato un registro di debug rispetto a informazioni, versus ed errori, ecc. Ecc.
Anche se a questa domanda è già stata data risposta, ritengo che vi siano esempi mancanti nella risposta a cui è stata data risposta.
Pertanto porterò qui quello che ho scritto in un post sul blog "Livelli di registro Android"
verboso
È il livello più basso di registrazione. Se vuoi impazzire con la registrazione, vai con questo livello. Non ho mai capito quando usare Verbose e quando usare Debug. La differenza mi è sembrata molto arbitraria. Alla fine l'ho capito una volta che mi è stato indicato il codice sorgente di Android¹ "Verbose non dovrebbe mai essere compilato in un'applicazione se non durante lo sviluppo." Ora è chiaro per me, ogni volta che si sta sviluppando e si desidera aggiungere registri eliminabili che ti aiutano durante lo sviluppo, è utile avere un livello dettagliato che ti aiuterà a eliminare tutti questi registri prima di andare in produzione.
mettere a punto
È a scopo di debug. Questo è il livello più basso che dovrebbe essere in produzione. Le informazioni che sono qui sono di aiuto durante lo sviluppo. La maggior parte delle volte disabiliterai questo log in produzione in modo che vengano inviate meno informazioni e abiliterai questo log solo in caso di problemi. Mi piace accedere al debug di tutte le informazioni che l'app invia / riceve dal server (fare attenzione a non registrare le password !!!). Questo è molto utile per capire se il bug si trova nel server o nell'app. Faccio anche registri di entrata e di uscita di funzioni importanti.
Informazioni
Per i messaggi informativi che evidenziano l'avanzamento dell'applicazione. Ad esempio, al termine dell'inizializzazione dell'app. Aggiungi informazioni quando l'utente si sposta tra attività e frammenti. Registra ogni chiamata API ma solo poche informazioni come l'URL, lo stato e il tempo di risposta.
avvertimento
Quando c'è una situazione potenzialmente dannosa.
Questo registro è nella mia esperienza di livello difficile. Quando hai una potenziale situazione dannosa? In generale o che è OK o che è un errore. Personalmente non uso molto questo livello. Esempi di quando lo uso sono di solito quando le cose accadono più volte. Ad esempio, un utente ha una password errata più di 3 volte. Ciò potrebbe essere dovuto al fatto che ha inserito la password in modo errato per 3 volte, potrebbe anche essere dovuto a un problema con un personaggio che non è stato accettato nel nostro sistema. Lo stesso vale per i problemi di connessione di rete.
Errore
Eventi di errore L'applicazione può continuare a essere eseguita dopo l'errore. Questo può essere ad esempio quando ottengo un puntatore null dove non dovrei averne uno. Si è verificato un errore durante l'analisi della risposta del server. Ho ricevuto un errore dal server.
WTF (What a Terrible Failure)
Fatale è per gravi eventi di errore che porteranno alla chiusura dell'applicazione. In Android il fatale è in realtà il livello di errore, la differenza è che aggiunge anche il fullstack.
Il sito Web Android Studio ha recentemente (credo) fornito alcuni consigli su che tipo di messaggi aspettarsi da diversi livelli di registro che potrebbero essere utili insieme alla risposta di Kurtis:
Verboseregistrazione. È quello che usi quando vuoi produrre ogni possibile operazione logica.