Flutter / Dart 면접 질문

Flutter는 구글에서 개발한 UI 프레임워크로, 가장 큰 특징은 크로스 플랫폼 개발을 지원한다는 점입니다. Dart라는 언어를 사용해서 iOS와 Android 앱을 하나의 코드베이스로 만들 수 있습니다.

모바일 앱 개발에서 Flutter의 이점은 크게 세 가지로 볼 수 있습니다. 첫째, '핫 리로드' 기능 덕분에 코드 수정 후 즉시 결과를 확인할 수 있어 개발 속도가 매우 빠릅니다. 둘째, 다양한 위젯을 제공하여 아름다운 UI/UX를 쉽게 구현할 수 있습니다. 셋째, 네이티브 성능에 가까운 뛰어난 성능을 보여줍니다. 따라서 빠른 개발과 고품질 앱을 동시에 추구할 때 Flutter는 매우 효과적인 선택입니다.

Dart 언어의 주요 특징 세 가지는 다음과 같습니다.

첫째, Dart는 JIT(Just-In-Time) 컴파일과 AOT(Ahead-Of-Time) 컴파일을 모두 지원합니다. 개발 단계에서는 빠른 개발을 위해 JIT 컴파일을 사용하고, 배포 시에는 AOT 컴파일을 통해 네이티브 수준의 성능을 제공합니다.

둘째, Dart는 강력한 Null Safety를 제공합니다. 개발자가 null 관련 오류를 미리 방지할 수 있도록 도와주어 앱의 안정성을 높입니다.

셋째, Dart는 타입 추론 기능을 제공하여 코드의 간결성을 높입니다. 명시적인 타입 선언 없이도 컴파일러가 타입을 추론하여 개발 생산성을 향상시킵니다.

Flutter 개발에 있어 Dart가 가지는 장점은 다음과 같습니다. Dart는 Flutter의 위젯 렌더링에 최적화되어 있으며, Hot Reload 기능을 통해 UI 변경 사항을 즉시 확인할 수 있어 개발 속도를 크게 향상시킵니다. 또한, AOT 컴파일을 통해 Flutter 앱의 빠른 시작 속도와 부드러운 애니메이션을 가능하게 합니다.

Flutter에서 위젯은 UI를 구성하는 가장 기본적인 단위입니다. 모든 UI 요소는 위젯으로 표현되며, 이 위젯들이 트리 형태로 구성되어 화면을 그립니다.

Stateless 위젯과 Stateful 위젯의 주요 차이점은 상태 변화 가능성입니다. Stateless 위젯은 생성된 후에는 내부 상태가 변하지 않는 위젯입니다. 예를 들어, 단순히 텍스트를 보여주는 Text 위젯이나 아이콘을 표시하는 Icon 위젯 등이 있습니다. 이들은 한 번 생성되면 내용이 바뀌지 않습니다.

반면, Stateful 위젯은 사용자의 상호작용이나 데이터 변경에 따라 내부 상태가 변할 수 있는 위젯입니다. 예를 들어, 버튼을 누를 때마다 숫자가 증가하는 카운터 앱을 생각해볼 수 있습니다. 이 경우, 숫자를 저장하고 관리하는 위젯은 Stateful 위젯이어야 합니다. 상태가 변경될 때마다 setState() 메서드를 호출하여 UI를 다시 그리도록 합니다.

StatefulWidget의 주요 생명주기 메서드는 다음과 같습니다.

먼저 createState()는 StatefulWidget과 연결될 State 객체를 생성하는 메서드입니다. 위젯이 처음 생성될 때 딱 한 번 호출됩니다.

initState()는 State 객체가 생성된 후, 위젯 트리에 삽입되기 직전에 호출됩니다. 여기서 초기화 작업을 수행합니다. 예를 들어, 컨트롤러를 초기화하거나 데이터를 가져올 수 있습니다.

build()는 위젯의 UI를 구성하는 메서드입니다. 위젯이 처음 생성될 때, setState()가 호출될 때, 그리고 부모 위젯이 재빌드될 때 등 여러 상황에서 호출될 수 있습니다.

didUpdateWidget()은 위젯의 설정이 변경되었을 때 호출됩니다. 이전 위젯과 현재 위젯을 비교하여 필요한 업데이트를 수행할 수 있습니다.

마지막으로 dispose()는 State 객체가 위젯 트리에서 제거될 때 호출됩니다. 여기서 리소스를 해제해야 합니다. 예를 들어, 컨트롤러를 dispose하거나 스트림 구독을 취소할 수 있습니다.

