2010-09-22 10 views
18

No estoy del todo seguro de lo que estoy leyendo en la documentación. ¿Está bien dejar un montón de trozos de código logd distribuidos, o debería comentarlos para que no afecten el rendimiento de mi aplicación?Log.d e impacto en el rendimiento

Gracias,

Estoy un poco confundido porque si usted lee sobre el objeto de registro (documentation) ve esto:

"El orden en términos de nivel de detalle, de menos a más es ERROR, WARN, INFO, depurar, VERBOSE. detallado nunca debe ser compilado en una aplicación excepto durante el desarrollo. Los registros de depuración se compila pero despojaron a los registros de tiempo de ejecución. error, de aviso y de información se mantienen siempre. "

Casi sonaba como si estuviera bien dejar mensajes de depuración allí porque están "despojados". De todos modos, gracias por las respuestas, las comentaré cuando haya terminado. No es como si los necesita allí una vez que se completa la aplicación.

Gracias

+1

Además de afectar el rendimiento de su aplicación, pueden dificultar la depuración de otras personas. El registro solo tiene 64 KB, por lo que cada vez que agrega un mensaje de registro, otro mensaje se aleja de la parte superior. – fadden

Respuesta

14

El registro tiene un impacto en el rendimiento, por lo que se recomienda comentarlo o iniciar sesión con instrucciones condicionales.

Por ejemplo

public class MyActivity extends Activity { 
// Debugging 
private static final String TAG = "MyApp"; 
private static final boolean D = true; 
@Override 
public void onCreate(Bundle savedInstanceState) { 
    super.onCreate(savedInstanceState); 
    if(D) Log.e(TAG, "MyActivity.onCreate debug message"); 
} 

Luego en cuando publica su versión acaba de cambiar "D" en false

+3

¿Por qué no se establece depurable = false para inhabilitar la depuración de aplicación: anticafe

+11

@ anticafe Porque si, por ejemplo, haces una concatenación en una declaración de Log, aún se ejecutará (causando asignaciones innecesarias). La configuración 'debuggable = false' solo asegura que no terminará en el registro. Los métodos seguirán siendo llamados. – yydl

+0

Mejor aún, use Proguard para quitar todos los registros del código. –

3

Definitivamente comentarlas. Se suman rápidamente y pueden ralentizar notablemente su aplicación, especialmente si los tiene en bucles.

8

Mi solución:

+0

de lejos la mejor solución en mi humilde opinión - no contamina el código en absoluto :) – manmal

+0

pero luego no se puede volver a activar – likejiujitsu

2

Simplemente use los métodos de protección de código.

if (Log.isLoggable(LOG_TAG, Log.DEBUG)) { 
Log.d(LOG_TAG, "Your log here"); 
} 
+0

Incluso este control tiene implicaciones de rendimiento. Acabo de ejecutar Traceview y Log.isLoggable() toma 5 ms de tiempo de CPU/llamada y casi 11 ms de tiempo real/llamada. –

+0

Tienes razón. Pero mucho mejor que escribir una información de registro en el disco. Y el nivel se puede configurar a través de las configuraciones del servidor. – gconcon

+0

Definitivamente es mejor que escribir en el disco, pero no es bueno si intenta renderizar marcos a 60 fps consistentemente. Se está sacando un buen pedazo de esos 16.7ms por cuadro. –

Cuestiones relacionadas