Czy powinienem skomentować mój log wywołania podczas tworzenia mojego ostatecznego pakietu?

Question

Mam aplikację, która używa wielu wywołań Log.d() lub Log.e() do debugowania. Teraz chcę stworzyć mój ostateczny pakiet do wydania. Funkcja eksportu systemu Android z Eclipse wspomina o usunięciu flagi "Debuggable" w manifeście, który zrobiłem. Czy powinienem również skomentować wszystkie połączenia Log w celu poprawy wydajności mojej aplikacji, czy te połączenia nie będą działały w pakiecie końcowym bez debugowania?

Answer 1

Podklasowałem klasę Log do klasy o nazwie Trace, która odzwierciedla metody w dzienniku. Robię więc Trace.d (TAG, "bla"), a następnie w metodzie Trace.d kod wykonuje się tylko na podstawie statycznej zmiennej klasy końcowej o nazwie LOGGING_LEVEL, która ma poziomy 1-5 (brak, tylko błędy, błędy & ostrzeżenia , błędy & ostrzeżenia & info i wszystko w tym debugowanie). Podczas tworzenia produkcyjnego pliku APK program Proguard usuwa cały kod, który nie jest używany w aplikacji, więc robi to za mnie.

Dla mnie rejestrowanie jest zbyt ważne, aby usunąć je ze źródła, ale musi zostać usunięte z aplikacji produkcyjnej, ze względu na wydajność, bezpieczeństwo i własności intelektualnej.

Taka struktura pozwala mi dodać dużo więcej logowania do aplikacji, która sprawia problemy debugowania dużo łatwiej, ale z żadnego wpływu na produkcję 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

Od developer.android.com:

Wyłącz rejestrowanie i debugowanie i oczyścić dane/pliki do zwolnienia, należy upewnić się, że obiekty debugowania są wyłączone i że debugowania i inne niepotrzebne Dane/pliki są usuwane z projektu aplikacji .

Usuń atrybut android: debuggable = "true" z elementu manifestu w postaci . Usuń pliki dziennika , pliki kopii zapasowych i inne niepotrzebne pliki z projektu aplikacji . Sprawdź poufne dane prywatne lub i usuń je jako wymagane . Dezaktywuj wszystkie wywołania metod Log w kodzie źródłowym.

Source

Answer 3

To sprawiło mi sprawdzić moje założenie, że log.d linie kodu, który jakoś nie pojawiają się na podpisanym apk uwalnianiu bez debuggable flag set w manifeście, myliłem, nadal zjawić się.

Szybkie wyszukiwanie na SO doprowadziło mnie do zaakceptowanej odpowiedzi na to pytanie: Remove all debug logging calls before publishing: are there tools to do this?

działa bardzo dobrze i nie trzeba zmieniać żadnego kodu.

Answer 4

Chciałbym usunąć jak poniższy kod logowania:

-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(...); 
} 

W razie potrzeby kategorie błędów i ostrzeżeń mogą zostać zachowane.Ale upewnij się, że optymalizacja i zmniejszanie jest włączone tylko dla kompilacji, a następnie usunięcie kodu jest skuteczne