android.util.Log при публикации - что я могу делать / не делать

Question

У меня чертовски много Log.i Log.d Log.e в моем коде для недавнего приложения, которое я сделал.Я собираюсь опубликовать это приложение, и я на самом деле не хочу, чтобы люди видели его, когда они подключают телефон к adb, но я хочу, чтобы оно было там для моей собственной отладки.

Я хотел расширить Android.util.log и просто там есть логический переключатель, чтобы я мог просто отключить журнал при публикации и включить его при разработке, но этот класс является окончательным, я пропускаю трюк?

Не знаюочень хочу пройтись по моему коду и удалить все, правда, если худшее дойдет до худшего, я мог бы сделать глобальную замену Log для Ctrl + H для // Log, но это отстой, как ответ..d удаляется во время выполнения, но все еще запускается (теряя небольшую производительность), поэтому не запускать это будет дополнительным бонусом.

Да, так что в основном я ищу способ включить мою отладку икроме того, это может позволить мне позже сделать это предпочтением или чем-то еще, если люди захотят просмотреть его или помочь и отправить его.

Что вы, ребята, реализуете для этого?

Поблагодаритьs

Answer 1

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

Хорошая практика:

if (C.D) { Log.d(C.T, "your log text here " + foo + bar); }

Плохая практика:

YourLog.d("your log text here " + foo + bar);

// and in YourLog.java's d() method:
... { if (debugging) Log.d(tag, text); }

Первое решение очень быстрое, если константа D класса C ложна.Если у вас есть сложные строковые операции для создания вашей строки регистрации, они не будут выполнены, если отладка отключена.Компилятор может даже удалить эти операции во время компиляции, если D ложно, что может привести к нулевым накладным расходам во время выполнения.Второе (плохое) решение всегда будет собирать всю строку и вызывать метод, который не требует дополнительных затрат.

В общем, первое решение будет наилучшим.И да, я действительно называю класс и членов C, D и T (Constants / Debugging / Tag) - по соображениям производительности во время набора текста.; -)

Answer 2

Как правило, рекомендуется не включать их в код дистрибутива каким-либо образом, поскольку их необходимо будет обработать, что приведет к ненужной разрядке батареи.

Вы можете где-нибудь установить логическое значение в своем приложениичтобы указать версию вашего кода для разработки или выпуска и иметь много блоков if, проверяющих флаг и выполняющих код вашего лога или нет, но это только приводит к раздутию кода.

Вы должны избавиться от них, как только вы недольше они нужны.

Answer 3

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