알아가는 재미

앱을 개발하다보면, 99% 확률로 리스트 를 만나게 될 것 입니다. 리스트 없는 앱? 진짜 1% 에 속하려나요...? 있긴..하겠죠?

오늘은 List 를 그리는 3가지 방법을 알아볼까 합니다.

단순히 스크롤이 가능하게 하기 위한 Scroll 위젯들은 이번에 다루지는 않습니다. ^^

ListView 를 그리는 방법은 총 3가지가 있으며, 이 3가지는 각기 다른 차이가 존재합니다.

그리고 앞으로는 몰라서, 귀찮아서, 그냥 이렇게 하라길래  가 아닌 정확한 차이를 알고 썼으면 좋겠습니다.

먼저, 세가지 방법에 대해서 코드와 실행결과를 확인해주시면 될 것 같아요~!

builder 를 이용하여 짜여진 ListView

separated 를 이용하여 짜여진 ListView

그렇다면, 이렇게 짜여진 세가지 방법은 서로 어떤 차이가 있는 걸까요?? 그리고 어떤 상황에서, 대체 뭘 써야 할까요????

ListView.builder 와 ListView.separated 의 차이가 구분자 처리 하나뿐이라면 ListView.builder 는 구분자 처리를 못하나요??
-> 그렇지 않습니다. ListView.builder 도 구분자 처리를 할 수 있습니다. 오히려 구분자가 매우 단순하다면, ListView.builder 가 좋습니다.

ListView.builder 보다 ListView.separated 가 항상 더 좋은거 아닌가요???? 구분자가 해당 위젯을 비워두어도 되니까???
-> 그렇지 않습니다.

1. 구분자를 그려야하는지 말아야하는지 판단하기 위한 내부로직이 동작해야하는데, 이때 구분자를 그릴필요없다면, 이는 불필요한 오버헤드로 이어집니다.

2. 각 구분자가 매우 단순하거나, 동일한 경우에는 ListView.builder 가 좋습니다. 각 구분자가 100개까지는 A 타입, 100개 이후부터 B타입 등으로 다른 구분자를 필요로 하는 등 복잡한 구분자라면, ListView.separated 가 좋습니다.

3. 구분자도 결국 메모리를 필요로 합니다. 리스트의 아이템개수가 너무 많은 경우에 이러한 구분자를 위한 메모리도 그만큼 늘어납니다.

저는 왠만하면 ListView.builder 혹은 ListView.separated 둘중 하나를 사용하는 것을 추천합니다.
그와중에도

구분자가 복잡한 디자인을 가지고 있는 경우, 구분자가 index에 따라서 다르게 처리되는 경우 엔 ListView.separated 를 추천합니다.

구분자가 단순히 회색선, 모든 구분선이 동일 한 경우에는 ListView.builder 를 추천합니다.

Flutter 의 핵심은 위젯기반의 UI 툴킷 입니다. ( Android 에서 Compose 도 UI 툴킷인것 처럼)
하나의 코드로 여러 플랫폼에서 같은 결과... 네이티브와 유사한 성능 .. 렌더링이 어쩌구.. 다른것도 많지만 일단은
꼭 알아두세요! Flutter 의 핵심기능중 하나는 위젯 기반으로 UI 를 그리는 것 입니다. 

StatefulWidget , StatelessWidget 이 뭐고 FunctionWidget 은 쓰면 안되나요?

StatefulWidget 과 StatelessWidget 은 Flutter 를 개발하려면 반드시 만나게 되는 기초중의 기초 Widget 입니다.

결론부터 말씀드리자면, StatefulWidget 과 StatelessWidget 가 아닌 그냥 Widget 은 직접 정의해서 사용하지 말라! 입니다.

StatefulWidget 은 상태(Status) 를 저장하는 Widget 입니다.

StatelessWidget 는 상태(Status) 를 저장하지 않는 Widget 입니다.

상태(Status) 를 저장한다? 저장하지 않는다?


플러터는 Widget 을 기반으로 렌더링을 하면서 UI 를 그리게 됩니다.

완전 느린 컴퓨터가 있고, 이미지 1장 그릴때마다 1초가 걸린다고 생각해봐요
이미지 1장을 1초에 걸쳐서 그렸고, 새로운 이미지를 추가해서 1장을 더 그리려는데,
갑자기 이미 그렸던 이미지를 다시 1초에 걸쳐서 다시 그리고, 그다음 이미지를 1초에 걸쳐서 또 그려요..
그렇게 3장 4장 추가하다보면, 화면 하나 다 그리는게 3초, 4초 로 늘어나겠죠?

