このページは Cloud Translation API によって翻訳されました。

Jetpack Compose アーキテクチャのレイヤリング

このページでは、Jetpack Compose を構成するアーキテクチャレイヤの概要と、このデザインを決定付けるコア原則について説明します。

Jetpack Compose は単一のモノリシックプロジェクトではありません。完全なスタックを形成するために組み合わされた複数のモジュールから作成されています。Jetpack Compose を構成するさまざまなモジュールについて理解することで、次のことが可能になります。

適切なレベルの抽象化を使用して、アプリまたはライブラリをビルドする
より低いレベルに「降格」させて、きめ細かい制御や高度なカスタマイズを行えるケースを知る
依存関係を最小限に抑える

レイヤ

Jetpack Compose の主なレイヤは次のとおりです。

図 1. Jetpack Compose の主なレイヤ。

各レイヤは下位レベルをベースにビルドされ、機能を組み合わせて上位レベルのコンポーネントが作成されます。各レイヤは下位レイヤの公開 API をベースにビルドされ、モジュールの境界を検証することができ、必要に応じて任意のレイヤを置き換えることもできます。これらのレイヤを下から順に見てみましょう。

ランタイム: このモジュールは、基本的な Compose ランタイム、たとえば、remember、mutableStateOf、@Composable アノテーション、SideEffect を提供します。Compose のツリー管理機能のみが必要で、UI が必要でない場合は、このレイヤをベースに直接ビルドすることを検討してください。
UI: UI レイヤは、複数のモジュール（ui-text、ui-graphics、ui-tooling など）で構成されています。これらのモジュールは、LayoutNode、Modifier、入力ハンドラ、カスタムレイアウト、描画など、基本的な UI ツールキットを実装しています。UI ツールキットの基本的なコンセプトのみが必要な場合は、このレイヤをベースにビルドすることを検討してください。
基盤: このモジュールは、デザインシステムに依存しないビルディングブロック、たとえば、Row と Column、LazyColumn、特定のジェスチャーの認識などを Compose UI に提供します。独自のデザインシステムをビルドするには、基盤レイヤをベースにしたビルドを検討してください。
マテリアル: このモジュールは、マテリアルデザインシステムの実装、テーマ設定システム、スタイル付きコンポーネント、リップル表示、アイコンを Compose UI に提供します。アプリでマテリアルデザインを使用する際には、このレイヤをベースにビルドします。

設計の原則

Jetpack Compose の基本原則は、少数のモノリシックコンポーネントを提供することではなく、一緒に組み立てる（または構成する）ことができる、小さい集中型機能を提供することです。このアプローチには多くのメリットがあります。

制御

コンポーネントのレベルが高いほど、自動で行われる操作は増えますが、デベロッパーが直接制御できる操作は制限されます。きめ細かい制御が必要な場合は、「降格」させて下位レベルのコンポーネントを使用することが可能です。

たとえば、コンポーネントの色にアニメーション効果を加える場合は、animateColorAsState API を使用します。

val color = animateColorAsState(if (condition) Color.Green else Color.Red)ArchitectureLayering.kt

ただし、コンポーネントを常にグレーで開始する必要がある場合、この API ではそれを実行できません。代わりに、下位レベルの Animatable API を使用するために降格させます。

val color = remember { Animatable(Color.Gray) }
LaunchedEffect(condition) {
    color.animateTo(if (condition) Color.Green else Color.Red)
}ArchitectureLayering.kt

上位レベルの animateColorAsState API 自体は、下位レベルの Animatable API をベースにビルドされています。下位レベルの API を使用すると操作が煩雑になりますが、より細かく制御できます。ニーズに適した抽象化レベルを選択してください。

カスタマイズ

小さなビルディングブロックから上位レベルのコンポーネントを組み立てることで、必要に応じてコンポーネントを簡単にカスタマイズできるようになります。たとえば、マテリアルレイヤで提供される Button の実装を考えてみましょう。

@Composable
fun Button(
    // …
    content: @Composable RowScope.() -> Unit
) {
    Surface(/* … */) {
        CompositionLocalProvider(/* … */) { // set LocalContentAlpha
            ProvideTextStyle(MaterialTheme.typography.button) {
                Row(
                    // …
                    content = content
                )
            }
        }
    }
}ArchitectureLayering.kt

