モバイルUIの描画パイプライン

「滑らかさ」は締切問題である

モバイルUIの滑らかさは主観の話に見えて、実体は組込みのリアルタイム処理に近い締切問題です。ディスプレイは一定間隔でリフレッシュ信号（VSync）を出し、アプリはその間隔内に次のフレームを完成させなければなりません。間に合わなければ前のフレームが再表示され、体感として「カクつき」＝ジャンクになります。ここではUIKit/Androidの View 階層からGPU合成までの経路を追い、どこで予算超過が起きるとどんな症状になるかを整理します。

パイプラインの5段階

モバイルUIの1フレームは、おおむね次の順序で処理されます。

段階1と2は多くの実装でメインスレッド（Androidの場合はUIスレッド）が担い、ここが重いとフレーム全体が遅延します。段階3以降は専用スレッドやGPUに委譲され、CPU側の仕事を軽くしつつ並列に進めるのが現代の設計です。

iOS：UIView から CALayer、そして Render Server へ

UIKitの UIView はタッチ処理やレイアウトの責務を持つ実体ですが、ピクセルのバッキングストアや変換・透明度といった描画状態の大半は裏側の CALayer が保持します。ツリー構造は次のように分岐します。

• UIView 階層（アプリのメインスレッド）が、タッチ処理やレイアウト制約の解決を担当する。
• 各 UIView は対応する CALayer を持ち、Core Animation はこの CALayer ツリーを Retained-mode のシーングラフとして保持する。
• レイアウトと描画コマンド生成が終わると、アプリプロセスは CALayer ツリー（実体は差分コミット）を、別プロセスの Render Server へ送る。
• Render Server がレイヤーツリーからコンポジションを構築し、GPUにラスタライズと合成を指示する。

ここで重要なのは、アプリのメインスレッドが直接ピクセルを塗っているわけではないという点です。アプリ側の仕事は「次のフレームで見た目がどう変わるか」という宣言的な差分を作ることで終わり、実際のラスタライズと合成はプロセス境界を越えてGPU寄りの経路に渡ります。この分離により、レイアウトが少々重くても、既にコミット済みのレイヤーツリーに対する単純な変換（位置・不透明度・スケール）はアプリ側の再計算なしにGPUだけで再生できます。transform や opacity のアニメーションが frame の変更より軽いとされる理由はここにあります。

Android：View 階層から RenderNode／HWUI へ

Androidも構造は同型です。

• View 階層がUIスレッドで measure → layout → draw の3パスを実行する。
• draw パスは実際のピクセルではなく、RenderNode に対する描画コマンド（DisplayList）を記録する。
• RenderNode はツリー状に構成され、変換や透明度をノード単位で保持する（iOSの CALayer に相当するRetained構造）。
• HWUI（ハードウェアアクセラレーションレンダラ）が RenderNode ツリーをレンダースレッドに渡し、OpenGL ES／Vulkan経由でGPUがラスタライズする。

Androidの measure/layout/draw の3パスは、親から子への再帰と子から親への戻りを繰り返すため、ツリーが深い、あるいは requestLayout が広範囲に伝播すると、この段階だけで予算の大半を食いつぶします。invalidate （再描画のみ要求）と requestLayout （測定からやり直し）を区別し、変更の影響範囲を最小化することが、実務上の最重要ポイントです。

描画予算とリフレッシュレート

ディスプレイは固定間隔でVSync信号を発行し、アプリはその間隔内に段階1から5までを完了させる必要があります。間隔（予算）はリフレッシュレートで決まります。

高リフレッシュレート化は体感の滑らかさを上げる一方、同じ処理内容でも予算に対する余裕が減ることを意味します。60Hzで問題なかったレイアウトコードが120Hzでは恒常的にジャンクを出す、という現象は珍しくありません。可変リフレッシュレート機構は、動きのない場面でリフレッシュレートを落として電力を節約し、スクロールやアニメーションを検出すると引き上げる制御をOS側が行います。アプリ側から見ると「予算は固定ではなく状況に応じて変わる」ため、常に最も厳しい予算（最高リフレッシュレート時）を前提に設計するのが安全です。

ジャンクの原因を層で切り分ける

予算超過はパイプラインのどの段階でも起こり得ますが、原因ごとに症状と対策が変わります。

• レイアウト段の肥大化: Viewツリーが深い、制約解決が複雑、requestLayout が広範囲に伝播する。対策はツリーの平坦化と再測定範囲の限定。
• 描画コマンド生成の重さ: 複雑なパス描画やテキストレイアウトを毎フレーム再計算している。対策はキャッシュ化と差分更新。
• コンポジション段の過多: 重なるレイヤー数が多い、不透明度や角丸など合成コストの高い効果（オフスクリーンレンダリング）を多用している。対策はレイヤー統合とオフスクリーン合成の削減。
• ラスタライズ段の肥大化: 巨大なビットマップや複雑なシェーダーをGPUが処理しきれない。対策は解像度・オーバードローの削減。
• メインスレッドのブロック: I/Oや重い計算をメインスレッド（UIスレッド）で行い、レイアウト・描画の順番待ちが発生する。対策は非同期化。

まとめ

モバイルUIの描画は、View階層でのレイアウト確定、描画コマンド生成、Retained-modeのレイヤーツリーによるコンポジション、GPUでのラスタライズ、最終合成という段階的パイプラインで進みます。iOSの CALayer とAndroidの RenderNode はいずれもCPU側の再計算範囲をシーングラフの差分に限定し、実際のピクセル生成をGPUに委ねる設計です。この分業があるからこそ、単純な変換アニメーションは軽く、レイアウト変更やオーバードローは重いという非対称性が生まれます。60Hzで16.6ms、120Hzで8.3msという描画予算を常に意識し、ジャンクが出た際にレイアウト・描画・コンポジション・ラスタライズのどの層で予算を超えているかを切り分けることが、パフォーマンス改善の出発点になります。GPU側の合成やラスタライズの基礎は /graphics/、割り込みやスケジューリングの土台となるOS側の仕組みは /os/ と合わせて理解すると立体的になります。