Android Dev Summit 2019 - Debugging Tips n' Tricks

안드로이드 2019 Dev summit에서 발표된 Android studio debugging tips 관련 자료를 정리합니다.

Android logcat

1. 불필요한 시간 / TID / PID 제거

2. Filter 관리 및 등록

필요한 로그를 보기 위해서 filter를 걸거나, 여러개의 filter를 설정할수 있습니다.

하지만 자주 사용하는 Filter라면 "Edit Filter Configuration" 메뉴를 통해서 새 Filter를 등록해 놓고 사용 할 수 있는 기능을 제공합니다.

등록해 놓은 Filter는 drop 메뉴에서 바꿔가면서 선택 가능합니다.

3. 동일 로그 folding

계속해서 반복되는 로그가 있다면 해당 문자열을 드래그 하여 마우스를 우클릭하고 "Fold lines like this" 메뉴를 선택합니다.

해당 문자열의 로그는 folding되며, 원할때 펼쳐볼수 있습니다.

Breakpoint를 이용한 debugging

1. 실행중인 process에 debugging

이미 실행중인 process에 debugging 모드를 사용하려면 앱을 중지하고 다시 시작할 필요가 없습니다.

아래 아이콘을 눌러서 실행중인 process에 debugger를 붙이면 됩니다.

2. Break point condition

특정 부분에 Break point를 설정하면 해당 코드 라인을 지날때 process가 중지됩니다.

하지만 반복문이나, 수시로 실행되는 코드인 경우 에러가 발생할때까지 계속 break point를 skip하도록 수동으로 넘겨줘야 하죠..

따라서 break point가 앱을 중지시키기 위한 조건을 넣을 수 있습니다.

Break point에 마우스 우클릭후 Condition을 넣습니다.

Kotlin 또는 java로 boolean을 return하는 식을 넣을 수 있습니다.

이 식이 true일 경우 break point가 동작하면서 앱이 일시 중지 됩니다.

3. Disable until breakpoint is hit

반복되는 구문에 breakpoint를 설정한 경우, 계속해서 해당 breakpoint에서 앱이 실행을 멈춥니다.

이럴때 버그가 나올때 까지 해당 breakpoint를 skip해 주는 작업을 수동으로 해야 합니다.

만약 특정 조건이 만족하는경우에만 brea point 걸고 싶다면 breakpoint를 우클릭해서 More를 클릭합니다.

좌측에 현재 걸려있는 breakpoint가 나옵니다. 왼쪽에서 종속성을 가져야 할 breakpoint를 선택하고, 녹색 박스로 표시된 "Disable until breakpoint is hit"에서 break 하기 위한 제반조건이 되는 breakpoint를 선택합니다.

예를 들어 왼쪽에서 VoipFragment.java:1799를 클릭하여 속성중에 "Disable until breakpoint is hit"을 VoipFragment.java:1433으로 설정합니다.

이런 경우 실행중 VoipFragment.java:1433의 breakpoint가 걸려야만 VoipFragment.java:1799도 동작하게 됩니다.

4. 특정 thread stop

기본적으로 breakpoint를 만나면 전체 앱이 중단됩니다.

즉 모든 thread가 일시정지됩니다.

하지만 여러개의 멀티 thread가 동작하고 특정 thread의 버그를 디버깅 하기 위해서 breakpoint를 만나는 특정 thread만 중지하도록 설정할 수도 있습니다.

breakpoint에서 우클릭하여 나온 메뉴에 Thread를 선택하면 해당 breakpoint를 만나는 thread만 중지 됩니다.

(메인 스레드가 아니라면 breakpoint를 만나더라도 해당 thread만 일시정지되고, 여전히 app은 실행됩니다.)

5. Breakpoint inactivation

Breakpoint가 더이상 필요 없다면 해체할 수 있습니다.

하지만 일시적으로 필요없느 경우 Alt+클릭을 통해서 비활성화 시켜 놓을 수 있습니다.

Mac의 경우 option+클릭을 사용하면 됩니다.

6. Breakpoint log

Breakpoint을 만났을때 앱을 멈추는게 아니라 특정 로그를 찍도록 할수도 있습니다.

(오오오..이거 좋습니다..)

breakpoint에서 우클릭을 합니다.

Suspend의 cehck를 풀고, Log 항목에 어떤 로그를 표시할지 설정합니다.

Breakpoint를 지나갔다란 메시지만 표시할수도 있고, 특정 메시지를 찍도록 할수도 있습니다.

저는 둘다 check 했지만 둘중에 하나만 체크해도 상관없습니다.

참고로 Stack trace를 찍을수도 있네요~

전부 독립사건이니, 원하는 로그를 체크해서 사용하면 됩니다.

Suspend가 아니기 때문에 breakpoint가 주황색으로 바뀐걸 확인할 수 있습니다.

로그는 아래와 같이 나옵니다.

custom log에 넣은 변수값도 잘 표기되는걸 확인할수 있습니다.

※ 주의할 점은 Logcat으로 출력되는 로그가 아니라 Debug 창의 Console tab에 표기되므로 따로 logcat tool을 사용한다면 사용 못하는 기능이네요.

Android studio에서만 해당 로그를 확인할 수 있습니다.

7. Making breakpoint group

디버깅 중에 또다른 버그를 발견하거나, 여러 버그가 산재하여, 버그에 따라 breakpoint를 activation/deactivation 시켜야 하는 경우가 발생합니다.

이때 breakpoint를 버그에 따라 찍었다 뺐다 하기에는 번거로우니, 위에서 언급한 활성화/비활성화를 진행할 수 있습니다.

하지만 버그에 따라 설정해 놓은 breakpoint를 하나씩 바꾸기 보다는 group으로 만들어 처리할 수 있습니다.

breakpoint을 묶어 그룹화 시키고 한번에 activie/deactive 시키거나, 삭제할 수 있습니다.

8. Drop frame

안드로이드 10 이상의 단말에서는 디버깅중에 drop frame이라는 기능을 활용할수 있습니다.

breakpoint 내부로 들어갔어야 하나, 실수나 의도적으로 해당 breakpoint를 넘어간 경우 drop frame을 사용하면 된다는 내용입니다.

흠..

이건 제가 영상만으로는 이해를 못했습니다.ㅠ.ㅠ

그냥 안쓰는걸로...

8. Tracking object with labeling

특정 object에 대한 상태를 계속해서 추적하고 싶다면, Mark Object 메뉴를 사용할 수 있습니다.

breakpoint에서 suspend 되면, variable 창에 this (현재 객체정보)가 나타납니다.

이 this를 우클릭하여 Mark Object를 눌러 원하는 label을 붙여 줍니다.

그리고 이 object가 존재하지 않는 다른 breakpoint에서도 +를 통해  추가한 변수에 대한 watch를 설정하면 어디서든 해당 객체의 변화를 추적할 수 있습니다.

9. Log trace from other logs

만약 다른곳으로 부터 trace 로그를 전달받는다면 아래와 같이 Android studio로 집어 넣을수 있습니다.

먼저 외부에서 전달받은 로그를 복사합니다.

Analyze 메뉴에서 Analyze Stack Trace를 클릭하면 클립 보드에 있던 로그가 붙여진 채로 창이 뜹니다.

위 사진에서는 안떴지만 클립보드에 이미 붙어있는 로그가 있다면 이미 해당 로그가 붙여진 채로 창이 보여집니다.

그리고 나서 OK를 누르면 실제 로그처럼 console 창으로 붙여집니다.

추가로 클릭하여 이동가능한 라인은 파란색으로 링크가 생기면 클릭시 해당 클래스및 라인으로 이동할 수 있습니다.