¿Log.i () afecta el rendimiento en las aplicaciones de Android?

Soy un desarrollador de la vieja escuela (OK, tengo 20 años, no soy la escuela vieja, me gusta imprimir en lugar de usar el depurador paso a paso: P) y tengo un montón de Log.i () En una aplicación de Android. Me preguntaba si tendría un impacto en el rendimiento de la aplicación?

Sé que debo usar un depurador paso a paso, es sólo que la depuración de múltiples hilos puede ser un poco engorroso.

¡Gracias por tu ayuda!

No creo que Log afectará al rendimiento de la aplicación, porque cuando se libera la aplicación, la desactiva en Android Manifest definiendo debuggable :

 <application android:icon="@drawable/icon" android:label="@string/app_name" android:debuggable="false"> 

Todavía estoy buscando en la codificación de Android, pero yo por lo que he visto hasta ahora, asumiría que el registro de Android sufre de los mismos problemas que la mayoría de los marcos de registro de Java sufren de (La notable excepción es SLF4J), a saber:

  • El registro efectúa el rendimiento porque:
    1. Significa llamadas adicionales al método. (No es un problema para el 99% de las aplicaciones).
    2. A menudo significa trabajo de ensamblaje de cuerdas (gran impacto)
    3. Se compromete extra IO (Gran impacto)

Los desarrolladores suelen lidiar con esto añadiendo bloques de guardia

 if (log.isDebugEnabled()) { log.debug("..."); } 

Creo que el SDK de Android puede hacer esto también. Cubre los # 2 y # 3, pero todavía deja su código de liberación que contiene el código de registro no utilizado. Suponiendo, por supuesto, que nunca quiera habilitar el registro de depuración en una situación de liberación.

SFL4J BTW, no requiere bloques de protección porque utiliza C como método de llamadas que retrasan el montaje de String hasta que realmente se requiere. Desafortunadamente, parece que Android no ha ido por este camino. IOS no tiene este problema ya sea porque tiene un precompilador. Algo que a menudo desearía que Java hubiera mantenido.

De todos modos, yo no abogaría por eliminar el registro a favor del depurador. IMHO sirven dos propósitos diferentes. Logging Me parece muy útil (si se hace correctamente) en la comprensión del flujo de una aplicación. He encontrado a menudo problemas mirando a través de los registros que no habría encontrado en el depurador. Es decir. Ejecución de código innecesario a través de varias clases (especialmente en clases de interfaz de usuario), problemas de datos impares que no conducen a errores, etc. En estas situaciones, usar el depurador sería como intentar poner concreto con una cuchara. Los depuradores por otra parte son perfectos para analizar los detalles finos de un problema resaltado por el registro.

Así que en mi código tienden a tener una cantidad justa de registro que está diseñado para decirme lo que la aplicación está haciendo, de manera similar a inglés para que pueda leerlo fácilmente y entender lo que está sucediendo. Pero soy bastante estricto para mantener los niveles tan bajos como sea posible. Es decir. No registre cosas en el nivel de información a menos que sea algo que quiera ver incluso en el modo de liberación. He encontrado un montón de desarrolladores tienden a romper esto.

UPDATE: Acaba de leer Eliminar todas las llamadas de registro de depuración antes de publicar: ¿hay herramientas para hacer esto? Que habla de cómo puede utilizar ProGuard para eliminar el registro de código de liberación. Gran idea, significa que no se puede molestar con los bloques de guardia en el registro y poner tanto en lo que te gusta, sin embargo, estar seguro de que su código de liberación será rápido.

Si cambia a Log.d, puede depurar su aplicación y al construir una versión de lanzamiento, ninguna de esas llamadas se compilará o ejecutará.

Sí, tiene pena de rendimiento. Compruebe esto: Log.d e impacto en el rendimiento

La respuesta es sí y no.

Depende de la cantidad de llamadas de registro que tiene y como usted está hablando de depuración de paso, supongo que no está preocupado por el código de liberación en esta etapa (cuando obviamente quitar el registro excesivo).

He utilizado el registro excesivo hasta el punto que desborda el logcat, pero sólo cuando se trata de rastrear un problema particularmente elusivo en mi código de depuración – que el registro se eliminó tan pronto como rastreé el problema hacia abajo.

En resumen, registrar todo lo que quieras en el desarrollo, pero no lo inflija en el usuario.

  • ¿Cómo depurar una aplicación de Android empezó desde 'adb shell am start -D'?
  • Tengo un error ddms No se puede enlazar a local 8602 para depurador - sin depuración para Android
  • Depuración del código Android NDK C / C ++ en Eclipse: los puntos de interrupción no se alcanzan
  • ¿Qué hay de malo en depurar en Eclipse en Android?
  • Android: automáticamente elige debug / release Maps clave api?
  • ¿Cómo puedo forzar la presión de memoria para la depuración de Android?
  • ¿Cómo se puede "Mostrar límites de diseño" para la depuración de Android?
  • Logcat no muestra mis llamadas de registro
  • ignorando el segundo depurador y la caída del servicio en android
  • Eclipse de puntos de interrupción de android eclipse
  • Galaxy S5 Lollipop - no todos los puntos de interrupción detienen la ejecución bajo Android Studio debugger
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.