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

Los diferentes métodos de LogCat 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 solo sea un poco de semántica y tal vez no importe, pero para el filtrado de LogCat 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 sucede algo malo. Use esta etiqueta en lugares como dentro de una statement catch. Sabes que se ha producido un error y, por lo tanto, estás registrando un error.

  • Log.w : utilízalo cuando sospeches que algo sospechoso está sucediendo. Puede 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 ocurrieran, pero que no necesariamente son un error. Algo así como “hey, esto sucedió, y es extraño , deberíamos investigarlo”.

  • Log.i : use esto para publicar información útil en el registro. Por ejemplo: que se haya conectado con éxito a un servidor. Básicamente utilícelo para reportar éxitos.

  • Log.d : Use esto para depuración . Si desea imprimir un montón de mensajes para que pueda registrar el flujo exacto de su progtwig, 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 un extra …

  • Log.wtf : Usa esto cuando las cosas vayan absolutamente mal, horrorosamente, mierda santa. Conoces esos bloques de captura en los que estás detectando errores que nunca deberías obtener … sí, si quieres iniciar sesión, utiliza Log.wtf

Los diferentes métodos son indicaciones de prioridad. A medida que los enumera, van de menor a mayor importancia. Creo que la forma en que los mapee específicamente para depurar registros en su código depende del componente o la aplicación en la que esté trabajando, así como de cómo los trata Android en diferentes estilos de comstackción (eng, userdebug y user). He trabajado bastante en los demonios nativos de 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 parte de esto es más un arte que una ciencia. Mi regla básica es ser lo más eficiente posible, garantizar que puede depurar razonablemente su componente sin matar el rendimiento del sistema, y ​​siempre verificar si hay errores y registrarlos.

V – Impresiones de estado en diferentes intervalos, o sobre cualquier evento que ocurra que mi componente procese. También posiblemente impresiones muy detalladas de las cargas 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 pieza importante de la carga que sea crítica para el funcionamiento de mi componente.

W: cualquier cosa que ocurra que sea inusual o sospechosa, pero no necesariamente un error.

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

El error más grande que veo que hacen las personas es que abusan de cosas como V, D y yo, pero nunca usan W o E. Si un error es, por definición, no se supone que suceda, o debería ocurrir muy raramente, entonces es extremadamente barato para que usted registre un mensaje cuando ocurra. Por otro lado, si cada vez que alguien presiona una tecla, usted 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 ajustados.

Tal vez malo

 Log.i("I am here"); 

Bueno

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

Con todo esto en mente, cuanto más cerca esté su código de “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 ) Debería ejecutar algunos casos de uso simples y ver los registros para asegurarse de que aún puede comprender en su mayoría lo que sucede a medida que aplica un filtrado más restrictivo. Si ejecuta el filtro a continuación, aún podrá saber 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 se debe comstackr en una aplicación, excepto durante el desarrollo. Los registros de depuración se comstackn pero se eliminan en tiempo de ejecución. Los registros de error, advertencia e información siempre se guardan.

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

Creo que el objective de esos diferentes tipos de registro es si quieres que tu aplicación básicamente autofiltra sus propios registros. Así que Verbose podría 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 llegue a los registros de errores, solo desea 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 fan en tu 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.

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

  • Verbose – Muestra todos los mensajes de registro (por defecto).
  • Depurar : muestra los mensajes de registro de depuración que son útiles solo durante el desarrollo, así como los niveles de mensaje inferiores 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 los posibles problemas que aún no son errores, así como los niveles de mensaje más bajos en esta lista.
  • Error : muestra problemas que han causado errores, así como el nivel de mensaje más bajo en esta lista.
  • Assert – Muestra problemas que el desarrollador espera que nunca sucedan.

Puede usar LOG tal 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);