Jetpack Compose の内部メカニズム

私たちは毎日のように @Composable 関数を書いています。では、その関数が内部で実際にどのように実行されているのか、どこまで知っているでしょうか？

多くの資料が Compose を「どう使うか」に焦点を当てているのに対し、Jetpack Compose メカニズム は、Compose が「なぜそのように動くのか」を解説します。@Composable 関数がコンパイル時にどのように変換されるのかから、Composition を保持するギャップバッファベースの Slot Table、そして宣言的 UI を実際のピクセルへと変換するシングルパスのレンダリングパイプラインまで、Jetpack Compose の内部実装をソースコードに沿って一つずつ解きほぐしていきます。

とはいえ、内部 API をただ羅列した百科事典のような本ではありません。著者自身が実際に Compose のプラグインやライブラリを開発・運用してきた経験をもとに、すべての内部メカニズムを実務ですぐに活かせる具体例へとつなげています。単にルールを暗記するのではなく、Compose がどのように動いているのかを根本から理解するための一冊です。本書は最新の Kotlin 2.4.0 と Compose Compiler 2.4.0 を基準に執筆されています。

多くの開発者が意外と知らない事実があります。私たちが書いた @Composable 関数と、コンパイル後に実際に実行される関数は同じものではありません。コンパイルが終わると、元の関数はまったく新しい形へと書き換えられます。すべての呼び出しには $composer が渡され、$changed ビットマスクがその関数の実行をスキップできるかどうかを判断します。Slot Table は呼び出し位置に基づいて状態を記憶し、LayoutNode ツリーは一度の測定パスでレイアウトを計算した後、ハードウェアレイヤーへ描画命令を記録します。

予期しない Recomposition が発生したとき。原因の分からないスクロールのカクつきに遭遇したとき。Compiler Report に "not skippable" とだけ表示され、なぜそうなったのか分からなかったとき。私たちはすでに、日々の開発の中でこうした内部システムの影響を受けています。

本書は、まさにそうした現象を理解するためのガイドです。@Composable が単なるアノテーションではなく、関数型そのものを変える目印である理由。コンパイラが私たちの書いたコードを、状態マシンに近い形へと変換していく過程。mutableStateOf は Recomposition を引き起こすのに、通常の var では何も起こらない理由。そうした違いを、一つずつ理解していきます。

Snapshot システムが明示的なロックなしでマルチスレッドの状態をどのように管理するのか。不安定な List フィールドが一つあるだけで、なぜ画面全体のパフォーマンスが気づかないうちに低下するのか。Compose のレイアウトシステムが、従来の View システムで起こり得た指数関数的な測定コストを避けながら、どのように各要素を一度のパスで測定しているのかも見ていきます。各章は開発者にとって理解しやすいところから始まりますが、最後の章にたどり着く頃には、Compose の内部が想像以上に深いところまでつながっていることが見えてくるはずです。

本書は、著者自身が開発した Compose Stability Analyzer、Compose Stability Inference、Compose Navigation Graph、Compose HotSwan、Compose Performance Skills をはじめとする、さまざまな Compose プラグインやライブラリの開発経験をもとに執筆されています。本書で扱うすべてのメカニズムは、Composer、Kotlin コンパイラ、Compose Runtime などを含め、著者自身が実際に使い、デバッグし、プロダクションへ導入しながら検証してきたものです。

本書では、Compose を構成する3つのレイヤーを順に深く学び、その理解を単なる理論で終わらせることなく、実践へとつなげていきます。

第1章では、Compose Compiler が私たちの書いた @Composable 関数を実際にどのように変換するのか、その過程を追いかけます。$composer と $changed パラメータ、スキップ可能性を決定する Stability Inference、Lambda Memoization、そして最終的なコードを生成する数多くの IR Pass を見ていきます。

第2章では Runtime の世界に入ります。Composition を位置に基づいて記憶するギャップバッファ構造の Slot Table、ロックなしでマルチスレッドの状態を管理する Snapshot システム、フレーム境界に合わせて処理をスケジュールする Recomposer、そして同じ Runtime エンジンであらゆる種類のツリーを扱えるようにする Applier の仕組みを掘り下げます。

第3章では、そのツリーが実際のピクセルへ変換されるまでを扱います。LayoutNode、現代的な Modifier.Node システムと Coordinator チェーン、シングルパス測定、Graphics Layer、入力処理、アクセシビリティの Semantics、Lookahead と Shared Element Transition、そして SubcomposeLayout までを追っていきます。最後には、自分だけの小さな Compose UI ライブラリをゼロから実装します。

第4章では、それまでの3章で学んだすべてを一つにつなげ、Compose のパフォーマンスを実践的に最適化する方法を学びます。著者が Compose ライブラリやプラグインをプロダクションへ投入しながら積み重ねてきた経験をもとに構成された、実践重視のパフォーマンス・プレイブックです。Stability Inference のアルゴリズムを段階的に追い、実際の Composable に対して Runtime がどのようにスキップ可否を判断するのかを確認します。State の読み取りを適切なレンダリングフェーズへ移動する方法や、不要な Recomposition を引き起こす Lambda や ViewModel のパターンを改善する方法も取り上げます。

さらに、Compiler Report、Recomposition Tracing、Layout Inspector、Macrobenchmark を使って、パフォーマンス改善の結果を客観的に測定するところまで扱います。フレーム時間を静かに蝕んでいく代表的なアンチパターンを確認し、最後には毎秒47回の Recomposition が発生していたカクつくチャット画面を、Recomposition 0回まで削減する実践的なケーススタディを分析します。この章を読み終える頃には、単に「パフォーマンス最適化について読んだ」というレベルを超え、ソースコードから自分で原因を特定し、解決できるようになるはずです。

最後のページをめくる頃には、Compose はもう、暗記すべき API の集まりでも、理由を知らないままルールに従うためのツールでもなく、数多くの緻密なシステムが組み合わさって動く一つの構造として頭の中に描けるようになるでしょう。

そのとき、同じ Composable 関数を見ても、以前とは違って論理的に分析できるようになります。ビルドする前からその挙動を予測し、問題が起きたときにはソースコードをたどって自分で原因を突き止められるようになります。

もう推測に頼るのではなく、UI の内部で実際に何が動いているのかを自分の目で理解したい。そう思ったことがあるなら、この本がその答えの一つになれば幸いです。

— Jaewoong Eum (skydoves)

ISBN-13: 9798185354780