レイヤーモデル（Framework / Engine / Embedder）#

Flutter は 拡張可能でレイヤー化されたシステム として設計されている。各レイヤーは下位レイヤーに依存するが、下位レイヤーへの特権的アクセスは持たず、フレームワーク部分はすべて 任意で置き換え可能 になっている。

flowchart TB
  subgraph framework [Framework Dart]
    materialCupertino[Material / Cupertino]
    widgets[Widgets]
    rendering[Rendering]
    foundation[Foundation / Animation / Painting / Gestures]
    materialCupertino --> widgets --> rendering --> foundation
  end
  subgraph engine [Engine C++]
    dartui[dart:ui]
    impeller[Impeller / Skia / Dart Runtime]
    dartui --> impeller
  end
  subgraph embedder [Embedder Platform]
    os[Android / iOS / Web / Desktop]
  end
  framework --> engine --> embedder

Framework 層をさらに下から見ると次のように積み上がっている。

• Foundation: 基礎クラス、アニメーション・描画・ジェスチャなどの共通抽象
• Rendering: レイアウトを扱う層。レンダリング可能オブジェクトのツリーを構築する
• Widgets: 合成の抽象化層。リアクティブなプログラミングモデルはここで導入される
• Material / Cupertino: ウィジェット層の合成プリミティブを使って各デザイン言語のコントロールを実装

Framework 自体は比較的小さく、camera や webview などの多くの高機能はパッケージ（プラグイン）として提供される。

アプリの構成要素#

flutter create で生成される標準的なアプリは、以下のピースで構成される。

• Dart App: ウィジェットを組み合わせて UI とビジネスロジックを実装（アプリ開発者が所有）
• Framework: ウィジェットツリーをシーンに合成する高レベル API
• Engine: 合成済みシーンのラスタライズ。dart:ui で公開し、Embedder API で各プラットフォームと統合
• Embedder: OS とのやり取り、イベントループ管理
• Runner: Embedder のプラットフォーム固有 API を組み合わせ、実行可能なアプリパッケージにする

リアクティブ UI: UI = f(state)#

Flutter は React に影響を受けた リアクティブ / 宣言的 UI フレームワークである。 開発者は「アプリの状態 → UI の対応」を記述するだけで、状態が変わったときの UI 更新はフレームワークが担う。

ウィジェットは build() メソッドで自身の UI を宣言する。これは状態を UI に変換する関数だと考えられる。

1
UI = f(state)

build() は 副作用がなく高速 であることが前提で、フレームワークは必要に応じて（最悪フレームごとに）何度でも呼び出せる。

ウィジェットと「合成（Composition）」#

Flutter の最大の特徴のひとつが 積極的な合成（aggressive composability） である。 たとえば「余白」は他ウィジェットのプロパティではなく、Padding という独立したウィジェットになっている。中央寄せも Align プロパティをいじるのではなく Center ウィジェットで包む。

1
// 中央寄せは「プロパティ」ではなく「ウィジェットで包む」
2
Center(
3
  child: Padding(
4
    padding: const EdgeInsets.all(16),
5
    child: const Text('Hello World'),
6
  ),
7
)

クラス階層をあえて 浅く広く することで、小さな単機能ウィジェットの組み合わせ爆発によって表現力を確保している。 よく使う Container でさえ、内部的には LimitedBox / ConstrainedBox / Align / Padding / DecoratedBox / Transform といったウィジェットの合成で作られている。

3 つのツリー（Widget / Element / RenderObject）#

Flutter を理解するうえで最重要なのが、3 種類のツリー が連携して動く点である。

flowchart LR
  subgraph w [Widget Tree]
    w1["不変の設定値<br/>毎フレーム作り直し可"]
  end
  subgraph e [Element Tree]
    e1["ツリー上の位置と実体<br/>State を保持・永続的"]
  end
  subgraph r [RenderObject Tree]
    r1["レイアウト・描画<br/>ヒットテスト"]
  end
  w -->|inflate| e -->|生成・更新| r

ポイントは Widget は使い捨て、Element は再利用される という点。 Text('A') を Text('B') に変えると新しい Widget オブジェクトが作られるが、Element ツリーはフレームをまたいで維持され、変更があった部分だけを差分更新する。これにより「ウィジェットツリーは完全に使い捨てに見えるが、内部表現はキャッシュされている」という設計が成立する。

Element には 2 種類ある。

