앱이 커지면 스크롤이 뚝뚝 끊기거나 버튼을 눌렀을 때 반응이 늦는 일이 생긴다. "느린 것 같으니 이것저것 고쳐보자"는 가장 위험한 시작이다. 고친다고 정말 빨라지는지도, 어디가 문제인지도 모르기 때문이다. 이 글의 첫 규칙은 먼저 측정하고, 그다음에 고친다이다.

흔히 이런 코드가 느려지는 시작점이다. 카운터 숫자 하나가 바뀔 때, 같은 화면의 무거운 부분까지 같이 다시 그려지는 모습이다.

class _HomePageState extends State<HomePage> {
  int count = 0;

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Column(
        children: [
          Text('$count'),
          ElevatedButton(
            onPressed: () => setState(() => count++),
            child: const Text('+1'),
          ),
          HeavyChart(),   // 그래프를 그리는 무거운 위젯
          ProductList(),  // 상품 수백 개짜리 목록
        ],
      ),
    );
  }
}

버튼 하나를 누를 때마다 화면이 살짝 버벅인다. 바뀐 건 숫자 하나뿐인데 왜일까?

원인: setState가 이 State의 build 전체를 다시 실행한다

setState는 값이 바뀐 Text만 다시 그리는 게 아니라 이 State의 build를 통째로 다시 실행한다. 그러면 안에 적힌 HeavyChart(), ProductList()도 새로 만들어진다. 부모가 다시 그려지면 자식 위젯은 const로 표시했거나 별도로 분리하지 않은 이상 같이 다시 만들어진다. 위젯을 만드는 것 자체는 가볍지만, 무거운 위젯이 다시 그려지는 일이 반복되면 눈에 보이는 끊김이 된다.

1단계: 측정부터 한다 - profile 모드와 DevTools

처음에 반드시 알아야 할 함정이 있다. 디버그 모드는 일부러 느리게 돌아간다. 에러를 잡아주는 검사가 잔뜩 켜져 있어서, 디버그로 실행한 앱의 속도를 그대로 믿으면 안 된다. 성능은 실제 기기에서 profile 모드로 잰다.

flutter run --profile

그다음 Flutter DevTools를 연다. 쓸 만한 도구는 이 정도다.

• Performance(프레임 차트): 프레임마다 그리는 데 걸린 시간을 막대로 보여준다. 막대가 한계선을 넘은 프레임이 끊김의 원인이다
• Rebuild Stats(다시 그려진 횟수): 어떤 위젯이 몇 번 다시 만들어졌는지 알려준다
• CPU Profiler: 어떤 함수가 시간을 쓰는지 본다
• Memory: 메모리가 계속 늘어나는지 본다

고치기 전에 "스크롤하는 동안 프레임 시간" 같은 기준 하나를 정해서 재두고, 고친 뒤 같은 방법으로 다시 잰다. 숫자가 줄었는지로 판단해야 한다.

코드에서 바로 확인하려면 다시 만들어진 위젯을 콘솔에 찍게 할 수도 있다.

import 'package:flutter/widgets.dart';

void main() {
  debugPrintRebuildDirtyWidgets = true; // 다시 그려지는 위젯을 콘솔에 출력
  runApp(const MyApp());
}

2단계: const로 다시 만들어지는 걸 막는다

가장 쉽고 효과가 큰 방법이다. 첫 글에서 const는 "컴파일 때 값이 고정되는 것"이라고 했다. 위젯에 const를 붙이면 Flutter가 이미 만든 같은 객체를 재사용하고, 부모가 다시 그려져도 이 위젯은 건드리지 않는다.

Column(
  children: [
    Text('$count'),                         // count가 바뀌니 const 불가
    ElevatedButton(
      onPressed: () => setState(() => count++),
      child: const Text('+1'),              // 안 바뀌니 const
    ),
    const HeavyChart(),                     // const로 재사용
    const ProductList(),
  ],
)

const를 붙이려면 위젯 클래스의 생성자도 const여야 한다.

class HeavyChart extends StatelessWidget {
  const HeavyChart({super.key}); // const 생성자

