Comments 14
А что насчет скорости такого логировани, каков оверхед?
В рекомендациях по поводу подготовки приложения к публикации Google настойчиво рекомендует убирать из кода все вызовы логирующих методов при сборке релиза. Так что если вы следуете рекомендациям (а им разумно следовать), то скорость и оверхед не важны.
Судя по тому, сколько разных сообщений валится в logcat — мало кто следует этому правилу.
>Как правило, ценность логов начинаешь понимать только когда заказчик матерясь отсылает лог на почту и просит засабмитить фикс через 5 минут.
В данном случае логи в релизной версии видимо есть и о вопросе оверхеда стоит подумать т.к. иначе от такого логирования можно получить больше проблем, чем пользы.
В данном случае логи в релизной версии видимо есть и о вопросе оверхеда стоит подумать т.к. иначе от такого логирования можно получить больше проблем, чем пользы.
На самом деле не обязательно релизной. У заказчика может быть более десятка встреч с инвесторами о которых разработчикам становиться известно в последнюю очередь.
А по поводу оверхеда — я ответил комментарием ниже. В любом случае — никто не запрещает вывести обычный лог в том месте, где возможно требуется упор на призводительность.
А по поводу оверхеда — я ответил комментарием ниже. В любом случае — никто не запрещает вывести обычный лог в том месте, где возможно требуется упор на призводительность.
Статья давняя, набрел на нее после изобретения такого же велосипеда.
По ссылке информация внизу для чего какой лог подойдет с комментариями.
Любой вызов метода будет произведен, но не виден в LogCat при определенных обстоятельствах (релизная версия и т.д.)
Также pro-guard отлично справялетя (ссылка) с выкашиванием логов при релизе.
Отмечу, что перекрывать название системного класса — плохой тон, лучше назовите свой класс для логирования LogUtil.
По ссылке информация внизу для чего какой лог подойдет с комментариями.
Любой вызов метода будет произведен, но не виден в LogCat при определенных обстоятельствах (релизная версия и т.д.)
Также pro-guard отлично справялетя (ссылка) с выкашиванием логов при релизе.
Отмечу, что перекрывать название системного класса — плохой тон, лучше назовите свой класс для логирования LogUtil.
Обычно его можно минимизировать в релизе за счет использования конструкции if (log.isInfoEnabled).
Если в андроидовском SDK такие методы не предусмотрены, стоит написать свой wrapper наподобие того, что сделал автор, и реализовать там эту функциональность.
Если в андроидовском SDK такие методы не предусмотрены, стоит написать свой wrapper наподобие того, что сделал автор, и реализовать там эту функциональность.
В своем случае я чуть исправил данный класс, добавил в него возможность быстрого отключения всех логов, изменением boolean переменной и использования его в коде только заменой импорта, что бы не переписывать все логи, получилось удобно.
Автору спасибо, сам хотел написать такой класс, но все руки не доходили.
Автору спасибо, сам хотел написать такой класс, но все руки не доходили.
Я просто оставлю это здесь: «Реализовали описанное решение в виде jar-библиотеки: https://github.com/noveogroup/android-logger. Делает всё то, что написано в статье плюс ещё можно конфигурировать формат вывода логов, централизованно отключать и т.д. Кроме всего прочего совместима с SLF4J, что тоже хорошо»
Этот метод для любой явы вполне годится, не только для андроида. Но его скорость вызывает сомнения.
Полностью согласен — данный метод работает медленней простого вывода сообщения.
Однако, на мой взгляд, оверхед здесь минимален — логирование открытия той или иной активити таким образом никак не скажется на быстродействии, а логирование циклов с множеством повторов выглядит, как мне кажется, вообще неоправдано — будет работать медленно при любом логировании, да и лог забъется мусором за достаточно короткое время.
Однако, на мой взгляд, оверхед здесь минимален — логирование открытия той или иной активити таким образом никак не скажется на быстродействии, а логирование циклов с множеством повторов выглядит, как мне кажется, вообще неоправдано — будет работать медленно при любом логировании, да и лог забъется мусором за достаточно короткое время.
Проверено в боевых условиях, логи дают нагрузку. На Magic разбор огромного xml с детализированным логированием 25sec, без логов — 5sec. Однако, на современных топовых устройствах эта разница не так заметна.
Обёртка вокруг стандартного Log необходима, т.к. логи нужны и средство их централизованно отключать должно быть.
Обёртка вокруг стандартного Log необходима, т.к. логи нужны и средство их централизованно отключать должно быть.
Ну этого конечно стоило ожидать. Что тут скажешь — условия условиям рознь. Не совсем правда понятна необходимость логирования разбора xml дерева. Как мне кажется, необходимо логировать только ошибки парсинга (несоответствие типов и пр.), и в случае ошибки в debug версии сбрасывать либо в файл, либо в лог сам XML для последующего анализа.
Но вам виднее конечно — надо, значит надо.
Но вам виднее конечно — надо, значит надо.
Sign up to leave a comment.
Логирование в Android приложениях