• ComponentElement: 他の Element を保持するホスト
• RenderObjectElement: レイアウトや描画フェーズに参加する Element（対応する RenderObject の仲介役）

build() の引数 BuildContext は、実体としてはこの Element への参照（ツリー上の位置のハンドル）であり、Theme.of(context) のような呼び出しはこの context を使って祖先を辿っている。

状態管理（State / InheritedWidget）#

• 状態を持たないウィジェットは StatelessWidget
• 状態を持つウィジェットは StatefulWidget。ウィジェット自体は不変なので、可変状態は別の State クラスに保持する
• 状態を変えるときは setState() を呼び、フレームワークに再 build を依頼する

ツリーが深くなると、状態をバケツリレーするのが煩雑になる。そこで InheritedWidget を使うと、共通の祖先からデータを効率よく取得できる。

1
// 祖先に置いた状態を、子孫から型で取得する
2
final studentState = StudentState.of(context);

Flutter 自身もテーマ（Theme.of(context)）などで InheritedWidget を多用している。provider などの状態管理パッケージも、その多くは InheritedWidget のラッパーである。

レンダリングパイプライン（Build → Layout → Paint）#

UI コードが実際のピクセルになるまでの流れは次の通り。

flowchart LR
  state[State] -->|build| widget[Widget Tree]
  widget -->|inflate| element[Element Tree]
  element -->|create/update| render[RenderObject Tree]
  render -->|layout| size[サイズ・位置確定]
  size -->|paint| scene[Scene]
  scene -->|compositeFrame| gpu[GPU でラスタライズ]

1. Build: 状態から Widget ツリーを構築し、対応する Element ツリーへ展開（inflate）。ここで Container が ColoredBox を挿入するなど、コードより深いツリーになることがある
2. Layout: RenderObject ツリーを深さ優先で 1 パス走査。親から子へ制約（constraints）を渡し、子から親へサイズ（geometry）を返す。O(n) で完了する
3. Paint: 各 RenderObject が paint() で描画。ルートの RenderView が compositeFrame() でシーンを合成し、dart:ui 経由で GPU に渡す

なお Flutter は OS のウィジェットを使わず、自前のウィジェットセットを直接描画する（描画は Impeller）。これにより OS バージョンによらず同じ見た目・性能を保ち、Flutter ↔ プラットフォーム間の往復オーバーヘッドを避けている。

サブリニアなレイアウト#

• Flutter のレイアウトは 1 フレームにつき 1 回・単一パス で行われる
• 親が子の layout を呼んで制約を渡し、子はサイズを返す。一度返した RenderObject はそのフレームでは原則 二度と訪問されない
• 各 RenderObject はレイアウト中に 最大 2 回（下りと上り）しか訪問されない

さらに、無駄な再計算を避ける仕組みがある。

• 子が dirty でなく、前回と 同じ制約 を受け取ったなら、子は即座に return できる（走査を打ち切る）
• 親が子のサイズを使わないなら、子のサイズが変わっても親は再レイアウト不要
• tight 制約（最小 = 最大）なら、子は親から新しい制約が来ない限りサイズを変えられないので、親の再計算も不要

結果として、dirty なノードとその周辺の限定的な部分木だけが訪問される。

サブリニアなウィジェットビルド#

• ビルド後のウィジェットは Element ツリーが保持する（ウィジェットは不変で親子関係を覚えられないため）
• setState() などで Element が dirty になると、フレームワークは dirty な Element のリストを持ち、ビルド時にそこへ直接ジャンプして clean な Element を飛ばす
• ビルド中は情報が 下方向にしか流れない ため、各 Element はビルド時に最大 1 回しか訪問されない

ここで効くのが const と「再投影（reprojection）」パターン。 ウィジェットが不変なので、親が 同一インスタンス の子で再ビルドすれば、Element はオブジェクト同一性の比較だけで「変わっていない」と判断し、即座に return できる。

1
// const を付けると同一インスタンスとして扱われ、再ビルドがスキップされやすい
2
const SizedBox(height: 20)

また、InheritedWidget は各 Element にハッシュテーブルとして情報を 下方向にプッシュ することで、テーマ参照などのたびに親チェーンを辿る O(N²) を回避している。

線形の差分（reconciliation）と key#

意外なことに、Flutter は ツリー差分（tree-diffing）アルゴリズムを使っていない。 代わりに、各 Element の子リストを個別に O(N) で照合する。最適化されるケースは以下。

