Dart 신입 성능 최적화 기술면접

Flutter DevTools의 Performance 탭에서 'Repaint Rainbow'를 활성화하면 위젯이 다시 그려질 때마다 색상이 변경되어 불필요한 리빌드를 시각적으로 확인할 수 있습니다. 또한 'Paint Flashing'을 켜면 페인팅이 발생하는 영역을 하이라이트로 표시합니다. 코드 레벨에서는 debugPrint를 build 메서드 안에 넣어 빌드 횟수를 로그로 확인할 수도 있습니다. 이러한 도구들을 통해 성능 병목을 파악하고 const 생성자나 StatelessWidget 사용 등의 최적화를 적용할 수 있습니다.

리스트의 크기를 미리 알고 있다면 List.generate를 사용하는 것이 메모리 효율적입니다. List.generate는 초기 용량을 미리 할당하여 동적 확장에 따른 재할당 오버헤드를 줄입니다. 반면 빈 리스트에 for 루프로 add를 반복하면 내부 배열이 가득 찰 때마다 더 큰 배열로 복사하는 작업이 발생합니다. 따라서 고정된 크기의 데이터를 생성할 때는 List.generate나 List.filled를 사용하는 것이 좋습니다.

ListView.builder는 lazy loading 방식으로 화면에 실제로 보이는 항목만 빌드하고 렌더링합니다. 사용자가 스크롤할 때 필요한 위젯만 동적으로 생성하므로 초기 메모리 사용량과 빌드 시간이 크게 줄어듭니다. 반면 children을 직접 전달하면 모든 위젯을 한 번에 생성하여 메모리에 올리므로 리스트가 길어질수록 초기 로딩이 느려지고 메모리 부담이 커집니다. 따라서 동적이거나 긴 리스트에는 항상 ListView.builder나 ListView.separated를 사용해야 합니다.

순차적으로 await를 사용하면 첫 번째 API 응답을 받은 후에야 두 번째 API를 호출하므로 총 실행 시간이 각 호출 시간의 합이 됩니다. 반면 Future.wait는 모든 API를 동시에 호출하고 모든 응답을 기다리므로 총 실행 시간이 가장 긴 호출 시간과 같아집니다. 예를 들어 각각 2초 걸리는 3개의 독립적인 API가 있다면 순차 처리는 6초, Future.wait는 약 2초가 걸립니다. 따라서 서로 의존성이 없는 비동기 작업은 Future.wait로 병렬 처리하는 것이 성능상 훨씬 유리합니다.

Flutter의 Image.network는 기본적으로 메모리 캐싱을 제공하지만 디스크 캐싱은 지원하지 않습니다. cached_network_image 패키지를 사용하면 메모리와 디스크 양쪽에 이미지를 캐싱하여 네트워크 요청을 줄일 수 있습니다. 캐싱을 사용하면 같은 이미지를 다시 표시할 때 네트워크 요청 없이 로컬에서 즉시 로드되어 로딩 시간이 단축되고 데이터 사용량이 감소합니다. 또한 오프라인 상황에서도 캐시된 이미지를 표시할 수 있어 사용자 경험이 향상됩니다.

Dart의 compute 함수를 사용하여 무거운 연산을 별도의 isolate에서 실행할 수 있습니다. Flutter는 단일 스레드 모델이므로 메인 isolate에서 무거운 작업을 수행하면 UI 렌더링이 블로킹되어 화면이 멈춥니다. compute를 사용하면 별도의 isolate에서 연산을 수행하고 결과만 메인 isolate로 전달하여 UI 응답성을 유지할 수 있습니다. 예를 들어 큰 JSON 데이터를 파싱하거나 이미지를 리사이징할 때 compute를 활용하면 앱이 버벅거리지 않고 부드럽게 동작합니다.

먼저 전체 재빌드 대신 핫 리로드나 핫 리스타트를 적극 활용하여 빠르게 변경사항을 확인할 수 있습니다. pubspec.yaml에서 사용하지 않는 패키지를 제거하면 의존성 분석 시간이 줄어듭니다. flutter clean 후 다시 빌드하면 손상된 캐시가 정리되어 빌드 문제가 해결되기도 합니다. 또한 Android Studio나 VS Code의 빌드 캐시를 활용하고, 개발 중에는 release 모드 대신 debug 모드를 사용하면 최적화 과정이 생략되어 빌드가 빨라집니다.