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

Различные LogCatметоды:

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

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

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

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

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

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

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

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

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

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

Различные методы являются признаками приоритета. Поскольку вы перечислили их, они идут от наименьшего к наиболее важному. Я думаю, как конкретно вы сопоставите их с журналами отладки в своем коде, зависит от компонента или приложения, над которым вы работаете, а также от того, как 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 в бета-версии, I в работе или, возможно, даже W в работе ). Вам следует пройтись по нескольким простым сценариям использования и просмотреть журналы, чтобы убедиться, что вы по-прежнему в основном понимаете, что происходит, когда применяете более ограничительную фильтрацию. Если вы используете фильтр, указанный ниже, вы все равно сможете рассказать, что делает ваше приложение, но, возможно, не получите всех подробностей.

logcat -v threadtime MyApp:I *:S

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

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

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

Вы можете использовать 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);

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

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

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

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

Подробный

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

Отлаживать

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

Информация

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

Предупреждение

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

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

ошибка

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

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

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

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

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