Android Log.v (), Log.d (), Log.i (), Log.w (), Log.e () - Когда использовать каждый?

Question

Существуют различные методы LogCat:

Log.v(); // Verbose
Log.d(); // Debug
Log.i(); // Info
Log.w(); // Warning
Log.e(); // Error

Какие условия подходят для использования каждого типа ведения журнала?Я знаю, что, возможно, это всего лишь небольшая семантика и, возможно, это не имеет большого значения, но для LogCat фильтрации в Android Studio и Eclipse было бы неплохо знать, что я использую подходящие методы в подходящее время.

Answer 1

Давайте пойдем в обратном порядке:

• Log.e : Это когда плохие вещи случаются.Используйте этот тег в таких местах, как внутри оператора catch.Вы знаете , что произошла ошибка , и поэтому вы регистрируете ошибку.

• Log.w : используйте, если вы подозреваете, что происходит что-то неясное.Возможно, вы не полностью работали в режиме ошибки, но, возможно, вы оправились от неожиданного поведения.В основном, используйте это, чтобы регистрировать то, чего вы не ожидали, но это не обязательно ошибка.Вроде как «эй, это случилось, и это странно , мы должны посмотреть на это».

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

• Log.d : Используйте это для отладки целей.Если вы хотите распечатать кучу сообщений, чтобы записать точный поток вашей программы, используйте это.Если вы хотите вести журнал значений переменных, используйте это.

• Log.v : Используйте это, если вы хотите перейти абсолютноорехи с вашей регистрации.Если по какой-то причине вы решили регистрировать каждую мелочь в определенной части вашего приложения, используйте тег Log.v.

И в качестве бонуса ...

• Log.wtf : используйте это, когда все идет совершенно, ужасно, нехорошо.Вы знаете те блоки перехвата, в которых вы ловите ошибки, которые вы никогда не должны получить ... да, если вы хотите их регистрировать, используйте Log.wtf

Answer 2

Различные методы являются признаками приоритета.Поскольку вы перечислили их, они идут от наименьшего к наиболее важному.Я думаю, как конкретно вы сопоставите их с журналами отладки в своем коде, зависит от компонента или приложения, над которым вы работаете, а также от того, как Android обрабатывает их в различных вариантах сборки (eng, userdebug и user).Я проделал немалую работу с нативными демонами в Android, и вот как я это делаю.Это может не относиться непосредственно к вашему приложению, но может быть какой-то общий язык.Если мое объяснение звучит расплывчато, то это потому, что это скорее искусство, чем наука.Мое основное правило - быть максимально эффективным, обеспечить разумную отладку компонента без ущерба для производительности системы, а также всегда проверять наличие ошибок и регистрировать их.

V - Распечатка состояния через различные интервалы,или при каких-либо событиях, происходящих с моим компонентом.Также возможно очень подробные распечатки полезных нагрузок сообщений / событий, которые мой компонент получает или отправляет.

D - Подробности незначительных событий, которые происходят в моем компоненте, а также полезных нагрузок сообщений / событий, которые получает мой компонент илиотправляет.

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

W - что угоднобывает, что это необычно или подозрительно, но не обязательно ошибка.

E - ошибки, означающие вещи, которые не должны происходить, когда все работает так, как должно.

Самая большая ошибкаЯ вижу, что люди делают то, что они злоупотребляют такими вещами, как V, D и I, но никогда не используют W или E. Если ошибка, по определению, не должна возникать или должна происходить очень редко, то это чрезвычайно дешево для васвойти в сообщение, когда это происходит.С другой стороны, если каждый раз, когда кто-то нажимает клавишу, вы выполняете Log.i (), вы злоупотребляете ресурсом общего ведения журнала.Разумеется, руководствуйтесь здравым смыслом и будьте осторожны с журналами ошибок для тех вещей, которые находятся вне вашего контроля (например, сетевые ошибки), или для тех, которые содержатся в жестких циклах.

Возможно, плохо

Log.i("I am here");

Хорошо

Log.e("I shouldn't be here");

Учитывая все это, чем ближе ваш код становится «готовым к работе», тем больше вы можете ограничить базовый уровень ведения журнала для вашего кода (вам нужен V в альфа, D в бета, я в производстве, или, возможно, даже W в производстве).Вам следует пройтись по нескольким простым сценариям использования и просмотреть журналы, чтобы убедиться, что вы по-прежнему в основном понимаете, что происходит, когда применяете более ограничительную фильтрацию.Если вы используете фильтр, указанный ниже, вы все равно сможете сказать, что делает ваше приложение, но, возможно, не получите всех подробностей.

logcat -v threadtime MyApp:I *:S

Answer 3

Исходный код предоставляет некоторые основные рекомендации:

Порядок в терминах многословия, от меньшего к большему, - это ОШИБКА, ПРЕДУПРЕЖДЕНИЕ, ИНФОРМАЦИЯ, ОТЛАДКА, ВЕРБОЗА. Подробно никогда не следует компилировать в приложение, кроме как во время разработки. Журналы отладки компилируются, но удаляются во время выполнения. Журналы ошибок, предупреждений и информации всегда сохраняются.