Flutter 개발 시 Hot Reload와 Hot Restart는 개발 생산성을 높여주는 아주 유용한 기능입니다.

Hot Reload는 앱이 실행 중인 상태에서 코드 변경 사항을 빠르게 반영하는 기능입니다. 앱의 상태를 유지하면서 변경된 부분만 업데이트하기 때문에 UI를 수정하거나 작은 로직을 변경했을 때 결과를 즉시 확인할 수 있습니다. 예를 들어, 버튼의 색깔을 바꾸거나 텍스트 내용을 수정했을 때 빠르게 적용되는 것을 볼 수 있습니다.

반면 Hot Restart는 앱을 완전히 재시작하는 기능입니다. 앱의 상태가 초기화되고 initState()와 같은 초기화 함수들이 다시 실행됩니다. 따라서 앱의 전체적인 구조를 변경하거나, 상태 관리 로직을 크게 수정했을 때 Hot Restart를 사용해야 변경 사항이 제대로 반영됩니다.

주요 차이점은 상태 유지 여부입니다. Hot Reload는 상태를 유지하고, Hot Restart는 상태를 초기화합니다. 어떤 변경 사항을 적용하느냐에 따라 적절한 기능을 선택하는 것이 중요합니다.

pubspec.yaml 파일은 Flutter 프로젝트의 핵심 설정 파일이라고 할 수 있습니다. 프로젝트에 대한 전반적인 정보를 담고 있죠.

가장 중요한 역할은 프로젝트에서 사용하는 외부 패키지, 즉 의존성을 관리하는 것입니다. 어떤 패키지를 사용하고, 어떤 버전을 사용하는지 명시하여 일관성 있는 개발 환경을 유지하도록 돕습니다.

뿐만 아니라 프로젝트의 이름, 설명, 버전 정보 등 기본적인 메타데이터도 정의하고, 앱에서 사용하는 이미지, 폰트와 같은 에셋 파일들을 등록하고 관리하는 데에도 사용됩니다. 예를 들어, assets: 섹션에 이미지 폴더를 지정하면 앱에서 해당 이미지들을 쉽게 사용할 수 있게 됩니다.

요약하자면, pubspec.yaml은 프로젝트의 '설계도'와 같은 역할을 하며, Flutter 프로젝트를 구성하고 관리하는 데 필수적인 파일입니다.

면접관님, BuildContext는 Flutter에서 위젯 트리의 특정 위치를 나타내는 핸들입니다. 쉽게 말해, 위젯이 자신을 둘러싼 환경에 접근할 수 있도록 도와주는 '맥락'이라고 생각하면 됩니다.

주로 위젯 트리 상위의 데이터나 서비스에 접근할 때 사용하는데요, 예를 들어 Theme.of(context)를 사용하면 현재 앱의 테마 정보에 접근할 수 있고, MediaQuery.of(context)를 사용하면 화면 크기나 방향과 같은 미디어 쿼리 정보에 접근할 수 있습니다.

또 다른 예시로는 Navigator.of(context)를 사용하여 화면을 이동하거나, Provider를 통해 상태 관리를 할 때도 BuildContext를 통해 필요한 데이터에 접근할 수 있습니다. 위젯이 속한 트리의 정보를 활용하여 다양한 기능을 수행할 수 있도록 하는 중요한 요소입니다.

면접관님, Flutter에서 Widget Tree와 Element Tree는 UI를 구성하는 핵심적인 부분입니다.

Widget Tree는 UI의 구조와 설정을 담고 있는 일종의 청사진이라고 생각하시면 됩니다. Widget은 불변 객체이기 때문에 UI가 변경될 때마다 새로운 Widget이 생성됩니다.

Element Tree는 Widget Tree를 기반으로 실제로 화면에 렌더링되는 객체들의 트리입니다. Element는 Widget의 인스턴스를 관리하고, 렌더링 파이프라인에 참여하여 화면에 그리는 역할을 합니다.

두 트리가 존재하는 이유는 효율적인 UI 업데이트 때문입니다. 예를 들어, 버튼의 텍스트만 변경된다면, Widget Tree에서는 해당 버튼 Widget만 새로 생성되고, Element Tree에서는 해당 Element만 업데이트됩니다. 전체 UI를 다시 그리는 것이 아니라 변경된 부분만 업데이트하기 때문에 성능을 향상시킬 수 있습니다. Element는 Widget의 변경 사항을 감지하고 필요한 부분만 다시 빌드하는 역할을 합니다.

