Android Log.v (), Log.d (), Log.i (), Log.w (), Log.e () - ¿Cuándo usar cada uno?

Los diferentes LogCatmétodos son:

Log.v(); // Verbose
Log.d(); // Debug
Log.i(); // Info
Log.w(); // Warning
Log.e(); // Error

¿Cuáles son las situaciones apropiadas para usar cada tipo de registro? Sé que tal vez es solo un poco de semántica y tal vez realmente no importa, pero para LogCatfiltrar en Android Studio y Eclipse, sería bueno saber que estoy usando los métodos adecuados en los momentos adecuados.

Vamos en orden inverso:

• Log.e : Esto es para cuando suceden cosas malas. Use esta etiqueta en lugares como dentro de una declaración catch. Usted sabe que un error ha ocurrido y por lo tanto se está acumulando un error.

• Log.w : Use esto cuando sospeche que está sucediendo algo sospechoso. Es posible que no esté completamente lleno en el modo de error, pero tal vez se haya recuperado de un comportamiento inesperado. Básicamente, use esto para registrar cosas que no esperaba que sucedieran pero que no son necesariamente un error. Algo así como un "hey, esto sucedió, y es extraño , deberíamos investigarlo".

• Log.i : use esto para publicar información útilen el registro. Por ejemplo: que se ha conectado correctamente a un servidor. Básicamente, úselo para reportar éxitos.

• Log.d : Use esto parapropósitos de depuración . Si desea imprimir un montón de mensajes para poder registrar el flujo exacto de su programa, use esto. Si desea mantener un registro de valores variables, use esto.

• Log.v : Use esto cuando quiera volverse completamente loco con su registro. Si por alguna razón ha decidido registrar cada pequeña cosa en una parte particular de su aplicación, use la etiqueta Log.v.

Y como extra ...

• Log.wtf : Use esto cuando las cosas salgan absolutamente, horriblemente, una mierda santa. Conoces esos bloques de captura donde estás detectando errores que nunca deberías obtener ... sí, si quieres registrarlos usa Log.wtf

Los diferentes métodos son indicaciones de prioridad. Como los ha enumerado, van de menos a más importantes. Creo que la forma en que los asigna específicamente a los registros de depuración en su código depende del componente o la aplicación en la que esté trabajando, así como de cómo Android los trata en diferentes tipos de compilación (eng, userdebug y user). He hecho una buena cantidad de trabajo en los demonios nativos en Android, y así es como lo hago. Es posible que no se aplique directamente a su aplicación, pero puede haber algo en común. Si mi explicación suena vaga, es porque algo de esto es más un arte que una ciencia. Mi regla básica es ser lo más eficiente posible, asegurarme de que pueda depurar razonablemente su componente sin eliminar el rendimiento del sistema, y ​​siempre verifique si hay errores y regístrelos.

V - Impresiones de estado a diferentes intervalos, o sobre cualquier evento que ocurra que procese mi componente. También posiblemente impresiones muy detalladas de las cargas útiles de mensajes / eventos que mi componente recibe o envía.

D - Detalles de eventos menores que ocurren dentro de mi componente, así como cargas de mensajes / eventos que mi componente recibe o envía.

I: el encabezado de los mensajes / eventos que recibe o envía mi componente, así como cualquier parte importante de la carga útil que sea crítica para la operación de mi componente.

W - Cualquier cosa que ocurra que sea inusual o sospechosa, pero no necesariamente un error.

E - Errores, es decir, cosas que no deben suceder cuando las cosas funcionan como deberían.

El error más grande que veo que comete la gente es que usan en exceso cosas como V, D e I, pero nunca usan W o E. Si un error, por definición, no se supone que suceda, o debería suceder muy raramente, entonces es extremadamente Es barato para usted registrar un mensaje cuando ocurre. Por otro lado, si cada vez que alguien presiona una tecla, hace un Log.i (), está abusando del recurso de registro compartido. Por supuesto, use el sentido común y tenga cuidado con los registros de errores para cosas que están fuera de su control (como errores de red), o aquellos contenidos en bucles estrechos.

Tal vez malo

Log.i("I am here");

Bueno

Log.e("I shouldn't be here");

Con todo esto en mente, cuanto más se acerque su código a la "producción lista", más podrá restringir el nivel de registro base para su código (necesita V en alfa, D en beta, I en producción, o posiblemente incluso W en producción ) Debe revisar algunos casos de uso simples y ver los registros para asegurarse de que aún puede comprender lo que sucede a medida que aplica un filtrado más restrictivo. Si ejecuta con el filtro a continuación, aún debería poder decir qué está haciendo su aplicación, pero tal vez no obtenga todos los detalles.

logcat -v threadtime MyApp:I *:S

El código fuente proporciona una guía básica:

El orden en términos de verbosidad, de menor a mayor es ERROR, WARN, INFO, DEBUG, VERBOSE. Verbose nunca debe compilarse en una aplicación, excepto durante el desarrollo. Los registros de depuración se compilan pero se eliminan en tiempo de ejecución. Los registros de errores, advertencias e información siempre se mantienen.

