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입니다. 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를 언제 사용하고 언제 언제 디버그를 사용해야하는지 이해하지 못했습니다. 그 차이는 매우 임의적이었습니다. Android¹의 소스 코드를 지적한 후에 마침내 그것을 이해했습니다. 이제는 개발 중이고 개발 중에 도움이되는 삭제 가능한 로그를 추가 할 때마다 자세한 수준을 갖는 것이 유용합니다.이 레벨은 프로덕션에 들어가기 전에 모든 로그를 삭제하는 데 도움이됩니다.

디버그

디버깅 목적입니다. 프로덕션 환경에서 가장 낮은 수준입니다. 여기있는 정보는 개발 중에 도움이됩니다. 대부분의 경우 프로덕션에서이 로그를 비활성화하여 더 적은 정보가 전송되도록하고 문제가있는 경우에만이 로그를 활성화합니다. 앱이 서버에서 보내거나받는 모든 정보를 디버그로 로그인하고 싶습니다 (암호를 기록하지 않도록주의하십시오 !!!). 이는 버그가 서버 또는 앱에 있는지 이해하는 데 매우 유용합니다. 또한 중요한 기능의 출입을 기록합니다.

정보

응용 프로그램의 진행 상황을 강조하는 정보 메시지. 예를 들어 앱 초기화가 완료된 경우입니다. 사용자가 활동과 조각 사이를 이동할 때 정보를 추가하십시오. 각 API 호출을 기록하지만 URL, 상태 및 응답 시간과 같은 정보는 거의 없습니다.

경고

잠재적으로 해로운 상황이있을 때.

이 로그는 제 경험상 까다로운 수준입니다. 잠재적으로 위험한 상황은 언제입니까? 일반적으로 또는 정상이거나 오류입니다. 나는 개인적으로이 수준을 많이 사용하지 않습니다. 내가 그것을 사용할 때의 예는 보통 물건이 여러 번 일어날 때입니다. 예를 들어, 사용자의 비밀번호가 3 번 이상 잘못되었습니다. 암호를 3 번 ​​잘못 입력했거나 시스템에서 허용되지 않는 문자에 문제가 있기 때문일 수 있습니다. 네트워크 연결 문제도 마찬가지입니다.

오류

오류 이벤트 오류 후에도 응용 프로그램을 계속 실행할 수 있습니다. 예를 들어 null 포인터를 얻지 않아야 할 경우 널 포인터를 얻을 수 있습니다. 서버 응답을 구문 분석하는 중에 오류가 발생했습니다. 서버에서 오류가 발생했습니다.

WTF (정말 끔찍한 실패)

치명적은 응용 프로그램을 종료시키는 심각한 오류 이벤트입니다. 안드로이드에서 치명적은 실제로 오류 수준이며, 차이점은 풀 스택을 추가한다는 것입니다.

안드로이드 스튜디오 웹 사이트 (내 생각)이 종류의 메시지의 커티스 '대답과 함께 유용 할 수있는 다른 로그 수준에서 무엇을 기대하는 몇 가지 조언을 제공 최근있다 :

• 상세 -모든 로그 메시지를 표시합니다 (기본값).
• 디버그 -개발 중에 만 유용한 디버그 로그 메시지와이 목록의 낮은 메시지 레벨을 표시합니다.
• 정보 -이 목록에서 낮은 메시지 수준뿐만 아니라 정기적 인 사용을 위해 예상되는 로그 메시지를 표시합니다.
• 경고 -아직 오류가 아닌 가능한 문제와이 목록의 메시지 수준이 낮습니다.
• 오류 -이 목록에서 낮은 메시지 수준뿐만 아니라 오류를 일으킨 문제를 표시합니다.
• Assert- 개발자가 절대 발생하지 않아야 할 문제를 보여줍니다.