  @override
  Widget build(BuildContext context) { /* ... */ }
}

const는 직접 외우기보다 린트의 도움을 받는 게 낫다. flutter_lints에는 prefer_const_constructors 규칙이 있어서, 붙일 수 있는 곳에 const를 안 붙이면 에디터가 알려준다. analysis_options.yaml에 린트가 켜져 있는지 확인해 둔다.

3단계: setState의 범위를 좁힌다

const를 붙일 수 없는 경우(값이 바뀌는 위젯)에는 바뀌는 부분만 별도 위젯으로 분리한다.

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

  @override
  Widget build(BuildContext context) {
    return const Scaffold(
      body: Column(
        children: [
          CounterSection(), // 숫자와 버튼만 상태를 가진다
          HeavyChart(),
          ProductList(),
        ],
      ),
    );
  }
}

class CounterSection extends StatefulWidget {
  const CounterSection({super.key});
  @override
  State<CounterSection> createState() => _CounterSectionState();
}

class _CounterSectionState extends State<CounterSection> {
  int count = 0;

  @override
  Widget build(BuildContext context) {
    return Row(
      children: [
        Text('$count'),
        ElevatedButton(
          onPressed: () => setState(() => count++),
          child: const Text('+1'),
        ),
      ],
    );
  }
}

이제 setState가 CounterSection의 build만 다시 실행한다. HeavyChart와 ProductList는 건드리지 않는다. 상태 관리 글들에서 Consumer, BlocBuilder, ref.watch를 필요한 위젯 가까이에 두라고 한 것도 같은 이유다. 상태 관리 도구에서도 일부만 구독하는 방법이 있다.

// Provider: 이 값이 바뀔 때만 다시 그림
final name = context.select<UserModel, String>((m) => m.name);

// Riverpod
final name = ref.watch(userProvider.select((u) => u.name));

// Bloc: 조건이 맞을 때만 다시 그림
BlocBuilder<UserCubit, UserState>(
  buildWhen: (prev, curr) => prev.name != curr.name,
  builder: (context, state) => Text(state.name),
)

4단계: 목록은 builder로

스크롤 목록 글에서 본 규칙이다. ListView(children: [...])는 항목을 전부 한꺼번에 만든다. 수백 개면 처음 열 때 느리고 메모리도 많이 쓴다. ListView.builder는 화면에 보이는 것만 만든다.

ListView.builder(
  itemCount: products.length,
  itemBuilder: (context, i) => ProductTile(products[i]),
)

항목이 추가, 삭제, 재정렬되는 목록에서는 항목마다 key: ValueKey(product.id)로 안정적인 키를 줘서, 위치가 아니라 id로 구분하게 한다. 이미지가 많은 목록은 원본을 줄여서 불러오고(Image.network(url, cacheWidth: 300)), 네트워크 이미지는 캐시해서 같은 걸 반복해서 받지 않게 한다.

5단계: RepaintBoundary로 다시 칠하는 범위를 가둔다

Flutter는 위젯을 다시 만드는 일(build) 과 다시 칠하는 일(paint) 을 따로 한다. 계속 움직이는 작은 위젯(회전하는 로고, 흐르는 시계)이 있으면, 그 주변 넓은 영역이 같이 다시 칠해지는 일이 생긴다. RepaintBoundary로 감싸면 그 안쪽만 따로 칠하는 층이 생겨서 바깥으로 번지지 않는다.

Column(
  children: [
    const RepaintBoundary(
      child: Spinner(), // 계속 돌아가는 위젯
    ),
    const ProductList(), // 스피너가 돌 때마다 같이 다시 칠해지지 않는다
  ],
)

효과가 있는지는 DevTools의 Flutter Inspector에서 "Highlight Repaints"를 켜서 확인한다. 다시 칠해지는 영역에 색 테두리가 깜빡인다. 다만 아무 데나 감싸면 안 된다. RepaintBoundary는 층을 하나 더 만들어서 GPU 메모리를 쓴다. 프로파일링으로 자주 다시 칠해지는 부분을 확인한 곳에만 쓴다.