Para más detalles, la respuesta de Kurtis es acertada. Simplemente agregaría: No registre ninguna información de identificación personal o privada en INFOo arriba ( WARN/ ERROR) De lo contrario, los informes de errores o cualquier otra cosa que incluya el registro pueden estar contaminados.

Puede usar LOG como:

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)

código de ejemplo:

private static final String TAG = "MyActivity";
...
Log.i(TAG, "MyClass.getView() — get item number " + position);

Creo que el objetivo de esos diferentes tipos de registro es si desea que su aplicación básicamente auto-filtre sus propios registros. Entonces, Verbose podría ser registrar absolutamente todo lo importante en su aplicación, luego el nivel de depuración registraría un subconjunto de los registros detallados, y luego el nivel de Información registrará un subconjunto de los registros de depuración. Cuando llegues a los registros de errores, solo debes registrar cualquier tipo de error que pueda haber ocurrido. También hay un nivel de depuración llamado Fatal para cuando algo realmente golpea al ventilador en su aplicación.

En general, tiene razón, es básicamente arbitrario, y depende de usted definir lo que se considera un registro de depuración versus informativo, versus y error, etc. etc.

Aunque esta pregunta ya fue respondida, siento que faltan ejemplos en la respuesta que fue respondida.

Por lo tanto, traeré aquí lo que escribí en una publicación de blog "Niveles de registro de Android"

Verboso

Es el nivel más bajo de registro. Si quiere volverse loco con el registro, entonces vaya con este nivel. Nunca entendí cuándo usar Verbose y cuándo usar Debug. La diferencia me sonó muy arbitraria. Finalmente lo entendí una vez que me señalaron el código fuente de Android¹ "Verbose nunca debe compilarse en una aplicación, excepto durante el desarrollo". Ahora está claro para mí, siempre que esté desarrollando y desee agregar registros borrables que lo ayuden durante el desarrollo, es útil tener el nivel detallado, esto lo ayudará a eliminar todos estos registros antes de comenzar la producción.

Depurar

Es para fines de depuración. Este es el nivel más bajo que debería estar en producción. La información que está aquí es para ayudar durante el desarrollo. La mayoría de las veces deshabilitará este registro en producción para que se envíe menos información y solo habilite este registro si tiene un problema. Me gusta iniciar sesión en depurar toda la información que la aplicación envía / recibe del servidor (¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡para que no se registran las contraseñas !!! Esto es muy útil para entender si el error se encuentra en el servidor o la aplicación. También hago registros de entrada y salida de funciones importantes.

Informacion

Para mensajes informativos que resaltan el progreso de la aplicación. Por ejemplo, cuando finaliza la inicialización de la aplicación. Agregue información cuando el usuario se mueva entre actividades y fragmentos. Registre cada llamada a la API pero solo poca información como la URL, el estado y el tiempo de respuesta.

Advertencia

Cuando hay una situación potencialmente dañina.

Este registro es, en mi experiencia, un nivel complicado. ¿Cuándo tienes una situación potencialmente dañina? En general o que está bien o que es un error. Yo personalmente no uso mucho este nivel. Los ejemplos de cuando lo uso son generalmente cuando suceden varias veces. Por ejemplo, un usuario tiene una contraseña incorrecta más de 3 veces. Esto podría deberse a que ingresó la contraseña incorrectamente 3 veces, también podría deberse a que hay un problema con un personaje que no se acepta en nuestro sistema. Lo mismo ocurre con los problemas de conexión de red.

Error

Eventos de error La aplicación aún puede continuar ejecutándose después del error. Esto puede ser, por ejemplo, cuando obtengo un puntero nulo donde se supone que no debo obtener uno. Se produjo un error al analizar la respuesta del servidor. Recibí un error del servidor.

WTF (Qué terrible falla)

Fatal es para eventos de error grave que harán que la aplicación salga. En Android, lo fatal es en realidad el nivel de Error, la diferencia es que también agrega el fullstack.

El sitio web de Android Studio recientemente proporcionó (creo) algunos consejos sobre qué tipo de mensajes esperar de diferentes niveles de registro que pueden ser útiles junto con la respuesta de Kurtis:

• Detallado : muestra todos los mensajes de registro (el valor predeterminado).
• Depurar : muestra los mensajes de registro de depuración que son útiles solo durante el desarrollo, así como los niveles de mensajes más bajos en esta lista.
• Información : muestra los mensajes de registro esperados para el uso regular, así como los niveles de mensajes más bajos en esta lista.
• Advertir : muestra posibles problemas que aún no son errores, así como los niveles de mensajes más bajos en esta lista.
• Error : muestra los problemas que han causado errores, así como el nivel de mensaje más bajo en esta lista.
• Afirmar : muestra los problemas que el desarrollador espera que nunca sucedan.