mensajes - logger android

¿Debo comentar mis llamadas de registro al crear mi paquete final?

Question

Tengo una aplicación que utiliza una gran cantidad de Log.d() o Log.e() para la depuración. Ahora quiero crear mi paquete final para su lanzamiento. La función de exportación de Android de Eclipse menciona la eliminación de la "Debuggable" en el manifiesto, lo que he hecho. ¿Debo también comentar todas las llamadas de Log para mejorar el rendimiento de mi aplicación o estas llamadas no harán nada en el paquete de la versión final no se puede depurar?

Answer 1

Desde developer.android.com:

Desactive el registro y la depuración y limpie los datos / archivos Para su publicación, debe asegurarse de que las funciones de depuración estén desactivadas y que la depuración y otros datos / archivos innecesarios se eliminen de su proyecto de aplicación.

Elimine el atributo android: debuggable = "true" del elemento del manifiesto. Elimine los archivos de registro, los archivos de copia de seguridad y otros archivos innecesarios del proyecto de la aplicación. Compruebe si hay datos privados o propietarios y elimínelos según sea necesario. Desactive las llamadas a los métodos de registro en el código fuente.

Source

Answer 2

Esto me hizo verificar mi suposición de que las líneas log.d en el código de alguna manera no aparecerían en una versión de lanzamiento firmada sin el indicador de depuración establecido en el manifiesto, estaba equivocado , todavía aparecen.

Una búsqueda rápida en SO me llevó a la respuesta aceptada a esta pregunta: eliminar todas las llamadas de registro de depuración antes de publicar: ¿hay herramientas para hacer esto?

Funciona muy bien y no tienes que cambiar ningún código.

Answer 3

He subclasificado la clase Log a una clase llamada Trace, que refleja los métodos en Log. Así que hago Trace.d (TAG, "blah") y luego, dentro del método Trace.d, el código solo se ejecuta en base a una variable de clase final estática llamada LOGGING_LEVEL, que tiene niveles 1-5 (ninguno, solo errores, errores y advertencias , errores y advertencias e información, y todo lo que incluye depuración). Al producir un APK de producción, Proguard elimina todo el código que no se utiliza en la aplicación, por lo que lo hace por mí.

Para mí, el registro es demasiado importante para eliminarlo de la fuente, pero debe eliminarse de la aplicación de producción, por razones de rendimiento, seguridad y propiedad intelectual.

Esta estructura me permite agregar mucho MÁS registro a la aplicación, lo que hace que los problemas de depuración sean mucho más fáciles, pero sin ningún impacto en la producción APK

public class Trace
{
public static final int NONE = 0;
public static final int ERRORS_ONLY = 1;
public static final int ERRORS_WARNINGS = 2;
public static final int ERRORS_WARNINGS_INFO = 3;
public static final int ERRORS_WARNINGS_INFO_DEBUG = 4;
private static final int LOGGING_LEVEL = ERRORS_ONLY; // Errors + warnings + info + debug (default)
public static void e(String tag, String msg)
{
if ( LOGGING_LEVEL >=1) Log.e(tag,msg);
}
public static void e(String tag, String msg, Exception e)
{
if ( LOGGING_LEVEL >=1) Log.e(tag,msg,e);
}
public static void w(String tag, String msg)
{
if ( LOGGING_LEVEL >=2) Log.w(tag, msg);
}
public static void i(String tag, String msg)
{
if ( LOGGING_LEVEL >=3) Log.i(tag,msg);
}
public static void d(String tag, String msg)
{
if ( LOGGING_LEVEL >=4) Log.d(tag, msg);
}
}

Answer 4

Quitaría el código de registro de la siguiente manera:

-assumenosideeffects class android.util.Log {
public static boolean isLoggable(java.lang.String, int);
public static int v(...);
public static int i(...);
public static int w(...);
public static int d(...);
public static int e(...);
public static java.lang.String getStackTraceString(java.lang.Throwable);
}
-assumenosideeffects class java.lang.Exception {
public void printStackTrace();
}
-assumenosideeffects class * implements org.slf4j.Logger {
public void trace(...);
public void debug(...);
public void info(...);
public void warn(...);
public void error(...);
public boolean isTraceEnabled(...);
public boolean isDebugEnabled(...);
public boolean isInfoEnabled(...);
public boolean isWarnEnabled(...);
public boolean isErrorEnabled(...);
}

Si es necesario, se pueden conservar las categorías de error y advertencia. Pero asegúrese de que la optimización y la reducción estén habilitadas solo para la compilación, de modo que la eliminación del código sea efectiva.