zuryeong의 개발 블로그

Flutter는 Google에서 개발 및 지원하는 오픈소스 프레임워크다.

프론트엔드 & 풀스택 개발자는 Flutter를 사용해 다수의 플랫폼에 대한 애플리케이션의 사용자 인터페이스(UI)를 단일 코드 베이스로 구축할 수 있도록 지원한다.

2018년 출시 이후 Flutter는 iOS, Android, Web, MacOS, Linux 여섯가지 플랫폼에 대한 애플리케이션 개발을 지원한다.

1. Flutter의 주요 특징

1) 프러터는 모든 사람이 아름답고, 좋은 성능을 가진 모바일 앱을 만들 수 있도록 제공하는 모바일 SDK이며 Dart로 구성되었다.

2) Dart는 구글이 만든 언어로 자바스크립트로 컴파일할 수 있다

3) Dart는 빠르며, 엄격한 형식을 지원하고 배우기 쉽다

4) 플러터는 네이티브 디바이스 코드로 컴파일되므로 다른 크로스 플랫폼 기술보다 성능이 뛰어나다

5) 또한 Dart의 JIT, 플러터의 리로드 덕분에 최상의 개발자 경험을 제공한다

6) 플러터는 훌륭한 성능의 크로스 플랫폼 앱을 빨리 만들어야 하는 사람에게 적합하다. 하지만 두 개의 네이티브 팀을 이미 보유한 큰 회사는 플러터가 좋은 선택이 아닐 수 있다.

7) 플러터의 모든 것은 위젯이다

8) 여러 작은 위젯을 조립해 위젯 트리를 완성하며 UI를 만든다

9) 위젯은 크게 상태가 없는 위젯과 상태가 있는 위젯으로 분류된다

10) 플러터는 위젯 생명주기 메서드, 특별한 State 객체 등 상태 관리 도구를 제공한다

2. Flutter 주요 개념

1) 플러터는 리액티브다

2) 모든 것은 위젯이다

3) state 객체는 오래 살아남으며 종종 재사용된다

4) 위젯의 제약은 부고가 서술한

3. Flutter 장점

   1) 통합 개발 환경 지원

Flutter는 다양한 Editor(Android Studio, VS Code 등등)를 사용하여 빌드가 가능하다. Android Studio는 Flutter Inspector와 Flutter Outline이라는 개발 도구를 추가적으로 지원해준다. VS code 에서는 간단하게 Extension 으로 Flutter를 설치하여 Flutter를 사용할 수 있다.

   2) 성능 문제 해결

기존 React Native 혹은 Hybrid App의 경우 네이티브 브릿지를 통한 통신이 불가피했다. 하지만 Flutter는 직접 컴파일되서 Render를 직접 하기때문에 성능이 빠르다. 애니메이션 속도가 60프레임은 가뿐히 넘어서는 것이 기존 크로스 플랫폼시장의 주류였던 React Native와 Flutter를 비교하는 많은 글들에서 Flutter를 내세우는 부분이다.

   3) 머티리얼 디자인과 쿠퍼티노

Flutter는 Androd와 iOS의 대표 디자인 가이드를 기본적으로 제공한다. 구글의 머티리얼 디자인(Material Design)의 홈페이지에는 이미 Flutter가 포함되어 있고 가이드만 제공하는 것 뿐만아니라 Flutter 프로젝트에 바로 추가하여 사용할 수 있는 패키지도 제공한다. 안드로이드와 iOS에서 같은 머티리얼 디자인을 사용하더라도 플랫폼에 따라 다르게 출력되는 부분을 각각 디자인 가이드에 맞게 화면을 그린다. iOS앱을 개발하는 경우 iOS특유의 디자인 시스템인 쿠퍼티노(Cupertino) 위젯을 제공한다. 그렇기에 선택의 폭이 정해져 있기 때문에 어떤 UI 라이브러리를 사용할 것인지 고민 할 필요가 없습니다만 이건 장점이자 단점이 될수도 있다.

   4) Dart를 사용하지만 Native 코드도 사용
앞서 Dart를 사용한다고 했지만 결국엔 크로스 플랫폼이기에 해당 OS에 최적화된 앱을 만들려면 Native 코드를 사용할수밖에 없고 Dart와 섞어서 사용한다. 즉, Dart만 사용하는것이 아니라 Android면 Kotlin, iOS면 Swift도 사용한다. 이는 기존의 Native 코드를 사용한 개발자라면 장점이 된다.

4. 단점

   1) Native API를 Dart에서 직접 호출 불가하다.
특별히 심하게 문제가 되진 않지만 외부 플러그인을 써야한다.

   2) Code Pushing
코드를 고치려면 새 버전을 배포해야 한다.
React Native, Cordova, Ionic 에선 이미 지원 중 이다.

   3) Air BNB Lotti 사용 불가하다.
Android, iOS, React-Native만 지원하고 Flutter는 지원하지 않는다.

   4) C/C++ 라이브러리 호출이 안된다.
