플러터를 통해 개발을 진행하다 보면 다양한 문제 상황에 직면하게 된다. 여기 있어야 할 위젯이 저기 가 있다거나, 메모리 오류가 발생해 앱이 종료된다거나, 알 수 없는 버그로 기이한 현상을 창조하는 것을 모두들 겪기 마련이다. 그때마다 다양한 방법을 사용해 앱의 실행을 정상 궤도에 올려야 한다. 이 글에서는 그 방법들 중, 플러터에서 제공하는 툴들을 이용해 해결하는 방법을 소개하고자 한다. 참고로, Visual Studio Code 기준으로 설명한다.
Widget Inspector
내가 배치한 위젯이 어느 정도의 영역을 차지하는 지, 특히나, Flex 위젯(Row, Column 등) 내에서 어떤 설정 덕에 이런 요상한 레이아웃을 만들어 낸 것인지 알고 싶을 때가 있다. 그런데 대부분의 경우 위젯의 레이아웃을 코드만 보고 파악하는 것은 굉장히 번거롭고 귀찮다. 그 때는 Widget Inspector를 이용하면 된다. Widget Inspector는 vscode의 '명령 팔레트'에서 'Flutter: Inspect Widget'을 통해 실행하거나, 앱 실행 후 중지 버튼 옆의 파란색 돋보기 모양의 버튼을 눌러서 실행할 수 있다. 왼쪽 상단의 'Select Widget Mode'를 활성화 하고 정보를 보고자 하는 위젯을 탭하면 해당 위젯의 레이아웃과 세부 정보를 볼 수 있다. 'Widget Tree'에서 원하는 위젯을 찾아서 볼 수도 있다.
우측 상단에는 옵션 버튼들이 있는데, 좌측부터,
- 애니메이션 재생 속도 5배 감소
- 위젯 영역 가이드라인 표시
- 텍스트 베이스라인 표시
- repaint되는 영역 마킹
- 메모리 효율성이 떨어지는 이미지 영역 마킹
에 해당한다.
아래는 이미지는 그 중, 가이드라인 표시 기능과 repaint 영역 마킹 기능을 활성화 한 것이다.
위의 이미지를 보면 알겠지만, 레이아웃을 한 눈에 빠르게 파악할 수 있다. 선택한 Container 위젯은 상하좌우 30만큼의 padding을 가진, Padding 위젯에 둘러싸여 있다.
한 가지 아쉬운 점은, Container에 margin값이 들어가 있어도 Layout Explorer의 UI 상에선 알아보기 어렵다는 것이다. 이와 같은, 각 위젯의 정보를 더 자세히 파악하기 위해서 'Widget Details Tree'를 확인해 볼 수도 있다.
'Widget Details Tree'에서는 실제로 해당 Expanded 위젯이 상하좌우 15의 margin 값을 가진 Container로 감싸져 있다는 것을 알 수 있다. 그런데 여기서, 이보다 더 장점이라고 느껴진 것은, 위젯이 실제 내부에서 어떻게 구현되어 있는지를 파악할 수 있다는 점이다. 위 이미지에서 Expanded를 감싼 Container는 알고보니, margin 이라는 것을 내부적으로 Padding 위젯을 통해 구현되어 있었고, 색상을 넣기 위한 ColoredBox도 가지고 있었다. color 파라미터 대신 decoration 파라미터에 BoxDecoration를 넣고 두께 5의 border를 넣을 경우, Container는 내부적으로 DecoratedBox와 상하좌우 5의 패딩을 가지는 Padding 위젯으로 구성되었다.
이 뿐만 아니라, Row나 Column과 같은 Flex 위젯의 경우에는, 코드를 수정하지 않고도 설정 값을 바꿔보며 레이아웃이 어떻게 적용되는 지 확인해 볼 수도 있다. 위 이미지에서와 같이, Flex 위젯을 선택하면 다양한 드롭다운 버튼이 활성화 되는데, 이를 통해 조작해볼 수 있다. minAxisAlignment, crossAxisAlignment 값을 바꿔가며 테스트 해 볼 수 있고, 자식 위젯들 각각의 flex와 fit을 조절해 가며 레이아웃 변화를 확인할 수 있다.
이와 같이 'Widget Inspector'를 사용하면, 레이아웃 형태와 빈 영역의 크기를 쉽게 알 수 있고, UI의 내부 구현과 설정에 따른 위젯 배치 규칙도 쉽게 파악할 수 있다.
Debugger
버그를 수정하기 위한 면밀한 분석은 프로그래머에게 필수이다. 이번엔, 다양한 IDE가 대부분 지원하는 중단점의 세부 기능에 대해 알아보고자 한다.
보통 위와 같이 원하는 줄에 중단점을 활성화하고, 프로세스가 중단점에 의해 중단되면, 그 시점에 변수들에 담긴 값을 확인한다. 또한, 위 이미지 상 우측 위의 화살표 버튼들 중, '단위 실행' 버튼이나 '단계 정보' 버튼을 통해, 프로세스를 한 단계씩 진행하며 값의 변화와 플로우를 확인할 수 있다.
그러나, 중단점의 기본 기능만으로는 번거로운 경우가 있다. 예를 들어 수만 번 반복하는 반복문 내에서 특정한 시점의 값을 확인하고 싶다던가, 다양한 경로를 통해 매우 자주 호출되는 함수가 특정 조건에서 호출된 경우에만 중단시키고 싶을 때가 있다.
각 중단점에는 중단 조건을 명시하여, 해당 조건이 만족할 때만 그 중단점에 의해 프로세스가 중단될 수 있도록 할 수 있다. 위 이미지는 isValid 값이 false로 변경되었을 때만 중단되도록 설정한 것이며, 그에 따라 index 값이 51이 되었을 때 최초로 디버거가 프로세스를 중단한 것을 볼 수 있다.
또한 다음과 같이 여러 개의 조건을 묶어서 사용할 수도 있고,
적중 횟수를 지정하면 해당 조건에 적중한 횟수가 지정한 횟수에 도달했을 때만 중단된다. (근데 동작하지 않는다...)
여기에 더해, 중단점이 지정된 지점이 실행될 때마다 콘솔에 로그를 남길 수도 있다. (조건과 무관한 듯 하다...)
사실상 쓸만한 것은 조건식을 포함한 중단점 정도이지만, 이것만 잘 활용해도 폭넓은 디버깅을 할 수 있지 않을까?
죄송합니다.