Button は、次の 4 つのコンポーネントで構成されています。

マテリアル Surface: 背景、形状、クリック処理などを提供します。
CompositionLocalProvider: ボタンで有効と無効を切り替えて、コンテンツのアルファ版を変更します。
ProvideTextStyle: 使用するデフォルトのテキストスタイルを設定します。
Row: ボタンのコンテンツ用のデフォルトのレイアウトポリシーを提供します。

構造をわかりやすくするため、一部のパラメータとコメントを省略していますが、これら 4 つのコンポーネントを組み合わせてボタンを実装するだけなので、コンポーネント全体のコードは約 40 行しかありません。Button のようなコンポーネントは、公開するパラメータを自身で決定し、一般的なカスタマイズの実装と、コンポーネントの利便性に影響を及ぼすパラメータの爆発的な増加とのバランスをとっています。たとえば、マテリアルコンポーネントはマテリアルデザインシステムで指定されたカスタマイズに対応しているため、マテリアルデザインの原則に沿って進めやすくなります。

ただし、コンポーネントのパラメータを無視したカスタマイズを行う場合は、レベルを「降格」させてコンポーネントをフォークします。たとえば、マテリアルデザインでは、ボタンは無地の背景にする必要があります。グラデーションの背景が必要な場合、このオプションは Button パラメータではサポートされません。その際は、参照として Material Button 実装を使用し、独自のコンポーネントを作成します。

@Composable
fun GradientButton(
    // …
    background: List<Color>,
    modifier: Modifier = Modifier,
    content: @Composable RowScope.() -> Unit
) {
    Row(
        // …
        modifier = modifier
            .clickable(onClick = {})
            .background(
                Brush.horizontalGradient(background)
            )
    ) {
        CompositionLocalProvider(/* … */) { // set material LocalContentAlpha
            ProvideTextStyle(MaterialTheme.typography.button) {
                content()
            }
        }
    }
}ArchitectureLayering.kt

上記の実装では、マテリアルレイヤのコンポーネント、たとえば、現在のコンテンツのアルファ版、現在のテキストスタイルのマテリアルのコンセプトなどが引き続き使用されます。ただし、マテリアル Surface を Row に置き換えて、望ましい外観になるようスタイルを設定することはできます。

独自のカスタムデザインシステムのビルドなど、マテリアルコンセプトをまったく使用しない場合は、基盤レイヤコンポーネントのみを使用するよう降格させることができます。

@Composable
fun BespokeButton(
    // …
    backgroundColor: Color,
    modifier: Modifier = Modifier,
    content: @Composable RowScope.() -> Unit
) {
    Row(
        // …
        modifier = modifier
            .clickable(onClick = {})
            .background(backgroundColor)
    ) {
        // No Material components used
        content()
    }
}ArchitectureLayering.kt

Jetpack Compose では、最上位のコンポーネントの名前が最もシンプルになっています。たとえば、androidx.compose.material.Text は androidx.compose.foundation.text.BasicText をベースとしています。これにより、上位レベルを置き換えたい場合には独自の実装に見つけやすい名前を付けられるようになります。

適切な抽象化の選択

Compose には、再利用可能なレイヤ化されたコンポーネントをビルドするという哲学があるので、常に下位のビルディングブロックのビルドを目指すべきではありません。上位レベルのコンポーネントの多くは、機能をより多く提供するだけでなく、ユーザー補助機能のサポートなどのベストプラクティスを実装しています。

たとえば、独自のカスタムコンポーネントにジェスチャーサポートを追加する場合、Modifier.pointerInput を使用してゼロから作成できます。ただし、それより上に他の上位コンポーネント（たとえば、Modifier.draggable、Modifier.scrollable、Modifier.swipeable）があり、これをさらに優れた出発点にできるかもしれません。

原則として、最上位レベルのコンポーネントをベースにビルドすることをおすすめします。そうすれば、そのコンポーネントのベストプラクティスからメリットを得るために必要な機能を確保できます。

詳細

カスタムデザインシステムをビルドする例については、Jetsnack サンプルをご覧ください。

あなたへのおすすめ

注: JavaScript がオフになっている場合はリンクテキストが表示されます
Jetpack Compose で Kotlin を使用する
リストとグリッド
Compose における副作用