スタイルは、設計上、修飾子とは異なります。スタイルは修飾子を置き換えるものではなく、2 つのシステムは異なる目標を持って共存します。内部的には、スタイルは修飾子です。 スタイルでできることはすべて修飾子でできますが、修飾子のすべての機能がスタイルで使用できるわけではありません。
スタイルと修飾子の比較は次のとおりです。
| 機能 | 修飾子 | スタイル |
|---|---|---|
| メインの目標 | 動作、セマンティクス、複雑なレイアウトを定義します。修飾子は、特定のコンポーザブルの個々の要素をその場で操作し、テーマから継承されません。 | 視覚的な外観、個々のアイテムのサイズ設定、テーマ設定可能なプロパティを定義します。スタイルはテーマレベルで動作し、コンポーネント レベルで上書きできます。さまざまなコンポーザブルに継承され、スタイルが適用されます。 |
| ロジック | 加算 - 修飾子が組み合わされて新しい結果が生成されます。 | 上書き可能 - スタイルで設定された最後のプロパティが優先されます。スタイルは、定義された優先順位階層に基づいて相互にオーバーライドするプロパティの単一レイヤとして機能します。 |
| テーマ設定 | テーマに組み込むのが難しく、通常は個別に使用されます。 | スタイルは設計上テーマ設定可能（CompositionLocal にアクセスできる）で、一度定義するとコンポーネント全体で使用できます。 |
| パフォーマンス | 更新には、Compose のコンポジション、レイアウト、描画の 3 つのフェーズすべてが必要になることがよくあります。修飾子の優れたアニメーション パフォーマンスを実現するには、ラムダベースのバージョンを作成する必要があることがよくあります。 | コンポジション フェーズをスキップし、レイアウト フェーズと描画フェーズでのみアクティブになり、再コンポジションが減少します。オブジェクトの割り当てが少なくて済みます。 |
| アニメーション | animate*AsState などの個別のプリミティブ アニメーションを使用する必要があります。 |
一部のアニメーションを処理する組み込みの animate { } API が用意されています。 |
修飾子の制限事項
現在の Compose の状況では、修飾子には多くのメリットがあります。ただし、スタイルは修飾子のいくつかの制限に対処します。以下にその制限を示します。
- 修飾子は通常、コンポジション フェーズで作成されます。ラムダベースの修飾子を作成しない限り、色の変更などの小さな視覚的な変更でも、更新によってコンポジション、レイアウト、描画の完全な再実行が強制される可能性があります。
- 条件付き修飾子では、スムーズなチェーン内で破壊的な if-else ロジックが必要になります。 アニメーション化するには、手動の状態ボイラープレートが必要であり、高パフォーマンスの「自動アニメーション」メカニズムがありません。
- 修飾子は置き換えるのではなく、積み重ねられます。コンポーネントのデフォルトのボーダーをオーバーライドすることはできません。上に 2 つ目を描画することしかできません。
- 修飾子をグローバル テーマに抽象化するのは困難です。そのため、テーマには通常、再利用可能な修飾子構成ではなく、生の値が保存されます。
スタイルの制限事項
スタイルは修飾子のギャップを埋めることができますが、いくつかの制限もあります。これにより、スタイルが修飾子を完全に置き換えることができないことがわかります。
- スタイルは特殊な修飾子です。修飾子はスタイルでできることは何でもできますが、その逆はできません。そのため、スタイルは修飾子を補完できますが、置き換えることはできません。
- スタイルは視覚的な構成（背景、パディング、ボーダー）に限定されます。 クリック ロジック、ジェスチャー検出、アクセシビリティ セマンティクスなどの動作を処理することはできません。
- スタイルを最終状態に解決するには、単一の修飾子を適用するよりもコストがかかります。 システムは、可能なすべてのプロパティ値を含むデータ構造を生成する必要があります。継承されたプロパティのルックアップにより、さらに複雑になります。
修飾子よりもスタイルを使用する場合
スタイルを使用するかどうかは、アプリとユースケースによって大きく異なりますが、次のガイダンスは、修飾子よりもスタイルを優先する場合を判断するのに役立ちます。
- テーマ全体の整合性を実現する場合: スタイルは、グローバル テーマに「リフト」されるように設計されています。すべてのコンポーネントに繰り返し修飾子を渡すのではなく、テーマで単一のスタイルを定義して、アプリ全体で統一された外観を作成できます。
- 頻繁にアニメーションを実行する場合: スタイルはレイアウト フェーズと描画フェーズで評価されるため、コンポジション フェーズを完全にバイパスしながら、色やスケールなどのプロパティをアニメーション化できます。これにより、パフォーマンスのオーバーヘッドが大幅に削減されます。視覚的なプロパティのアニメーションを行う場合は、修飾子ではなくスタイルを使用します。
- オーバーライドとスタッキング: デフォルトのプロパティを置き換える必要がある場合は、スタイルを使用します。修飾子は加算型（ボーダーを追加すると 2 つ目が積み重ねられます）ですが、スタイルは「後書き優先」ロジックを使用するため、視覚的な混乱を招くことなく背景やパディングを簡単に交換できます。
- マテリアル コンポーネントのカスタマイズ: マテリアル コンポーネントにスタイル パラメータが用意されている場合は、カスタマイズに推奨される方法です。これらのスタイルを使用すると、コンポーザブルの内部構造内の特定のプロパティにアクセスして変更できます。通常はアクセスできない可能性があります。