Должен ли я комментировать мои журналы вызовов при создании моего окончательного пакета? - PullRequest
Новая
       32

Должен ли я комментировать мои журналы вызовов при создании моего окончательного пакета?

21 голосов
/ 10 февраля 2011

У меня есть приложение, которое использует много вызовов Log.d() или Log.e() для отладки.Теперь я хочу создать свой окончательный пакет для выпуска.Функция экспорта Android из Eclipse упоминает об удалении флага "Debuggable" в манифесте, что я и сделал.Должен ли я также прокомментировать все вызовы Log, чтобы повысить производительность моего приложения, или эти вызовы ничего не сделают в неотлаживаемом пакете окончательной версии?

Ответы [ 4 ]

18 голосов
/ 10 февраля 2011

Я подклассифицировал класс Log к классу Trace, который отражает методы в Log.Поэтому я делаю Trace.d (TAG, «бла»), а затем внутри метода Trace.d код выполняется только на основе статической конечной переменной класса LOGGING_LEVEL, которая имеет уровни 1-5 (нет, только ошибки, ошибки и предупреждения)., ошибки и предупреждения и информация, и все, включая отладку).При создании рабочего APK Proguard удаляет весь код, который не используется в приложении, поэтому он делает это для меня.

Для меня ведение журнала слишком важно, чтобы удалить его из источника, но оно должнобыть удаленным из производственного приложения по соображениям производительности, безопасности и интеллектуальной собственности.

Эта структура позволяет мне добавить в приложение гораздо больше записей, что значительно облегчает проблемы отладки, но никак не влияет напроизводство 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);
    }

}
8 голосов
/ 10 февраля 2011

Это заставило меня проверить мое предположение о том, что строки log.d в коде как-то не будут отображаться в apk с подписанным выпуском без установленного в манифесте флага отладки, Я ошибся , они все еще появляются.

Быстрый поиск по SO привел меня к принятому ответу на этот вопрос: Удалите все вызовы журнала отладки перед публикацией: есть ли инструменты для этого?

Это работаеточень хорошо, и вам не нужно менять код.

4 голосов
/ 10 февраля 2011

От developer.android.com:

Отключите ведение журнала, отладку и очистку данных / файлов. следует убедиться, что средства отладки выключены и отладки и другие ненужные данные / файлы удалено из вашего проекта приложения.

Удалить андроид: debuggable = "true" атрибут из элемент манифеста. Удалить журнал файлы, резервные копии файлов и другое ненужные файлы из приложения проект. Проверить для частного или проприетарные данные и удалить их как необходимо. Отключить любые звонки в журнал методы в исходном коде.

Источник

2 голосов
/ 12 мая 2015

Я бы удалил код регистрации, как показано ниже: 

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

При необходимости категории ошибок и предупреждений могут быть сохранены.Но убедитесь, что оптимизация и сжатие включены для сборки только тогда, когда удаление кода будет эффективным

...