UI更新はどこで詰まるのか──Ionic・Flutter・React Nativeを入力イベントと再描画の衝突点で比較する

1. なぜ「入力イベント」が差を拡大させるのか

アプリは常に次を同時に処理しています。

• 入力イベント（タップ、スクロール）
• 状態更新
• UI再描画

この3つが同じ実行ループに乗るか、分離されているかで、体感品質は決まります。

2. IonicとはイベントとDOMが同一ループで競合する構造

Ionicでは、次がすべてWebViewのイベントループ上で処理されます。

• JavaScriptのイベントハンドラ
• DOM操作
• CSS再計算
• レイアウト・ペイント

つまり、

この途中で処理が重くなると、次の入力イベント自体が遅延します。

Ionicのパフォーマンス問題は「描画が遅い」のではなく、入力と描画が同じ列に並んでいる点にあります。

3. Flutterがイベントと描画を分離できる理由

Flutterでは構造が異なります。

• 入力イベント：UIスレッド
• 描画：Rasterスレッド

Widgetツリーが再構築されても、描画は別スレッドで進みます。

このため、

• タップは即座に反応
• 描画は次フレームで追従

という挙動になります。

ただし、Widget設計が粗いと、再構築コストが即座に跳ね返ります。

4. React Nativeでイベント遅延が発生する実体

React Nativeでは、

• 入力：ネイティブ
• ロジック：JS
• UI更新：ネイティブ

がブリッジで接続されています。

イベントが頻発すると、ブリッジ往復が詰まるため、タップが効かない、スクロールが引っかかる現象が出ます。

5. 状態更新が多い画面で何が起きるか

例えば、次のような画面です。

• 入力と同時にリスト更新
• フィルタ条件変更で即再描画
• アニメーションと状態更新が混在

IonicではDOM再計算、FlutterではWidget再構築、React Nativeでは差分伝達が支配的になります。

問題は、これが画面単位で固定されることです。

6. スクロール中に処理を入れた瞬間の挙動差

無限スクロールで処理を入れると、差は顕著です。

• Ionic：スクロールが止まる
• React Native：スクロールは動くが更新が遅れる
• Flutter：描画が一瞬落ちるが入力は生きる

どれも「正しい」挙動であり、設計思想の違いが露出しているだけです。

7. 設計時に固定される危険な前提

初期実装で次を決めた瞬間、後戻りできません。

• 状態更新頻度をUI層に置くか
• 入力と描画を分離できる前提にするか
• 再描画を局所化できる構造にするか

Ionicでは特に、DOMを増やしても大丈夫という思い込みが後で効いてきます。

Ionicとは、入力イベント・状態更新・描画が単一ループ上で競合するWeb実行モデルを受け入れる選択です。Flutterは描画を分離し、React Nativeはブリッジで折衷しています。違いは性能ではなく、入力と再描画が衝突したときの壊れ方です。この差を理解せずに選定すると、改善ではなく再実装が必要になります。