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

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.