Flutter에서 Provider, BLoC, Riverpod은 모두 상태 관리 솔루션이지만, 복잡도와 기능 면에서 차이가 있습니다.

Provider는 가장 간단하며, 앱 전체에서 데이터에 접근하고 업데이트하는 데 용이합니다. 간단한 앱이나 UI 상태 관리에 적합합니다. 예를 들어, 테마 변경이나 사용자 인증 상태를 공유할 때 유용합니다.

BLoC은 비즈니스 로직을 UI에서 분리하여 상태를 예측 가능하게 관리합니다. 복잡한 비즈니스 로직을 처리하고, 상태 변화를 명확하게 추적해야 하는 경우에 적합합니다. 이벤트와 상태를 분리하여 테스트가 용이하다는 장점도 있습니다.

Riverpod은 Provider의 단점을 개선한 솔루션으로, 전역 상태 관리를 더 안전하고 효율적으로 처리합니다. Provider와 유사한 사용법을 가지면서도 컴파일 타임에 타입 안정성을 확보하고, 의존성 주입을 더욱 강력하게 지원합니다.

실제 프로젝트에서는 앱의 규모와 복잡성에 따라 선택합니다. 간단한 앱은 Provider, 복잡한 앱은 BLoC이나 Riverpod을 사용하는 것이 좋습니다. 저는 과거에 쇼핑 앱을 개발하면서 사용자 장바구니 상태 관리에 Provider를 사용했고, 복잡한 상품 검색 로직에는 BLoC을 적용하여 코드 유지보수성을 높였습니다.

네, Flutter의 InheritedWidget에 대해 설명드리겠습니다.

InheritedWidget은 위젯 트리의 하위 위젯들에게 데이터를 효율적으로 전달하는 메커니즘입니다. 쉽게 말해, 위젯 트리의 상위에서 정의된 데이터를 하위 위젯들이 BuildContext를 통해 접근할 수 있도록 해줍니다.

상태 관리 패턴에서 InheritedWidget은 전역적으로 접근해야 하는 데이터를 공유하는 데 사용될 수 있습니다. 예를 들어, 앱의 테마 정보나 사용자 인증 정보 등을 InheritedWidget으로 감싸면, 앱 내의 모든 위젯이 쉽게 해당 정보에 접근하고 변경 사항을 반영할 수 있습니다.

Provider 패키지가 InheritedWidget을 기반으로 만들어졌으며, 의존성 주입을 통해 위젯 간 결합도를 낮추고 재사용성을 높이는 데 기여합니다. 간단한 앱 설정이나 테마 변경과 같이 앱 전체에 영향을 주는 상태를 관리할 때 유용하게 사용할 수 있습니다.

Flutter에서 Key는 위젯 트리의 위젯을 고유하게 식별하는 데 사용됩니다. 특히 동일한 타입의 위젯이 여러 개 있을 때, Flutter가 위젯 트리를 효율적으로 업데이트하고 상태를 유지하도록 돕습니다. 예를 들어, 리스트 아이템의 순서가 변경될 때 Key가 없으면 Flutter는 위젯을 재사용하는 대신 새로 생성할 수 있습니다.

ValueKey는 위젯의 값을 기반으로 식별할 때 사용합니다. 예를 들어, 리스트 아이템의 데이터 자체를 키로 사용할 수 있습니다. ObjectKey는 특정 객체를 키로 사용하며, 객체의 동일성을 기준으로 위젯을 식별합니다. GlobalKey는 앱 전체에서 위젯의 상태에 접근해야 할 때 사용됩니다. 예를 들어, 폼의 상태를 다른 화면에서 접근하거나, 위젯의 크기나 위치 정보를 얻을 때 유용합니다. GlobalKey는 사용 빈도를 최소화하는 것이 좋습니다. 왜냐하면 위젯 트리의 구조를 변경할 수 있기 때문입니다.

네, Flutter에서 StatefulWidget과 StatelessWidget의 생명 주기를 비교 설명하겠습니다.

StatelessWidget은 상태가 변하지 않는 위젯으로, 생명 주기가 단순합니다. build 메서드만 존재하며, 이 메서드에서 UI를 구성합니다. 한 번 생성되면 다시 그려질 때까지 동일한 UI를 유지합니다.