• 旧子リストが空
• 新旧リストが同一
• 1 か所だけ挿入・削除された
• 同じ key を持つウィジェット同士をマッチさせる

key を付けると、リスト内で要素が並び替わっても「同じものだ」と認識でき、State を取り違えずに済む。

ツリーサージェリー（GlobalKey）#

Element の再利用は、State と RenderObject を保持できる ため性能上きわめて重要。 GlobalKey を使うと、Element ツリーの 別の場所へウィジェットを移動 しても、新規生成ではなく既存 Element を付け替え（reparent）て部分木全体を維持できる。

これは Hero アニメーション やナビゲーションで多用される。移動先の親が同じ制約を渡せば、子はレイアウトを即 return できるため、移動してもレイアウト情報が再利用される。

無限スクロール（Viewport / Sliver）#

ListView のような無限スクロールは、表示されているぶんだけウィジェットをオンデマンド生成する。

• スクロール領域の外側は Viewport（「中身が外より大きい箱」）
• その子は RenderBox ではなく RenderSliver（ビューポートを意識したレイアウトプロトコルを持つ）
• Sliver は「見えている残り空間」の情報を受け取れるので、無限の子を持ちうる場合でも 有限個だけ 生成する

これを成立させるため、Flutter は ビルドとレイアウトのフェーズを織り交ぜる。レイアウト中（＝見える空間が分かった時点）に、その配下のウィジェットを必要なぶんだけ生成できる。

Element と RenderObject を分ける理由#

両ツリーはほぼ同型（RenderObject ツリーは Element ツリーの部分集合）だが、あえて分けている。

• 性能: レイアウト変更時、合成由来の余計なノードを飛ばして必要部分だけ走査できる
• 明確さ: ウィジェットのプロトコルと描画のプロトコルをそれぞれ専門化でき、API が単純になる
• 型安全: RenderObject ツリーは座標系ごとに型を保証できる

親子の「交渉」の具体例#

公式の例（幅 300・高さ 85 の制約、5px の padding 付き Column）を要約すると、こうした会話になる。

• 親「君は幅 0〜300px、高さ 0〜85px の範囲ね」
• ウィジェット「padding 5px ぶん引くので、子には最大 290 × 75 を渡そう」
• 第 1 子「では幅 290px、高さ 20px にします」
• ウィジェット「2 つ目は第 1 子の下に置くから、残り高さは 55px」
• 第 2 子「幅 140px、高さ 30px にします」
• ウィジェット「位置は第 1 子 (5,5)、第 2 子 (80,25)。自分は 300×60 にする」と親へ報告

つまり 位置は子自身では決められず、親が決める。子は与えられた制約の範囲でしかサイズを選べない。

ボックスの 3 つのタイプ#

制約の扱い方で、ボックスは大きく 3 種類に分かれる。

Container は引数次第で変化する。デフォルトは「できるだけ大きく」だが、width を与えるとそのサイズを尊重しようとする。

これが「width: 100 を指定したのに 100px にならない」問題の正体。 たとえば画面いっぱいの制約を受けた Container(width: 100) は、親（画面）の tight な制約 に従って画面サイズになってしまう。Center で包むと、Center が子に「0〜画面サイズ」の loose な制約 を渡すため、ようやく 100px になれる。

1
// これは画面いっぱいになる（親が tight な制約を渡すため width が無視される）
2
Container(width: 100, height: 100, color: Colors.red)
3

4
// Center で包むと loose な制約になり、100x100 になれる
5
Center(
6
  child: Container(width: 100, height: 100, color: Colors.red),
7
)

tight 制約と loose 制約#

• tight（きつい）制約: 最小 = 最大。満たすサイズはただ 1 つ。例: 画面ルートが子に渡す制約
• loose（ゆるい）制約: 最小が 0。「最大までなら好きなサイズで良い」。例: Center が子に渡す制約

ConstrainedBox と UnconstrainedBox の違いも理解の助けになる。

• ConstrainedBox: 親から受けた制約に 追加の制約 を課す。親が tight ならその追加は効かないことがある
• UnconstrainedBox: 子に制約を課さず、子が好きなサイズになれる。ただし子が大きすぎると、あの overflow 警告 が出る

1
// Row の中で子が大きすぎると "RenderFlex overflow" になる
2
Row(
3
  children: [
4
    Container(width: 4000, color: Colors.blue), // 画面幅を超えて溢れる
5
  ],
6
)

