スタイルと修飾子

スタイルは、設計上、修飾子とは異なります。スタイルは修飾子を置き換えるものではなく、2 つのシステムは異なる目標を持って共存します。内部的には、スタイルは修飾子です。修飾子ではスタイルでできることはすべてできますが、修飾子のすべての機能がスタイルで利用できるわけではありません。

重要:

• スタイルを選択する場合: 既存のコンポーネントのデフォルトをオーバーライドする必要がある場合、高パフォーマンスのアニメーションを実行する場合、コンポーネントのテーマ全体のプロパティ セットを定義する場合。
• 修飾子を選択する条件: 動作（クリック可能、ジェスチャーなど）を追加する必要がある場合、一意の 1 回限りのレイアウトを定義する必要がある場合、または加法的なプロパティが必要な場合。

スタイルと修飾子の比較は次のとおりです。

機能	修飾子	スタイル
主な目標	動作、セマンティクス、複雑なレイアウトを定義します。修飾子は、特定のコンポーザブルの個々の要素をその場で操作し、テーマから継承されません。	外観、個々のアイテムのサイズ設定、テーマ設定可能なプロパティを定義します。スタイルはテーマレベルで動作し、コンポーネント レベルで上書きできます。これらは下位に伝播し、さまざまなコンポーザブルにスタイルを適用します。
ロジック	加算 - 修飾子が組み合わされて新しい結果が生成されます。	上書き可能 - スタイルで最後に設定されたプロパティが優先されます。スタイルは、定義された優先順位の階層に基づいて互いにオーバーライドするプロパティの単一レイヤとして機能します。
テーマ設定	テーマに組み込むのが難しく、通常は個別に使われます。	スタイルはテーマ設定可能（CompositionLocal にアクセス可能）で、一度定義するとコンポーネント全体で使用できます。
パフォーマンス	更新には、Compose の 3 つのフェーズ（コンポジション、レイアウト、描画）すべてが必要になることがよくあります。修飾子の優れたアニメーション パフォーマンスを実現するには、ラムダベースのバージョンを記述する必要があることがよくあります。	コンポジション フェーズをスキップし、レイアウト フェーズと描画フェーズでのみアクティブになり、再コンポーズを減らします。オブジェクトの割り当てが少なくて済みます。
アニメーション	animate*AsState などの別のアニメーション プリミティブを使用する必要があります	一部のアニメーションを処理する animate { } API が組み込まれています。

修飾子の制限

現在の Compose の状況では、修飾子には多くのメリットがあります。ただし、スタイルは修飾子のいくつかの制限に対処します。以下にその制限を示します。

• 修飾子は通常、コンポジション フェーズで作成されます。ラムダベースの修飾子を作成しない限り、更新によって、色などの小さな視覚的変更であっても、コンポジション、レイアウト、描画の完全な再実行が強制されることがあります。
• 条件修飾子には、フルエント チェーン内の破壊的な if-else ロジックが必要です。アニメーション化するには、手動の状態ボイラープレートが必要であり、高性能の「自動アニメーション」メカニズムがありません。
• 修飾子は置き換えではなく、スタックされます。コンポーネントのデフォルトの境界線をオーバーライドすることはできません。2 つ目の境界線を上に描画することのみ可能です。
• 修飾子はグローバル テーマに抽象化するのが難しい。そのため、テーマには通常、再利用可能な修飾子の構成ではなく、未加工の値が保存されます。

スタイルの制限事項

スタイルは修飾子のギャップを埋めることができますが、いくつかの制限もあります。これにより、スタイルが修飾子を完全に置き換えることができないことがわかります。

• スタイルは特殊な修飾子です。修飾子はスタイルと同じことができますが、その逆は当てはまりません。そのため、スタイルは修飾子を補完できますが、置き換えることはできません。
• スタイルは、視覚的な構成（背景、パディング、境界線）に限定されます。クリック ロジック、ジェスチャー検出、アクセシビリティ セマンティクスなどの動作を処理することはできません。
• Style を最終状態に解決する処理は、単一の修飾子を適用するよりもコストがかかります。システムは、可能なすべてのプロパティ値を含むデータ構造を生成する必要があります。継承されたプロパティのルックアップは、これをさらに複雑にします。

修飾子よりもスタイルを使用する場合

スタイルを使用するかどうかは、アプリとユースケースに大きく依存しますが、次のガイダンスは、修飾子よりもスタイルを優先するタイミングを判断するのに役立ちます。

• テーマ全体で一貫性を保つには: スタイルはグローバル テーマに「リフト」されるように設計されています。繰り返し使用する Modifier をすべてのコンポーネントに渡す代わりに、テーマで 1 つの Style を定義して、アプリ全体で統一された外観を作成できます。
• アニメーションを頻繁に実行する場合: スタイルはレイアウト フェーズと描画フェーズで評価されるため、色やスケールなどのプロパティをアニメーション化しながら、コンポジション フェーズを完全にバイパスできます。これにより、パフォーマンスのオーバーヘッドが大幅に削減されます。ビジュアル プロパティのアニメーションを行う場合は、修飾子ではなくスタイルを使用します。
• オーバーライドとスタック: デフォルトのプロパティを置き換える必要がある場合は、スタイルを使用します。修飾子は加法的（枠線を追加すると、2 つ目の枠線が積み重ねられる）ですが、スタイルは「後書き優先」ロジックを使用するため、視覚的な混乱を招くことなく背景やパディングを簡単に置き換えることができます。
• マテリアル コンポーネントのカスタマイズ: マテリアル コンポーネントに Style パラメータが用意されている場合は、カスタマイズに推奨されるアプローチです。これらのスタイルを使用すると、コンポーザブルの内部構造内の特定のプロパティにアクセスして変更できます。これらのプロパティは、通常はアクセスできない可能性があります。