Более подробно, ответ Куртиса мертв. Я бы просто добавил: Не регистрируйте никакую личную или личную информацию на INFO или выше (WARN / ERROR). В противном случае отчеты об ошибках или что-либо еще, включающее ведение журнала, могут быть загрязнены.

Answer 4

Я думаю, что смысл этих различных типов ведения журналов заключается в том, что вы хотите, чтобы ваше приложение само фильтровало свои собственные журналы. Таким образом, Verbose может вести запись абсолютно всего важного в вашем приложении, тогда уровень отладки будет регистрировать подмножество подробных журналов, а затем уровень Info будет регистрировать подмножество журналов отладки. Когда вы переходите к журналам ошибок, вы просто хотите регистрировать любые ошибки, которые могли произойти. Существует также уровень отладки, называемый Fatal, для случая, когда что-то действительно поражает поклонника в вашем приложении.

В общем, вы правы, это в основном произвольно, и вам решать, что считать журналом отладки в сравнении с информационным, в сравнении с ошибкой и т. Д. И т. Д.

Answer 5

Несмотря на то, что на этот вопрос уже был дан ответ, я чувствую, что в ответе отсутствуют примеры, на которые дан ответ.

Поэтому я приведу здесь то, что написал в блоге "Уровни журнала Android"

Многословный

Это самый низкий уровень ведения журнала. Если вы хотите сходить с ума от регистрации, то вы идете с этим уровнем. Я никогда не понимал, когда использовать Verbose, а когда использовать Debug. Разница звучала для меня очень произвольно. Я, наконец, понял это, как только мне указали на исходный код Android… «Verbose никогда не должен компилироваться в приложение, кроме как во время разработки». Теперь мне ясно, когда вы разрабатываете и хотите добавить удаляемые журналы, которые помогут вам во время разработки. При разработке полезно иметь подробный уровень, который поможет вам удалить все эти журналы, прежде чем вы начнете работать.

Debug

Для отладки. Это самый низкий уровень, который должен быть в производстве. Информация, которая здесь, должна помочь во время разработки. В большинстве случаев вы отключаете этот журнал в рабочей среде, чтобы отправлять меньше информации, и включайте этот журнал только в случае возникновения проблем. Мне нравится входить в систему отладки всю информацию, которую приложение отправляет / получает от сервера (будьте осторожны, чтобы не регистрировать пароли !!!). Это очень полезно, чтобы понять, лежит ли ошибка на сервере или в приложении. Я также делаю журналы входа и выхода важных функций.

информация

Для информационных сообщений, которые освещают ход работы приложения. Например, когда инициализация приложения завершена. Добавить информацию, когда пользователь перемещается между действиями и фрагментами. Регистрируйте каждый вызов API, но только небольшую информацию, такую ​​как URL, статус и время ответа.

Внимание

Когда существует потенциально опасная ситуация.

Этот журнал, по моему опыту, сложный уровень. Когда у вас есть потенциальная вредная ситуация? В общем или что это нормально или что это ошибка. Лично я не пользуюсь этим уровнем много. Примеры, когда я использую это, обычно, когда вещи происходят несколько раз. Например, у пользователя неправильный пароль более 3 раз. Это может быть связано с тем, что он неправильно ввел пароль 3 раза, а также с тем, что существует проблема с персонажем, который не принимается в нашей системе. То же самое касается проблем с сетевым подключением.

Error

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

WTF (Какой ужасный провал)

Fatal - для серьезных ошибок, которые приведут к выходу приложения. В Android фатальным на самом деле является уровень ошибок, разница в том, что он также добавляет полный стек.

Answer 6

Вы можете использовать LOG, например:

Log.e(String, String) (error)
Log.w(String, String) (warning)
Log.i(String, String) (information)
Log.d(String, String) (debug)
Log.v(String, String) (verbose)

пример кода:

private static final String TAG = "MyActivity";
...
Log.i(TAG, "MyClass.getView() — get item number " + position);

Answer 7

Сайт Android Studio недавно (я думаю) предоставил несколько советов о том, какие сообщения ожидать от разных уровней журнала, которые могут быть полезны, наряду с ответом Куртиса:

• Подробно - Показать все сообщения журнала (по умолчанию).
• Debug - Показать сообщения журнала отладки, которые полезны только во время разработки, а также уровни сообщений ниже в этом списке.
• Информация - Показать ожидаемые сообщения журнала для регулярного использования, а также уровни сообщений ниже в этом списке.
• Warn - Показать возможные проблемы, которые еще не являются ошибками, а также уровни сообщений ниже в этом списке.
• Ошибка - Показать проблемы, которые вызвали ошибки, а также уровень сообщений ниже в этом списке.
• Утверждение - Показать проблемы, которые разработчик ожидает, никогда не должно происходить.