우리는 당연히 "이미 그렸는데, 얘를 왜 다시그림?" 이라고 생각할 수 있지만, 컴퓨터는 생각보다 멍청해서
"이럴때 그리라고 했지, 너가 이미 그린경우엔 다시 그리지말라고는 안했잖아. 시킨대로 그리는거야"

그래서 플러터에서는 "다시 그리지 않아야 하는 경우" 를 알려주기 위해서 상태(Status) 를 사용해요.
상태(Status) 를 저장해두고, 이걸 보면서 다시 그릴지 말지 결정하고, 상태(Status) 를 저장하지 않는 경우에는 한번 그려지면, 다시그리지 않아요.

StatefulWidget 다시 그려야하는 시점을 파악하고, 때에 따라 다시 그리기 위해 상태(Status) 를 저장하는 Widget 입니다.

StatelessWidget 는 한번 그리면 다시 그리지 않을거여서 상태(Status) 를 저장하지 않는 Widget 입니다.

FunctionWidget 은 Widget getItem() { ... } 처럼 Widget 자체를 반환하는 함수라고 하겠습니다.

1. 만약 여러분이 만든 StatefuleWidget 에서 상태가 변경되면 (setState 호출), 자식트리에 있는 StatefulWidget, StatelessWidget, FunctionWidget 전부 다시 그리려고 시도합니다. 

2. 다시 그리려고 시도는 하지만, 내부적으로 const 로 선언된 Widget 은 다시 그리지 않고, 재사용을 하게됩니다. ( 다시 그리려고 시도한다고해서 무조껀 다시 그리는게 아니라는 거죠! )

3. 하지만 FunctionWidget 인 경우에는 얘기가 달라집니다. FunctionWidget 내부에 사용된 모든 Widget( 자식트리포함) 은 재사용을 하지 않습니다.  FunctionWidget 안에서 return Text('123') 처럼 단일 StatelessWidget 하나라면 성능상으로 차이를 못느낄 수 있겠지만, 우리가 개발을 하다보면, 위젯 하위에 위젯. 그리고 그것을 확장하고, 또 다른 위젯을 파생시키는 등... 엄청나게 변경가능성이 크죠?

4. 따라서 FunctionWidget 은 그냥 사용하지 않는 것이 좋습니다. (최소 Production 에서는 절대 쓰지 않는다고 생각하는게 좋아요)

너의 뇌피셜아니야? 알고보니 그냥 써도 성능상 차이 없는거 아니야? 
플러터 팀에서 직접 만든 영상을 보고 스스로 판단하셔도 좋습니다! 

오늘의 결론 요약!

StatefulWidget : 사용해도 됩니다! - 상태변경을 통해서 Widget 을 다시 그려야할 때 사용하세요~

class MyStatefulWidget extends StatefulWidget {
  const MyStatefulWidget({super.key});

  @override
  State<MyStatefulWidget> createState() => _MyStatefulWidgetState();
}

class _MyStatefulWidgetState extends State<MyStatefulWidget> {
  @override
  Widget build(BuildContext context) {
    return const Placeholder();
  }
}

StatelessWidget : 사용해도 됩니다! - 한번 그려지면, 다시 그릴필요가 없을 때 사용하세요~

class MyStatelessWidget extends StatelessWidget {
  const MyStatelessWidget({super.key});

  @override
  Widget build(BuildContext context) {
    return const Placeholder();
  }
}

FunctionWidget : 사용하지 마세요! - 가독성? 유지보수? 아니요. 성능에서 차이납니다. 쓰지 마세요~

class MyFunctionWidget {
  Widget getItemWidget() {
    return const ItemWidget();
  }
}

class MyStatefulWidget extends StatefulWidget {
  const MyStatefulWidget({super.key});

  @override
  State<MyStatefulWidget> createState() => _MyStatefulWidgetState();
}

class _MyStatefulWidgetState extends State<MyStatefulWidget> {
  @override
  Widget build(BuildContext context) {
    return const Placeholder();
  }

  Widget getItemWidget() {
    return const ItemWidget();
  }
}

class MyStatelessWidget extends StatelessWidget {
  const MyStatelessWidget({super.key});

  @override
  Widget build(BuildContext context) {
    return const Placeholder();
  }

  Widget getItemWidget() {
    return const ItemWidget();
  }
}