Join FlipAndroid.COM Telegram Group: https://t.me/joinchat/F_aqThGkhwcLzmI49vKAiw


Android Log.v (), Log.d (), Log.i (), Log.w (), Log.e () – ¿Cuándo utilizar 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 es sólo un poco de semántica y tal vez no importa, pero para el filtrado de LogCat en Android Studio y Eclipse, sería bueno saber que estoy usando los métodos adecuados en el momento adecuado.

  • ¿Limpiar automáticamente LogCat en cada depuración / ejecución de Eclipse?
  • Desactivar LogCat Salida COMPLETAMENTE en la versión de Android app?
  • Inhabilitar Logcat (DDMS) y ejecutar la consola de apertura automática en cualquier actividad
  • Evitar que el filtro de sesión de LogCat le robe el foco
  • Android Studio: ¿qué está causando los logs de la fuente de alimentación de la batería logcat?
  • Logcat rellenado con java.io.IOException: Mensajes de rechazo de conexión
  • Sobre poblar Logcat hace que las ventanas se congelen, hasta que se realice el reinicio duro
  • ¿Qué regex se puede utilizar para filtrar dalvikvm y dalvikvm-heap mensajes desde el logcat
  • 5 Solutions collect form web for “Android Log.v (), Log.d (), Log.i (), Log.w (), Log.e () – ¿Cuándo utilizar cada uno?”

    Vamos en orden inverso:

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

    • Log.w : Utilice esto cuando usted sospecha que algo shady está sucediendo. Es posible que no esté completamente en modo de error, pero tal vez se recuperó de un comportamiento inesperado. Básicamente, utilice esto para registrar cosas que no esperaba que sucedieran, pero no es necesariamente un error. Un poco como un "hey, esto sucedió, y es raro, debemos investigarlo".

    • Log.i : Utilícelo para publicar información útil en el registro. Por ejemplo: que se ha conectado correctamente a un servidor. Básicamente utilizarlo para informar sobre los éxitos.

    • Log.d : Utilice esto para propósitos de depuración. Si desea imprimir un montón de mensajes para que pueda registrar el flujo exacto de su programa, utilice esto. Si desea mantener un registro de los valores de las variables, utilice esto.

    • Log.v : Utilice esto cuando quiera ir absolutamente loco con su registro. Si por alguna razón has decidido registrar cada pequeña cosa en una parte particular de tu aplicación, usa la etiqueta Log.v.

    Y como un bono …

    • Log.wtf : Usa esto cuando las cosas van absolutamente, horriblemente, santo-mierda mal. Usted sabe esos bloques de la captura en donde usted está cogiendo errores que usted nunca debe conseguir … sí, si usted desea registrarlos utiliza Log.wtf

    Los diferentes métodos son indicaciones de prioridad. Como usted los ha enumerado, van del menos a más importante. Creo que la forma en que los mapeas específicamente para depurar registros en tu código depende del componente o la aplicación en la que estés trabajando, así como de cómo Android los trata en diferentes estilos de construcción (eng, userdebug y usuario). He hecho una buena cantidad de trabajo en los daemons nativos en Android, y así es como lo hago. Es posible que no se aplique directamente a su aplicación, pero puede haber alguna base común. Si mi explicación es 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, asegurarse de que usted puede razonablemente depurar su componente sin matar el rendimiento del sistema, y ​​siempre comprobar si hay errores y registrarlos.

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

    D – Detalles de eventos secundarios que ocurren dentro de mi componente, así como cargas útiles de mensajes / eventos que mi componente recibe o envía.

    I – El encabezado de cualquier mensaje / evento que mi componente recibe o envía, así como cualquier pieza 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 se supone que suceden cuando las cosas están funcionando como deberían.

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

    Quizás malo

     Log.i("I am here"); 

    Bueno

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

    Con todo esto en mente, cuanto más cerca de su código llegue a "producción lista", más se puede restringir el nivel de registro base de su código (se necesita V en alfa, D en beta, I en la producción, o incluso W en la producción ). Debe ejecutar a través de algunos casos de uso simples y ver los registros para asegurarse de que todavía se puede entender sobre todo lo que está sucediendo a medida que aplican el filtrado más restrictivo. Si se ejecuta con el filtro de abajo, todavía debe ser capaz de decir lo que su aplicación está haciendo, pero tal vez no obtener todos los detalles.

     logcat -v threadtime MyApp:I *:S 

    El código fuente proporciona algunas orientaciones básicas:

    El orden en términos de verbosidad, de menos a la mayoría es ERROR, WARN, INFO, DEBUG, VERBOSE. La verbosidad nunca debe ser compilada 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 error, advertencia e información se guardan siempre.

    Para más detalles, la respuesta de Kurtis está muerta. Sólo añadiría: No registre ninguna información privada o personalmente identificable en INFO o superior (WARN / ERROR). De lo contrario, los informes de errores o cualquier otra cosa que incluya el registro puede estar contaminado.

    Creo que el punto de los diferentes tipos de registro es si desea que su aplicación básicamente auto filtro de sus propios registros. Por lo tanto, Verbose podría registrar absolutamente todo lo importante en su aplicación, entonces el nivel de depuración registraría un subconjunto de los registros detallados y, a continuación, el nivel Info registrará un subconjunto de los registros de depuración. Cuando llegue a los registros de errores, sólo desea registrar cualquier tipo de errores que puedan 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, tienes razón, es básicamente arbitrario, y depende de ti definir lo que se considera un registro de depuración frente a información, contra y error, etc., etc.

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

    • Verbose – Mostrar todos los mensajes de registro (el valor predeterminado).
    • Depurar : muestra los mensajes de registro de depuración que son útiles sólo durante el desarrollo, así como los niveles de mensajes inferiores en esta lista.
    • Info – Muestra los mensajes de registro esperados para uso regular, así como los niveles de mensajes inferiores en esta lista.
    • Advertir – Mostrar posibles problemas que aún no sean errores, así como los niveles de mensajes inferiores en esta lista.
    • Error : muestra los problemas que han causado errores, así como el nivel de mensaje inferior en esta lista.
    • Assert : muestra los problemas que el desarrollador espera que nunca sucedan.
    FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.