반면 StatefulWidget은 상태 변화에 따라 UI가 업데이트되는 위젯입니다. 더 복잡한 생명 주기를 가집니다.

• initState(): 위젯이 처음 생성될 때 딱 한 번 호출됩니다. 초기화 작업을 수행하기에 적합합니다. 예를 들어, 데이터 로딩이나 리스너 등록 등을 할 수 있습니다.
• didChangeDependencies(): 위젯이 의존하는 데이터가 변경될 때 호출됩니다. InheritedWidget의 변경에 대응하는 로직을 구현할 수 있습니다.
• build(): UI를 구성하는 메서드입니다. 상태가 변경될 때마다 호출되어 화면을 다시 그립니다.
• didUpdateWidget(): 위젯의 설정이 변경될 때 호출됩니다. 이전 위젯과 현재 위젯을 비교하여 필요한 업데이트를 수행할 수 있습니다.
• setState(): UI를 다시 그리도록 Flutter 프레임워크에 알리는 메서드입니다. 이 메서드 호출 후 build 메서드가 다시 실행됩니다.
• dispose(): 위젯이 제거될 때 호출됩니다. 리소스 해제, 리스너 해제 등을 수행하여 메모리 누수를 방지합니다.

StatefulWidget은 setState를 통해 상태를 변경하고, 이에 따라 build 메서드가 다시 호출되어 UI를 업데이트하는 방식으로 동작합니다. 이러한 생명 주기 메서드들을 적절히 활용하여 동적인 UI를 구현할 수 있습니다.

Flutter 애플리케이션 성능 최적화 방법은 여러 가지가 있지만, 중요한 세 가지를 말씀드리겠습니다.

첫째, 불필요한 위젯 리빌드를 줄이는 것입니다. const 키워드를 사용하여 변경되지 않는 위젯을 상수화하면, Flutter는 해당 위젯을 다시 빌드하지 않습니다. 또한, RepaintBoundary 위젯으로 특정 영역을 감싸면, 해당 영역 내부의 변경 사항이 외부 위젯에 영향을 주지 않아 리빌드 범위를 최소화할 수 있습니다.

둘째, 위젯 트리의 깊이를 최적화하는 것입니다. 위젯 트리가 너무 깊으면 렌더링 성능에 영향을 줄 수 있습니다. 불필요한 위젯을 제거하거나, 위젯을 재구성하여 트리의 깊이를 줄일 수 있습니다.

셋째, ListView와 같은 동적 콘텐츠를 효율적으로 렌더링하는 것입니다. ListView.builder를 사용하면 화면에 보이는 부분만 렌더링하므로, 많은 데이터를 가진 리스트를 처리할 때 성능을 크게 향상시킬 수 있습니다.

면접관님, Dart에서 Future와 Stream은 모두 비동기 프로그래밍을 위한 도구이지만, 처리하는 데이터의 성격에 차이가 있습니다.

Future는 미래에 완료될 작업의 결과를 나타냅니다. 단 한 번의 값을 반환하죠. 예를 들어, 서버에 데이터를 요청하고 응답을 받는 경우에 Future를 사용합니다. await 키워드를 사용하여 결과를 기다릴 수 있습니다.

반면 Stream은 시간의 흐름에 따라 여러 개의 데이터를 순차적으로 방출하는 비동기 데이터의 흐름입니다. 실시간으로 업데이트되는 데이터, 예를 들어 센서 데이터나 채팅 메시지를 처리할 때 유용합니다. async* 키워드를 사용하여 Stream을 생성할 수 있습니다.

Flutter 앱에서 Future는 HTTP 요청, 데이터베이스 쿼리 등 한 번만 실행되는 비동기 작업에 사용되고, Stream은 Firebase의 실시간 데이터베이스 변경 감지, WebSocket을 통한 실시간 데이터 수신 등에 활용될 수 있습니다.

네, Flutter 앱 렌더링 파이프라인에 대해 설명드리겠습니다.

Flutter는 위젯 트리를 기반으로 Build, Layout, Paint, Composite 단계를 거쳐 화면을 렌더링합니다.

Build 단계에서는 위젯 트리를 Element 트리로 변환합니다. 이 과정에서 build() 메서드가 호출되며, 불필요한 위젯 재빌드는 성능 저하를 유발할 수 있습니다. const 키워드나 shouldRebuild()를 활용하여 최적화할 수 있습니다.

