Photo by Lewis Kang'ethe Ngugi on Unsplash 안드로이드 개발을 하다보면 간단히 Stacktrace로 버그를 찾아내어 수정할 수 있는 경우도 많지만, 알 수 없는 문제로 고생하는 경우도 많다. 그럴 경우 다양한 경로로 해당 원인을 분석하기 위해 노력해야 하는데, 그러한 노력의 일환으로 dumpstate 로그를 추출하여 확인하는 것이 있다. 공식적인 명칭으로는 버그리포트 혹은 버그신고 로그라고 한다. 일반적인 개발 용어로는 덤프로그가 조금 더 익숙하여 이 포스팅에서는 이렇게 용어를 기록하였다. 로그 추출하기당연하겠지만, 우선 디바이스를 디버깅 연결한다. 그러면 아래와 같이 기기가 잘 연결되어 있을 것이다.(아래와 같은 경우는 무선디버깅으로 연결할 경우 나오는 내용이다.) 디바이스 연결을 먼저 확인그리고 다음과 같이 커맨드 명령을 입력해준다. 그렇게하면 현 시점 기준으로 버그리포트를 위한 파일이, 입력한 이름의 zip 파일로 생성된다. 생성되는데 걸리는 시간은 고사양폰 기준으로 보더라도 약 3분정도는 걸리는 것 같다. 이렇게 입력하면 파일이 생성되는 것이 보인다나오는 파일의 구성은 대략 아래와 같으며, 특징으로는 메인이 되는 로그파일을 보면 용량이 수십메가 이상은 된다는 점이다. 이 경우는 30메가이지만, 적은 용량이라고 볼 수 있다위에서 bugreport-* 형식으로 되어있는 파일을 선택하면 되며, Android OS 버전에 따라서는 파일 이름이 다른 형식으로 나올 수 있지만, 용량이 수십메가쯤 되는 파일을 선택하면, 내부에는 비슷한 내용으로 구성되어 있을 것이기 때문에 어렵지 않게 찾을 수 있을 것이다. 로그 읽기해당 파일을 Visual Studio Code와 같이 텍스트 에디터로 열면 된다. 이 문서에서 모든 부분을 언급할 수는 없겠지만, 참고가 될만한 부분을 기록하자면 다음과 같다. 시스템 로그logcat 로그는 모든 logcat 정보의 문자열 기반 덤프이다. system 부분은 프레임워크를 위해 예약되었으며, 다른 모든 부분을 포함하는 main보다 더 긴 기록을 갖는다. 각 행은 일반적으로
순으로 되어있지만, 버전에 따라서는 UID가 없을 수도 있다. 아래의 예시의 내용에서처럼 'SYSTEM LOG'를 키워드로 검색하면 바로 쉽게 찾을 수 있다. 혹은 system과 main 파트를 찾고 싶다면, 해당 부분도 마찬가지로 각각 beginning of system과 beginning of main으로 검색하면 된다.
이벤트 로그이벤트로그는 바이너리 형식 로그 메시지의 문자열 표현이 포함될 수 있다. 이 로그는 logcat 로그보다 노이즈는 적지만 더 읽기가 어려울 수 있다. 기본형식은
처럼 되어 있다. (V: 상세, D: 디버그, I: 정보, W: 경고, E: 에러) 아래는 그 예시이며, 동일하게 EVENT LOG를 키워드로 찾기 쉽다.
ANR(Application Not Responding) 찾기일반적으로 차단되었거나 사용량이 많은 기본 쓰레드로 인해 앱이 특정 시간내에 응답하지 않는다면, 시스템은 프로세스를 종료하고 스택을 /data/anr로 덤프한다. am_anr을 검색하면 찾을 수 있다. 다만, 이 로그는 모든 경우에 찾을 수 있는 것은 아니기 때문에 해당되는 경우가 아니라면 없을 수 있다. 아래는 나올 경우 예시이다.
ANR이 검색되었고, 해당되는 경우라면 아래와 같이 CPU를 사용하고 있는 것들에 대한 정보를 추가로 찾을 수 있다.
만약 나오지 않을 경우 아래와 같은 내용이 포함되어 있을 수 있다.
종종 ANR에 대응하는 stacktrace를 찾을 수도 있다. VM 트레이스에서 timestamp와 조사중인 ANR사이에 PID가 일치하는지 확인 한 후, 프로세스의 기본 쓰레드를 확인한다. 참고로 기본쓰레드는 ANR 발생시에 실행하고 있던 작업만 알려주는 것이므로 이는 ANR의 실제 원인일수도 있으며, 아닐 수도 있다. 또한 2개 이상의 stacktrace 세트가 있을 수 있으니 현재 보고있는 섹션이 맞는지 확인을 잘 해야 한다. 나온다면 아래와 같을 것이다.
참고로 교착상태 발생시에는 다음과 같은 로그가 나올 수 있다. 다음 로그의 특징으로는 Blocked로 기록된 부분과, waiting to lock 혹은 locked라고 표현된 부분들이다.
Activity 찾기집중이 된 Activity를 찾고 싶다면 'am_focused_activity'를 검색한다. 또한 프로세스의 시작을 찾고싶다면, 'Start proc'을 찾으면 된다. 또한 기기가 쓰래싱(메모리 접근시 페이지 폴트 발생으로 CPU 이용률이 급격히 낮아지는 현상)이 발생하는 지 알아보려면 'am_proc_died'와 'am_proc_start' 주변에서 Activity가 비정상적으로 증가했는지 확인해보는것이 좋다. 아래와 같은 것이 예시가 될 것이다.
메모리 관련 찾기물리적 메모리가 제한적인 경우가 많으므로, RAM 관리가 매우 중요하다. 일단 메모리 부족을 식별하기 위해서는 앞에서 언급했던 내용처럼 'am_proc_died와 'am_proc_start' 항목이 얼마나 몰려있는지 확인하면 된다. 바이너리 이벤트 로그의 'am_low_memory' 항목은 마지막으로 캐시된 프로세스가 종료되었다는 의미이다. 그래서 이것이 발생되면, 이후에는 아래의 예시처럼 시스템이 서비스를 종료하기 시작한다.
쓰래싱 지표를 보기 위해서는 먼저 'CPU INFO' 항목을 찾는다. 이곳에서 'kswapd', 'kworker', 'mmcqd' 소비 주기가 있다. 이러한 부분들이 쓰래싱 지표에 영향을 미칠 수 있다.
ANR로그에서도 마찬가지로 유사항 스냅샷을 제공하기도 한다. 아래는 그 예시이다.
메모리 스냅샷은 'Total PSS by OOM adjustment' 키워드로 찾을 수 있다. 메모리 관련 이슈가 있을 경우에도 유용할 것이니 이 경우 잘 체크해두면 좋다. 이 경우의 예시는 아래와 같다.
이 정보로 현재 메모리 상태를 파악하는 데 도움이 될 것이다. - 프로세스가 얼마나 오랫동안 실행하는지 이해하거나 - 프로세스가 현재 실행되고 있는 이유를 이해하기 위해서는 다른 부분의 섹션을 추가로 참고해야 하는데, 해당 부분은 다음 포스팅에 기록할 예정이다. 출처- 버그 신고캡처 및 읽기: https://developer.android.com/studio/debug/bug-report?hl=ko - 버그신고 읽기: https://source.android.com/setup/contribute/read-bug-reports?hl=ko#anrs-deadlocks |