2026年のFlutterパフォーマンス最適化：Impeller、リビルド、ベストプラクティス

2026年のFlutterのパフォーマンス最適化は、滑らかなアプリの作り方を変えた2つの転換に支えられています。レンダリングエンジンのImpellerがiOSとAndroidで既定として出荷されるようになったこと、そしてフレームワークのリビルドモデルが、ウィジェットツリーを小さく不変に保つ開発者に報いることです。この2つのてこを活用するチームは、フレームごとに手作業で調整することなく、60または120fpsを安定して維持します。

なぜImpellerがFlutterのパフォーマンス基準を引き直すのか

ImpellerはFlutterのレンダリングエンジンであり、モバイルプラットフォーム全体でSkiaに代わって既定になりました。差が最も表れるのはアニメーションの最初の数秒です。Skiaはシェーダーをジャストインタイムで、ある効果が画面に初めて現れたときにコンパイルしていました。これがFlutterアプリが批判された、あの悪名高い初回実行時のカクつきを生んでいました。Impellerはそれらのシェーダーをビルド時に事前コンパイルするため、アニメーションの最初のフレームは100番目のフレームと同じくらい滑らかです。

Impellerは現代的なグラフィックスAPIも直接ターゲットにします。iOSではMetal、AndroidではVulkanを用い、古いAndroidハードウェア向けにはOpenGLのフォールバックがあります。GitHub上のImpellerエンジンのドキュメントは、レンダリングアーキテクチャとプラットフォームサポートのマトリクスを詳しく説明しています。

| 観点 | Skia（旧来） | Impeller（2026の既定） | |--------|---------------|-------------------------| | シェーダーのコンパイル | 実行時、初回実行時のカクつきを引き起こす | 事前、ビルド時 | | iOSバックエンド | OpenGL / Metal | Metal | | Androidバックエンド | OpenGL | Vulkan、OpenGLフォールバック | | 最初のアニメーションの滑らかさ | ときどきカクつく | 一貫している |

ほとんどのプロジェクトで移行は無料です。最近のFlutterリリースはImpellerを自動的に有効にし、古いシェーダーウォームアップの回避策（--purge-persistent-cache、同梱の.skslファイル）はもはや不要で、削除できます。FlutterがサポートするGLSLのサブセットに対して書かれたカスタムのFragmentProgramシェーダーも引き継がれます。Impellerがそれらを、フレームワーク自身の効果と同じオフラインパイプラインでコンパイルするためです。

アプリがどのエンジンで動作しているかの確認は1行で済みます。デバッグビルドは起動時にアクティブなバックエンドを出力し、DevToolsのインスペクタはアプリのレンダリング詳細でそれを報告します。Impellerが確認できたら、残りのパフォーマンス作業はウィジェット層へと上がります。そこではフレームワークが、画面が実際に変化するよりもはるかに頻繁にリビルドします。本ガイドの残りが焦点を当てるのはそこです。速いエンジンでも、1秒間に何百回も自らを再描画するウィジェットツリーは救えないからです。

constとウィジェット分割でFlutterのリビルドを減らす

setStateは毎回そのウィジェットをダーティとしてマークし、その要素とサブツリーについてbuildを再実行します。コツはそのサブツリーをできるだけ狭く保つことです。作業の大半は2つの習慣が担います。静的なウィジェットをconstとしてマークすること、そして状態を下へ押し下げて、状態を持つ部分を小さく保つことです。

constウィジェットは単一のインスタンスに正規化されるため、親がリビルドされるとき、Flutterは同一の参照を比較し、変更がないと判断して、その枝の再描画を完全にスキップします。

// A cart update repaints the badge, not the header.

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

  @override
  State<ProductScreen> createState() => _ProductScreenState();
}

class _ProductScreenState extends State<ProductScreen> {
  int _cartCount = 0;

  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        const ProductHeader(),         // const: never rebuilds on setState
        CartBadge(count: _cartCount),   // only this subtree rebuilds
        FilledButton(
          onPressed: () => setState(() => _cartCount++),
          child: const Text('Add to cart'),
        ),
      ],
    );
  }
}

analysis_options.yamlでprefer_const_constructorsのlintを有効にすると、この規律がコンパイラのチェックに変わり、constの機会が黙って後退することがなくなります。関連するprefer_const_literals_to_create_immutablesルールは、同じ保証をウィジェットに渡されるリストやマップにも広げます。

