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

Question

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

Answer 1

He subclase de la clase de registro a una clase llamada de seguimiento, que refleja los métodos de registro. Así que hago Trace.d (TAG, "bla") y luego dentro del método Trace.d el código sólo se ejecuta basa en una variable de clase static final llamada logging_level, que tiene los niveles 1-5 (ninguno, sólo errores, errores & advertencias , errores & advertencias & información, y todo, incluida la 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 como para eliminar de la fuente, pero debe ser retirado de la aplicación de producción, para el funcionamiento, razones de propiedad seguros e intelectuales.

Esta estructura permite que añada mucho más el registro de la aplicación, lo que hace que los problemas de depuración mucho más fácil, pero sin impacto alguno sobre 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 2

De developer.android.com:

Desactivar el registro y depuración y limpieza de datos/archivos para su liberación, que debe asegurarse de que las instalaciones de depuración estén apagados y que depurar y otra innecesaria los datos/archivos son eliminados de su proyecto de aplicación.

Elimina el atributo android: debuggable = "true" del elemento del manifiesto. Quitar ingrese archivos, archivos de seguridad y otros archivos innecesarios del proyecto de aplicación . Compruebe si hay datos privados o patentados y elimínelos como necesarios. Desactive todas las llamadas a los métodos Log en el código fuente.

Source

Answer 3

Esto me hizo revisar mi suposición de que los log.d líneas en el código de alguna manera no aparecerían en una apk autorización firmada sin la bandera depurable establecido en el manifiesto, que estaba equivocado, todavía Aparecer.

Una búsqueda rápida en lo que me llevó a la respuesta aceptada a esta pregunta: Remove all debug logging calls before publishing: are there tools to do this?

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

Answer 4

que eliminarí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 contracción estén habilitadas para la construcción solo cuando la eliminación del código sea efectiva