NDK C/C++ 라이브러리 호출이 Dart에서 안된다. 외부 플러그인을 써야하고, 원하는 플러그인이 없다면 만들어야 하는 번거로움이 있다.

   5) 지원되는 플러그인이 부족하다.
어플을 생성할 때, Webview, Map 등 플러그인은 필요하다. 하지만 Flutter의 이러한 플러그인들은 전부 0.4, 0.3 등등 1.0을 넘는 버전을 보기가 힘들다. 따라서 지속적으로 업데이트가 되고있고, 업데이트가 될때마다 다시 붙이고 테스트해보는 것은 번거로운 일이 될 것이다.

   6) 아직까진 국내에 개발관련 자료가 많이 없다.
Android, iOS Native는 나온지 오래되서 자료가 많다보니 문제해결이 쉽지만, 국내엔 아직까진 자료가 많다고 할수가 없어 이슈 상황 발생시 자료 찾기가 어렵다. 또한, Flutter 개발자들도 그렇게 많은 편이 아니기에 도움을 구하기도 어느정도 힘이 다.

Flutter의 상태관리의 종류에는

1. StateFul

2. ValueListenable

3. Getx

4. Provider

5. Bloc

6. Cubit

7. Riverpod

8. Mobx

Bloc은 플러터의 상태관리를 도와주는 패키지로써 bloc 외에도 상태관리 패키지를 사용하지 않는 것까지 포함해서 8정도가 있다.

   1) 상태 (state)

앱 내부의 데이터라고 할 수 있다. 유저가 어떤 행동을 취했을 때 내부에서 변하는 데이터를 상태라고 한다.

   2) 상태관리 (state management)

간단한 to do 앱의 경우 미들웨어가 필요 없을테지만, 앱의 덩어리가 조금 더 커지면 setSate만으로는 상태 관리하는데 어려움이 있을 것이다. 이 때문에 따로 상태를 관리할 수 있는 미들웨어 (여기선 bloc)이 필요하다.

1. bloc 패턴이란

bloc(Business LOgic Component)패턴은 상태 변화에 있어 UI와 Business Logic을 분리하는데 사용되는 디자인 패턴이다.

bloc은 "simple", "powerful", "testable"을 핵심가치로 개발되었다.

   1) simple  :  이해하기 쉽고, 다양한 수준의 개발자가 사용할 수 있게 하기 위해

   2) powerful  : 어플리케이션을 작은 단위의 컴포넌트로 나눠주어 멋지고 복잡한 애플리케이션 개발을 돕기 위해

   3) testable  :  어플리케이션의 모든 부분을 쉽게 테스트할 수 있게 하여 코드에 확신을 가지고 개발을 진행할 수 있게

                         하기 위해

2. Bloc을 사용하는 이유

   1) 뷰 영역과 비즈니스 영역을 쉽게 구분할 수 있다.

뷰 영역은 화면 UI부분을 뜻하며 사용자의 액션을 받아 이벤트를 발생시키는 영역을 말한다. 비즈니스 영역은 사용자의 입력에 따라 여러가지 기능(회원가입, 검색 등)을 수행하게 되는데 사용자들은 대부분 어떤 과정을 통해 기느을 수행하는지 알 필요 없다. 사용자의 요청을 빠르게 수행하기 위해 로직을 작성하게 되는 부분을 비즈니스 영역이라고 말한다.

뷰와 비즈니스 영역은 서로 상호작용하게 되어 결과를 도출해 주는 집합체가 하나의 서비스가 되는 것이다.

   2) 테스트하기 쉽고(TDD), 재사용을 가능하게 해 준다.

TDD 개발 방법론 적용 시 bloc적용은 특정 비즈니스 로직 부분만 유닛 테스트  ->  리펙토링 반복 개발을 수월하게 해준다

   3) 이벤트 트레킹을 통합적으로 관리할 수 있다.

BlocObserver라는 게 있어서 이를 통하여 이벤트 트레킹을 통합적으로 관리할 수 있게 된다. 

   4) 통일된 코드 베이스로 일할 수 있다.

룰이 정해져 있기 때문에 개발자들끼리동일한 개발 패턴을 다르게 되어있다. 때문에 업무 효율이 올라간다.

   5) UI와 Business Logic을 분리함으로서 유지보수하기 좋은 구조로 설계할 수 있다.

UI입장에서는 데이터가 처리되는 과정을 알 필요가 없다. 단지 필요한 데이터를 요청하고 그 결과만을 가지고서 화면에 맞게 표시해주는 역할에만 충실하면 된다.

하지만  UI처리 코드와 Business Logic이 같이 섞여 있는 코드라면 복잡성은 높아지고 유지보수도 힘들어진다. 추가로 사이드 이팩트 오류가 발생할 확률도 높아진다.

   6) 분리된 코드는 상태관리되기 때문에 UI에 있어 변경된 부분만 다시 그려주거나 상태만 변경해줌으로써 앱은 빠른 성능이 보장된다

이렇게 상태관리가 되어 있지 않은 앱은 불필요한 UI 다시 그리기 처리, 상태체크 등 작업이 발생됨으로써 그만큼 좋은 성능을 낼 순 없다