ウィジェットのキーもここで触れる価値があります。リストが並べ替えられたり、ウィジェットの型は同じでも同一性が変わったりするとき、ValueKeyやObjectKeyがあれば、Flutterは状態を破棄して作り直す代わりに、古い要素を正しい新しいウィジェットインスタンスに対応付けられます。キーの欠落は、動的リストでスクロール位置が失われたりアニメーションがリセットされたりする一般的な原因であり、それが引き起こす余分なリビルド作業は見落としやすいものです。

変化したデータにリビルドを絞り込む

状態がツリーの高い位置にあると、うまく分割したレイアウトでも多くリビルドされます。対策は、値をブロードキャストし、単一のウィジェットにそれを聴かせることです。FlutterはまさにこのためにValueNotifierとValueListenableBuilderを用意しており、外部パッケージは不要です。

// A scroll-to-top button that rebuilds alone, not the whole page.

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

  @override
  State<ArticleList> createState() => _ArticleListState();
}

class _ArticleListState extends State<ArticleList> {
  final _showFab = ValueNotifier<bool>(false);
  final _controller = ScrollController();

  @override
  void initState() {
    super.initState();
    // Update the notifier, not setState: the list never rebuilds
    _controller.addListener(() => _showFab.value = _controller.offset > 400);
  }

  @override
  void dispose() {
    _showFab.dispose();
    _controller.dispose();
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: ListView.builder(
        controller: _controller,
        itemCount: 200,
        itemBuilder: (_, i) => ListTile(title: Text('Item $i')),
      ),
      floatingActionButton: ValueListenableBuilder<bool>(
        valueListenable: _showFab,
        builder: (_, visible, __) => visible
            ? FloatingActionButton(
                onPressed: () => _controller.jumpTo(0),
                child: const Icon(Icons.arrow_upward),
              )
            : const SizedBox.shrink(),
      ),
    );
  }
}

状態管理ライブラリは同じ考え方を一般化します。Riverpodのref.watch(provider.select(...))とProviderのSelectorウィジェットは、いずれも状態の選ばれた一部が変化したときだけリビルドします。これがデータの多い画面で滑らかかカクつくかを分ける決め手です。これらのライブラリ間のトレードオフは、2026年のFlutter状態管理のガイドで扱っています。

RepaintBoundaryで高コストな再描画を分離する

リビルドと再描画は別の段階です。ウィジェットはリビルドをスキップしても、騒がしい隣人がレイヤーを共有しているために再描画されることがあります。RepaintBoundaryはサブツリーに独自のレイヤーを与えるため、アニメーションするグラフが静的なカードを毎フレーム再描画させることはできません。

// The live chart repaints on its own layer, cards stay untouched.

class Dashboard extends StatelessWidget {
  const Dashboard({required this.ticker, super.key});
  final Stream<double> ticker;

  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        // SummaryCards is static, so isolate it from the animation below
        const RepaintBoundary(child: SummaryCards()),
        RepaintBoundary(
          child: StreamBuilder<double>(
            stream: ticker,
            builder: (_, snap) => LivePriceChart(value: snap.data ?? 0),
          ),
        ),
      ],
    );
  }
}

RepaintBoundaryは無料ではありません。1つごとにレイヤーを確保するため、あちこちにばらまくと利益より害が大きくなります。本当にアニメーションする領域や長いスクロールリストの周りで用い、タイムラインで効果を確認してください。RepaintBoundaryのAPIリファレンスは、デバッグの再描画オーバーレイが、実際に再描画されるレイヤーをどのように強調表示するかを説明しています。

buildメソッドを軽く、副作用なく保つ

buildメソッドはリビルドのたびに実行されるため、その中の高コストなものはすべて何倍にもなります。ルールは、buildは状態を読み取ってウィジェットを返すだけ、それ以上はしないことです。buildの中でScrollController、AnimationController、Futureを確保すると、毎フレーム作り直され、以前のインスタンスがリークします。それらのオブジェクトはinitStateか、disposeで解放されるlate finalフィールドに属します。

重い同期処理は2つ目の罠です。buildの中でJSONをパースしたり、大きなリストをフィルタしたり、日付をフォーマットしたりすると、たとえ元のデータが変わっていなくても、その処理が再描画のたびに再実行されます。入力が変わったときに結果を一度だけ計算してキャッシュするか、フレームワークが1フレームをブロックして待たずに済むようFutureBuilderに移してください。他の値から導かれる値については、依存関係が変わったときだけ再計算するゲッターの背後でメモ化します。