Row / Column のオーバーフローは、「子に制約を課さない」性質と「画面という有限の制約」がぶつかった結果である。Expanded や Flexible で残り空間を分配したり、SingleChildScrollView でスクロール可能にしたりして解決する。

仕組み#

1. ホスト側が前回のコンパイル以降に編集されたコードを調べ、変更されたライブラリ・アプリのメインライブラリ・そこに至るライブラリを再コンパイルする
2. 生成された kernel ファイルをデバイスの Dart VM に送る
3. Dart VM が新しい kernel からライブラリを再ロードする（この時点ではまだコードは再実行されない）
4. フレームワークが既存の全ウィジェット / RenderObject の再ビルド・再レイアウト・再描画を発火する

重要なのは、ホットリロードは既存ウィジェットの再ビルドを引き起こすだけ という点。再ビルドに関わるコードしか再実行されないため、main() や initState() は 再実行されない。

State が保持される#

ホットリロードは アプリの状態を保持 する。ログイン後の深い画面で UI を修正してリロードしても、ログインし直さずに変更を確認できる。これが通常は望ましい挙動。

ただし、状態に影響する変更をした場合、「最初から実行したときの状態」とは食い違うことがある。その場合は ホットリスタート（状態を捨てて再起動）が必要になる。

ホットリロードが効かない / 効きにくいケース#

1
// 例: ルートウィジェットの build より「下流」の変更はホットリロードで反映される
2
class Counter extends StatelessWidget {
3
  const Counter({super.key});
4

5
  @override
6
  Widget build(BuildContext context) {
7
    // ここの文字色やテキストを変えるとホットリロードで即反映される
8
    return const Text('count: 0');
9
  }
10
}

判断の目安は「変更したコードが、ルートウィジェットの build() より下流で再実行されるか」。下流なら反映される。final bar = foo; のような初期化子の変更は反映されにくいので、const にするか getter（int get bar => foo;）に置き換えると良い。

Before / After#

1
// Before（型名を明示）
2
Container(
3
  alignment: Alignment.center,
4
  padding: const EdgeInsets.all(16.0),
5
  child: Column(
6
    mainAxisAlignment: MainAxisAlignment.center,
7
    crossAxisAlignment: CrossAxisAlignment.start,
8
    children: [
9
      Text('Hello World', style: TextStyle(fontWeight: FontWeight.bold)),
10
    ],
11
  ),
12
);

1
// After（ドットショートハンド）
2
Container(
3
  alignment: .center,                  // Alignment.center
4
  padding: const .all(16.0),           // EdgeInsets.all(16.0)
5
  child: Column(
6
    mainAxisAlignment: .center,        // MainAxisAlignment.center
7
    crossAxisAlignment: .start,        // CrossAxisAlignment.start
8
    children: [
9
      Text('Hello World', style: TextStyle(fontWeight: .bold)), // FontWeight.bold
10
    ],
11
  ),
12
);

使える場所#

コンパイラが明確な「コンテキスト型」を持つ場所、つまりウィジェットのプロパティ指定のほぼすべてで使える。

• enum: MainAxisAlignment, CrossAxisAlignment, BoxFit, TextDirection など
• 静的プロパティ / メソッド: FontWeight.bold → .bold など
• コンストラクタ: EdgeInsets.all() → .all()、BorderRadius.circular() → .circular()

1
// 名前付きコンストラクタ（基底クラス EdgeInsetsGeometry を推論）
2
Padding(
3
  padding: .symmetric(horizontal: 16.0, vertical: 8.0),
4
  child: Text('Spaced out text'),
5
)
6

7
// .new で無名コンストラクタも呼べる（ウィジェットツリーでは稀）
8
final ScrollController _scrollController = .new(); // ScrollController()

型名が省けるぶん可読性が上がる一方、文脈が曖昧だと推論が効かない。慣れるまでは「何の型が推論されているか」を意識しておくと安全。

Phase 1: 入門 — ウィジェットで画面を作る#

ゴール: 「すべてがウィジェット」「UI = f(state)」を体感する。

Phase 2: 基礎 — レイアウトと状態管理#

ゴール: 「Constraints go down. Sizes go up. Parent sets position.」を説明できる。

Phase 3: 内部理解 — 3 つのツリーとパイプライン#

ゴール: 「なぜ大量のウィジェットでも高速なのか（サブリニア / 線形差分）」を説明できる。

Phase 4: 実践 — 性能・最適化・運用#

ゴール: 性能問題を計測ベースで切り分け、適切な最適化を選べる。