Layout 단계에서는 Element 트리를 RenderObject 트리로 변환하고, 각 RenderObject의 크기와 위치를 결정합니다. 복잡한 레이아웃 계산은 성능 병목의 원인이 될 수 있으며, RepaintBoundary로 레이아웃 범위를 제한하여 최적화할 수 있습니다.

Paint 단계에서는 각 RenderObject를 캔버스에 그립니다. 불필요한 영역까지 다시 그리는 것을 방지하기 위해 RepaintBoundary를 사용하거나, CustomPainter에서 shouldRepaint()를 구현하여 최적화할 수 있습니다.

Composite 단계에서는 그려진 레이어를 GPU에 업로드하여 화면에 합성합니다. 이 단계는 일반적으로 성능에 큰 영향을 미치지 않지만, 과도한 투명도 효과나 블렌딩 모드는 성능 저하를 유발할 수 있습니다.

DevTools의 Performance 탭을 사용하여 각 단계별 소요 시간을 측정하고, 문제점을 파악하여 최적화할 수 있습니다.

RenderObject를 직접 구현해야 하는 경우는 정말 복잡한 UI나 고성능 그래픽 처리가 필요할 때입니다. 예를 들어, 기존 위젯으로는 표현하기 어려운 특이한 레이아웃 알고리즘이나, 캔버스를 직접 조작하여 애니메이션 효과를 극대화해야 하는 경우를 들 수 있습니다.

RenderObject를 구현할 때는 RenderBox를 상속받아 performLayout과 paint 메서드를 오버라이딩합니다. performLayout에서는 부모로부터 전달받은 Layout Constraints를 기반으로 자식들의 크기와 위치를 결정합니다. 이 때, 자식 위젯의 intrinsic dimensions를 고려하여 레이아웃을 결정해야 합니다. paint 메서드에서는 Painting Context를 사용하여 실제 픽셀을 그립니다.

주의할 점은 performLayout에서 크기를 잘못 계산하면 렌더링 오류가 발생할 수 있고, paint 메서드에서 불필요한 연산을 수행하면 성능 저하를 야기할 수 있다는 것입니다. 또한, RepaintBoundary를 적절히 사용하여 불필요한 영역의 리페인팅을 방지하는 것이 중요합니다.

네, Flutter 앱에서 UI 스레드 블록을 막기 위해 Isolate를 사용할 수 있습니다. Isolate는 별도의 실행 스레드라서 무거운 작업을 여기서 처리하면 UI는 멈추지 않습니다.

Isolate 간 통신은 Port를 통해 이루어집니다. 메인 Isolate에서 메시지를 보내면, 다른 Isolate가 메시지를 받아 작업을 수행하고 결과를 다시 메인 Isolate로 보낼 수 있습니다.

Isolate 사용 시 메모리 오버헤드나 데이터 복사 비용이 발생할 수 있습니다. 왜냐하면 Isolate는 독립적인 메모리 공간을 가지기 때문입니다. 이 문제를 해결하기 위해 가능한 원시 타입이나 불변 객체를 사용해서 데이터 복사 비용을 줄일 수 있습니다. 또한, 불필요한 데이터 전송을 최소화하는 것도 중요합니다.

Flutter에서 복잡한 비즈니스 로직과 UI 상태를 분리하기 위해 MVVM 또는 Clean Architecture를 적용할 수 있습니다. Provider/Riverpod는 이 과정에서 핵심적인 역할을 합니다.

MVVM을 예로 들면, ViewModel은 비즈니스 로직을 처리하고 UI에 필요한 데이터를 Provider/Riverpod를 통해 제공합니다. UI는 ViewModel의 상태를 관찰하고 변경 사항에 따라 업데이트됩니다.

의존성 주입 관점에서 Provider/Riverpod는 ViewModel에 필요한 Repository나 Service를 쉽게 주입할 수 있도록 해줍니다. 이는 테스트 용이성을 높이고 코드의 결합도를 낮춥니다.

대규모 앱에서는 상태 격리가 중요합니다. Provider/Riverpod의 Scope 기능을 활용하여 특정 위젯 트리에만 영향을 미치는 상태를 관리할 수 있습니다. 또한, 상태를 작은 단위로 나누고, 필요한 곳에서만 소비하도록 설계하여 복잡성을 줄일 수 있습니다. 예를 들어, ChangeNotifierProvider를 사용하여 UI 관련 상태를 관리하고, FutureProvider를 사용하여 비동기 데이터를 처리하는 방식으로 상태를 분리할 수 있습니다.