Opacityウィジェットは名指しする価値のある具体的な問題児です。サブツリーをOpacityで包むと画面外のsaveLayerが強制されます。これはパイプラインで最も高コストな操作の1つです。フェードアニメーションにはAnimatedOpacityやFadeTransitionのほうが安く、固定の色合いにはforegroundDecorationやシェーダーを通してペイントレベルで色を適用すれば、レイヤーを完全に避けられます。同じ注意は、大きな面でアンチエイリアスを効かせたClipPathやClipRRectにも当てはまり、これらも裏でsaveLayerを発生させます。

最後に、constのコレクションと、ビルドごとに新しいクロージャを捕捉しないコールバックを優先してください。既定として渡すconst []と、インラインのラムダの代わりのメソッド参照は、どちらもウィジェットの等価チェックを安く保ち、前述のconstによるショートサーキットを実際に発火させます。

長いリストと画像を効率的に構築する

長いフィードや画像グリッドは、素朴なFlutterコードがフレームを落とす場所です。2つのルールがほとんどのケースをカバーします。行を遅延的に構築すること、そして画像をソース解像度ではなく表示されるサイズでデコードすることです。

// Lazy rows plus right-sized image decoding keep scrolling at 60fps.

class Feed extends StatelessWidget {
  const Feed({required this.posts, super.key});
  final List<Post> posts;

  @override
  Widget build(BuildContext context) {
    return ListView.builder(
      itemCount: posts.length,     // build on demand, not all at once
      cacheExtent: 600,            // pre-build past the viewport edge
      itemBuilder: (context, index) {
        final post = posts[index];
        return ListTile(
          leading: Image.network(
            post.thumbnailUrl,
            width: 48,
            height: 48,
            cacheWidth: 96,        // decode at display size, save memory
          ),
          title: Text(post.title),
        );
      },
    );
  }
}

3000ピクセルのフル解像度画像を48ピクセルのアバターに押し込むと、その1つ1つでメモリとデコード時間が無駄になります。cacheWidthを設定するとエンジンにターゲットサイズでデコードするよう指示でき、これだけでリストのメモリ使用量を1桁分削減できることがあります。Flutterのパフォーマンスのベストプラクティスは、同じ原則に従うOpacity、saveLayer、クリップの使い方に関するさらなる指針をまとめています。

2026年のFlutter最適化をDevToolsで測定する

上記のすべてのルールは、想定するのではなく検証すべきです。Flutter DevToolsが信頼できる情報源です。パフォーマンスオーバーレイ（デバッグコンソールのP、またはflutter run --profile）はUIとラスターの2つのグラフを描き、緑の線を越えるバーはすべて落ちたフレームです。タイムラインビューは次に、各遅いフレームを特定のbuild、レイアウト、ペイントの呼び出しに帰属させます。

必ず実機で--profileモードでプロファイルしてください。デバッグビルドは最適化されていないDartを実行し、あらゆる測定値を膨らませるため、デバッグでカクつく画面がコンパイル後には完璧に動くことがよくあります。DevToolsのパフォーマンスガイドはフレームチャートの読み方とジャンクの原因の見つけ方を順を追って説明しており、同じプロファイリングの勘所はFlutterのアニメーションとレンダリングに関する面接でも登場します。

より広いFlutterテクノロジーハブは、本番のパフォーマンス戦略を完成させる状態管理、テスト、レンダリングの各トピックを結びつけます。

まとめ

2026年のFlutterのパフォーマンスは、細かなトリックよりも、一貫して適用する短い習慣のリストに関わります。

• Impeller上で出荷し、旧来のシェーダーウォームアップコードを削除する。最初のフレームのジャンク問題はエンジンレベルで解決済みです。
• 静的なウィジェットをconstとしてマークし、prefer_const_constructorsのlintで強制する。
• 状態を持つウィジェットを小さく分割し、各setStateが可能な限り狭いサブツリーを再描画するようにする。
• 変化する値を、画面全体をリビルドする代わりにValueListenableBuilderやselectスタイルのAPIでブロードキャストする。
• 本当にアニメーションする領域をRepaintBoundaryで包む。ただし増やす前に測定する。
• リストはListView.builderで構築し、画像はcacheWidthを使って表示サイズでデコードする。
• 実機で--profileモードでプロファイルし、次に何を最適化するかを直感ではなくDevToolsに決めさせる。