Различные методы 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.
И в качестве бонуса...
Различные методы являются признаками приоритета. Поскольку вы перечислили их, они идут от наименьшего к наиболее важному. Я думаю, как конкретно вы сопоставите их с журналами отладки в вашем коде, зависит от компонента или приложения, над которым вы работаете, а также от того, как 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 в бета-версии, я в работе или, возможно, даже Ш в производстве). Вам следует пройтись по нескольким простым сценариям использования и просмотреть журналы, чтобы убедиться, что вы по-прежнему в основном понимаете, что происходит, когда применяете более ограничительную фильтрацию. Если вы используете фильтр, указанный ниже, вы все равно сможете рассказать, что делает ваше приложение, но, возможно, не получите всех подробностей.
logcat -v threadtime MyApp:I *:S
Исходный код содержит несколько основных рекомендаций:
Порядок в терминах многословия, от меньшего к большему, - это ОШИБКА, ПРЕДУПРЕЖДЕНИЕ, ИНФОРМАЦИЯ, ОТЛАДКА, ВЕРБОЗА. Подробно никогда не следует компилировать в приложение, кроме как во время разработки. Журналы отладки компилируются, но удаляются во время выполнения. Журналы ошибок, предупреждений и информации всегда сохраняются.
Для более подробной информации, ответ куртиса мертв. Я бы просто добавил: Не регистрируйте никакую личную или личную информацию на INFO или выше (WARN/ERROR). В противном случае сообщения об ошибках или что-либо еще, включающее ведение журнала, могут быть загрязнены.
Я думаю, что точка этих разных типов ведения журнала - это то, что вы хотите, чтобы ваше приложение само по себе самостоятельно отфильтровывало собственные журналы. Таким образом, Verbose может регистрировать абсолютно все, что важно в вашем приложении, тогда уровень отладки будет регистрировать подмножество подробных журналов, а затем Info-уровень будет регистрировать подмножество журналов отладки. Когда вы переходите к журналам ошибок, вы просто хотите регистрировать любые ошибки, которые могли произойти. Существует также уровень отладки, называемый Fatal, когда что-то действительно поражает поклонника вашего приложения.
В общем, вы правы, это в основном произвольно, и вам решать, что считать отладочным журналом в сравнении с информационным, против и ошибкой и т.д. и т.д.
веб-сайт Android Studio недавно (я думаю) представил некоторые рекомендации о том, какие сообщения ожидать от разных уровней журналов, которые могут быть полезны вместе с ответом Куртиса:
Вы можете использовать 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);
Несмотря на то, что на этот вопрос уже был дан ответ, я чувствую, что в ответе отсутствуют пропущенные примеры.
Поэтому я приведу здесь то, что написал в блоге "Уровни лога Android"
Многословный
Это самый низкий уровень регистрации. Если вы хотите сходить с ума от регистрации, то вы идете с этим уровнем. Я никогда не понимал, когда использовать Verbose, а когда использовать Debug. Разница звучала для меня очень произвольно. Я наконец понял это, как только мне указали на исходный код Android… "Verbose никогда не должен компилироваться в приложение, кроме как во время разработки". Теперь для меня ясно, что когда вы разрабатываете и хотите добавить удаляемые журналы, которые помогут вам в процессе разработки, полезно иметь подробный уровень, который поможет вам удалить все эти журналы, прежде чем приступить к работе.
Debug
Для отладки. Это самый низкий уровень, который должен быть в производстве. информация, которая здесь, должна помочь во время разработки. В большинстве случаев вы отключаете этот журнал в рабочей среде, чтобы отправлять меньше информации, и включайте этот журнал только в случае возникновения проблем. Мне нравится входить в систему отладки всю информацию, которую приложение отправляет/получает от сервера (будьте осторожны, чтобы не регистрировать пароли !!!). Это очень полезно, чтобы понять, лежит ли ошибка на сервере или в приложении. Я также делаю журналы входа и выхода важных функций.
Информация
Для информационных сообщений, которые освещают ход работы приложения. Например, когда инициализация приложения завершена. Добавить информацию, когда пользователь перемещается между действиями и фрагментами. Регистрируйте каждый вызов API, но только небольшую информацию, такую как URL, статус и время ответа.
Предупреждение
Когда существует потенциально опасная ситуация.
Этот журнал по моему опыту сложный уровень. Когда у вас есть потенциальная вредная ситуация? В общем или что это нормально или что это ошибка. Я лично не использую этот уровень много. Примеры, когда я использую это, обычно, когда вещи происходят несколько раз. Например, у пользователя неправильный пароль более 3 раз. Это может быть из-за того, что он неправильно ввел пароль 3 раза, а также из-за того, что существует проблема с символом, который не принимается в нашей системе. То же самое касается проблем с сетевым подключением.
ОшибкаСобытия ошибок. Приложение может продолжать работать после ошибки. Это может быть, например, когда я получаю нулевой указатель, где я не должен его получить. При анализе ответа сервера произошла ошибка. Получена ошибка с сервера.
WTF (Какой ужасный провал)
Неустранимый для серьезных ошибок, которые приведут к выходу приложения. В Android фатальным на самом деле является уровень ошибок, разница в том, что он также добавляет полный стек.
Log и все его методы очень хорошо объяснены в документации для разработчиков Android