음, Flutter 앱에서 네이티브 기능을 사용해야 할 때 Platform Channels와 Dart:ffi 중 선택은 상황에 따라 달라집니다.

Platform Channels는 비교적 구현이 간단하고, Android/iOS 네이티브 코드와 비동기 메시지 방식으로 통신합니다. 따라서 복잡하지 않은 기능이나 UI 관련 작업에 적합합니다. 하지만 데이터 직렬화/역직렬화 과정 때문에 성능 오버헤드가 발생할 수 있습니다.

Dart:ffi는 C/C++ 라이브러리를 직접 호출하여 성능이 중요한 작업에 유리합니다. 예를 들어, 이미지 처리나 복잡한 계산에 적합하죠. 하지만 메모리 관리를 직접 해야 하고, 타입 매핑에 신경 써야 합니다. 특히 Dart의 Garbage Collector가 관리하지 않는 메모리를 직접 해제해야 메모리 누수를 방지할 수 있습니다. 또한, C/C++ 타입과 Dart 타입을 정확히 매핑하지 않으면 예상치 못한 오류가 발생할 수 있습니다.

결론적으로, 간단한 기능은 Platform Channels, 고성능이 필요한 복잡한 기능은 Dart:ffi를 선택하는 것이 좋습니다. Dart:ffi를 사용할 때는 메모리 관리와 타입 안전성에 특히 주의해야 합니다.

딥 링크와 유니버설 링크는 앱으로 사용자를 특정 콘텐츠로 바로 연결하는 기술입니다. 딥 링크는 앱 내 특정 위치로 이동하는 URI 스킴을 사용하지만, 유니버설 링크는 HTTP/HTTPS URL을 사용해 웹사이트와 앱 모두 연결할 수 있어 더 안전하고 사용자 경험이 좋습니다.

구현 과정은 먼저 go_router나 Navigator 2.0을 사용하여 라우팅 설정을 하고, AndroidManifest.xml과 Info.plist에 딥 링크/유니버설 링크 설정을 추가합니다. 유니버설 링크의 경우, 웹 서버에 AASA(Apple App Site Association) 파일을 호스팅하여 앱과 웹사이트의 연결을 증명해야 합니다.

문제점으로는 딥 링크의 경우 다른 앱과 URI 스킴이 충돌할 수 있고, 유니버설 링크는 AASA 파일 설정 오류나 OS 버전별 동작 차이로 인해 제대로 작동하지 않을 수 있습니다. 해결 전략으로는 고유한 URI 스킴을 사용하고, AASA 파일 설정을 꼼꼼히 확인하며, OS 버전별 예외 처리를 구현하는 것이 중요합니다. 링크 검증 도구를 활용하여 링크가 올바르게 설정되었는지 확인하는 것도 좋은 방법입니다.

네, Flutter 앱 성능 문제 진단 및 최적화를 위해 Flutter DevTools를 적극적으로 활용합니다. 특히 Profile 모드에서 CPU Usage, GPU Rendering, Memory 탭을 중점적으로 분석합니다.

만약 앱에서 스크롤 시 프레임 드롭이 발생한다면, 먼저 CPU Usage 탭에서 CPU 사용량이 급증하는 부분을 확인합니다. 특정 위젯의 build 메서드가 과도하게 호출되는지, 복잡한 계산이 이루어지는지 등을 파악할 수 있습니다.

GPU Rendering 탭에서는 렌더링 시간이 오래 걸리는 부분을 찾아냅니다. 예를 들어, 특정 위젯이 화면에 표시될 때마다 레이아웃 계산이 반복된다면, RepaintBoundary 위젯으로 해당 부분을 감싸 렌더링 범위를 제한하여 성능을 개선할 수 있습니다.

메모리 누수나 과도한 메모리 사용은 Memory 탭에서 힙 스냅샷을 찍어 분석합니다. 객체 할당 패턴을 확인하고, 불필요한 객체가 메모리에 남아있는지 확인하여 메모리 누수를 해결합니다. 예를 들어, 이미지 캐싱 전략을 변경하거나, 사용하지 않는 리소스를 명시적으로 해제하는 방식으로 메모리 사용량을 줄일 수 있습니다.

이러한 방식으로 DevTools를 활용하여 병목 지점을 찾아내고, 코드 수정 및 최적화를 통해 앱 성능을 개선합니다.