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

各タイプのロギングを使用する適切な状況は何ですか？多分それは意味論のほんの少しでおそらく多分それは重要ではないことを知っていますが、LogCatAndroid StudioとEclipseでのフィルタリングのために、適切なときに適切なメソッドを使用していることを知っておくとよいでしょう。

逆の順序で行きましょう：

• Log.e：これは、悪いことが起こったときのためのものです。このタグは、catchステートメント内などの場所で使用します。エラーが発生したことがわかっているため、エラーをログに記録しています。

• Log.w：怪しいことが起こっていると思われる場合に使用します。エラーモードでは完全に完全ではない可能性がありますが、予期しない動作から回復した可能性があります。基本的に、これを使用して、予期しないものをログに記録しますが、必ずしもエラーではありません。「ちょっと、これは起こりました、そしてそれは奇妙です、私たちはそれを調査する必要があります」のようなものです。

• Log.i：これを使用して、有用な情報をログに投稿します。例：サーバーに正常に接続したこと。基本的には、成功を報告するために使用します。

• Log.d：これをデバッグ目的で使用します。プログラムの正確なフローをログに記録できるように一連のメッセージを出力する場合は、これを使用します。変数値のログを保持したい場合は、これを使用してください。

• Log.v：これは、ログを完全に変更したい場合に使用します。なんらかの理由で、アプリの特定の部分にあるすべての小さなことを記録することにした場合は、Log.vタグを使用します。

そしておまけとして...

• Log.wtf：何かが絶対に、ひどく、ひどく間違っているときにこれを使用します。あなたが得るべきではないエラーをキャッチしているそれらのcatchブロックを知っています...ええ、それらをログに記録したい場合は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

ソースコードはいくつかの基本的なガイダンスを提供します：

冗長性の観点からの順序は、最低、最高の順に、ERROR、WARN、INFO、DEBUG、VERBOSEです。開発中を除いて、詳細をアプリケーションにコンパイルしないでください。デバッグログはコンパイルされますが、実行時に削除されます。エラー、警告、情報ログは常に保持されます。

詳細については、Kurtisの答えはまだ出ていない。追加するだけです：個人を特定できる情報や個人情報を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はアプリで重要なすべてのものをログに記録し、デバッグレベルは詳細ログのサブセットを記録し、情報レベルはデバッグログのサブセットを記録します。エラーログにたどり着いたら、発生した可能性のあるあらゆる種類のエラーをログに記録したいだけです。何かが本当にアプリのファンに当たったときのためのFatalと呼ばれるデバッグレベルもあります。

一般に、あなたは正しいです、それは基本的に任意であり、デバッグログと見なされるものと情報、対とエラーなどと見なされるものを定義するのはあなた次第です。

この質問はすでに回答されていますが、回答された回答には例が不足しているように感じます。

そこで、ブログ投稿「Android Log Levels」で書いたことをここに持ってきます

冗長

ロギングの最低レベルです。伐採に夢中になりたいなら、あなたはこのレベルに行きます。Verboseを使用する場合とDebugを使用する場合を理解できませんでした。その違いは非常に恣意的に聞こえました。Androidのソースコードを指されたとき、ようやくそれを理解しました。開発中に、削除可能なログを追加して開発中に役立つ場合は、詳細レベルにしておくと、本番環境に入る前にこれらのログをすべて削除できるので便利です。

デバッグ

デバッグ用です。これは、本番環境での最低レベルです。ここにある情報は、開発中に役立つものです。ほとんどの場合、本番環境ではこのログを無効にして、送信される情報が少なくなるようにし、問題がある場合にのみこのログを有効にします。ログインしてアプリがサーバーとの間で送受信するすべての情報をデバッグします（パスワードをログに記録しないように注意してください!!!）。これは、バグがサーバーとアプリのどちらにあるかを理解するのに非常に役立ちます。また、重要な機能の出入りのログも作成しています。

情報

アプリケーションの進行状況を強調する情報メッセージ。たとえば、アプリの初期化が終了したとき。ユーザーがアクティビティとフラグメントの間を移動するときに情報を追加します。各API呼び出しをログに記録しますが、URL、ステータス、応答時間などの情報はほとんど記録しません。

警告

潜在的に有害な状況がある場合。

このログは、私の経験ではトリッキーなレベルです。潜在的に有害な状況はいつありますか？一般的に、または問題がないか、エラーである。個人的にはこのレベルはあまり使いません。私がそれを使用する例は、通常、何かが何度も発生する場合です。たとえば、ユーザーが間違ったパスワードを3回以上持っています。これは、パスワードを3回誤って入力したことが原因である可能性があります。また、システムで受け入れられない文字に問題があるためである可能性もあります。ネットワーク接続の問題についても同様です。

エラー

エラーイベント。エラー後もアプリケーションは引き続き実行できます。これは、たとえば、私が取得するはずのないnullポインターを取得した場合です。サーバーの応答の解析中にエラーが発生しました。サーバーからエラーが発生しました。

WTF（ひどい障害）

Fatalは、アプリケーションを終了させる重大なエラーイベント用です。Androidでは、致命的なのは実際にはエラーレベルです。違いは、フルスタックも追加されることです。

Androidのスタジオのウェブサイトは、最近（と思う）カーティスの答えと一緒に有用である可能性があるさまざまなログレベルから期待するメッセージの種類をいくつかのアドバイスを提供してきました。

• 詳細 -すべてのログメッセージを表示します（デフォルト）。
• デバッグ -開発中にのみ役立つデバッグログメッセージと、このリストの下のメッセージレベルを表示します。
• 情報 -通常の使用で予想されるログメッセージと、このリストの下位のメッセージレベルを表示します。
• 警告 -まだエラーになっていない可能性のある問題と、このリストの下のメッセージレベルを表示します。
• エラー - エラーの原因となった問題と、このリストの下のメッセージレベルを表示します。
• アサート -開発者が決して起こしてはならないことを期待する問題を示します。