6단계: 무거운 계산은 UI 스레드 밖으로

비동기 글에서 Dart는 한 줄로 일하는 이벤트 루프라고 했다. await는 기다리는 동안 다른 일을 하게 해주지만, CPU를 오래 쓰는 계산은 await 없이 그대로 화면을 멈춘다. 수 MB짜리 JSON을 파싱하거나 이미지를 처리하는 일이 대표적이다.

import 'dart:isolate';

Future<List<User>> parseUsers(String text) {
  return Isolate.run(() {
    final list = jsonDecode(text) as List;
    return list.map((e) => User.fromJson(e as Map<String, dynamic>)).toList();
  });
}

Isolate.run은 계산을 별도의 스레드(아이솔레이트) 에서 실행하고 결과만 돌려준다. 그동안 UI는 멈추지 않는다. 가볍게 쓰려면 compute도 있다. 작은 일에 쓰면 오히려 느리니, 프레임 차트에서 한 프레임이 길게 막히는 지점이 확인된 계산에만 쓴다.

순서를 정리하면

• 측정: --profile과 DevTools로 어디가 문제인지 확인한다
• 싸고 효과 큰 것부터: const, setState 범위 좁히기, builder 목록
• 그다음 필요하면: RepaintBoundary, 이미지 줄이기, Isolate
• 다시 측정: 처음 잰 숫자와 비교한다

"일단 RepaintBoundary부터 둘러본다"는 순서는 거꾸로다. 측정 없이 고치면 효과가 있었는지조차 알 수 없다.

Compose, SwiftUI와 비교하면

// Compose - 리컴포지션 범위 좁히기
@Composable
fun HomePage() {
    Column {
        CounterSection()       // 상태를 안에 둠
        HeavyChart()           // 입력이 안 바뀌면 건너뜀(skip)
    }
}

• 안 바뀌는 부분 건너뛰기: Flutter는 const와 위젯 분리 / Compose는 입력이 안 바뀐 @Composable을 리컴포지션에서 자동으로 건너뜀(안정성이 필요) / SwiftUI는 Equatable 뷰나 작은 뷰로 분리
• 상태 범위: Flutter setState와 select / Compose derivedStateOf, 상태를 아래로 내리기 / SwiftUI @State를 필요한 뷰에만
• 목록: Flutter ListView.builder / Compose LazyColumn / SwiftUI List, LazyVStack
• 도구: Flutter DevTools / Android Studio Layout Inspector, Profiler / Xcode Instruments

Compose의 "입력이 안 바뀌면 건너뛴다"를 Flutter는 const로 개발자가 직접 표시한다. 자동으로 건너뛰는 Compose와 달리, Flutter에서는 const를 안 붙이면 건너뛰지 않는다는 점이 가장 큰 차이다.

정리

• 성능은 감으로 고치지 않고, 실제 기기에서 flutter run --profile로 DevTools의 프레임 차트와 다시 그려진 횟수를 먼저 측정한다. 디버그 모드는 일부러 느리다
• setState는 그 State의 build 전체를 다시 실행하므로, 안 바뀌는 위젯에는 const를 붙이고 prefer_const_constructors 린트로 놓친 곳을 찾는다
• const를 못 붙이는 바뀌는 부분은 별도 위젯으로 분리해서 setState의 범위를 좁히고, 상태 관리에서는 select, buildWhen으로 필요한 값만 구독한다
• 긴 목록은 ListView.builder로 보이는 것만 만들고, 이미지는 크기를 줄여서 불러온다
• 계속 움직이는 작은 위젯이 주변을 같이 다시 칠하면 RepaintBoundary로 감싸되, 층이 늘어 메모리를 쓰니 측정으로 확인한 곳에만 쓴다
• CPU를 오래 쓰는 계산은 Isolate.run이나 compute로 UI 스레드 밖에서 하고, 고친 뒤에는 같은 방법으로 다시 재서 효과를 확인한다

다음 글부터는 마지막 6단계로 넘어가서, 앱이 의도대로 동작하는지 코드로 확인하는 테스트(단위, 위젯, 통합)를 다뤄보겠다.