作成指標とビュー指標を比較する

Jetpack Compose による UI 開発の加速と Android の改善 学びます。ただし、データがどのように使用されるかを考慮し、 Compose を既存のアプリに追加すると、アプリの APK サイズ、 ランタイムパフォーマンスが向上します

APK サイズとビルド時間

このセクションでは、APK のサイズとビルド時間への影響について、 Sunflower サンプルアプリ - ベスト プラクティスを紹介するアプリ ビューベースのアプリを Compose に移行しました。

APK サイズ

プロジェクトにライブラリを追加すると、APK のサイズが増加します。次の結果 各プロジェクトの圧縮版リリース APK 用でリソースとコードを含む 圧縮を有効にして R8 フルモードを使用し、APK Analyzer で測定。

Compose を初めて Sunflower に追加したとき、APK のサイズは 2,252 KB から 3,034 KB - 782 KB の増加。生成された APK は、次の UI ビルドで構成されます。 ビューと Compose の組み合わせです。この増加は、 依存関係が Sunflower に追加されました。

逆に、Sunflower を Compose のみのアプリに移行した場合、APK サイズは 3,034 KB から 2,966 KB に削減されました（68 KB 削減）。この減少の要因は 未使用の View 依存関係（AppCompat や ConstraintLayout。

ビルド時間

Compose を追加すると、Compose コンパイラとしてのアプリのビルド時間が長くなる アプリ内のコンポーザブルを処理します次の結果が得られました。 スタンドアロンの gradle-profiler ツール。ビルドを複数回実行するため、 テスト実行のデバッグビルド時間の平均ビルド時間が得られることを ヒマワリ:

gradle-profiler --benchmark --project-dir . :app:assembleDebug

Sunflower に Compose を初めて追加したとき、平均ビルド時間が 299 から増加 ミリ秒～ 399 ミリ秒（100 ミリ秒増加）。この所要時間は Compose コンパイラによるものです プロジェクトで定義された Compose コードを変換するための追加のタスクを実行する。

逆に、342 ミリ秒（57 ミリ秒短縮）にまで短縮されました。 Sunflower の Compose への移行が完了しました。この減少の原因は データの削除など、複数の要素をまとめてビルド時間を短縮する バインディング、kapt から KSP を使用する依存関係の移行、更新 最新バージョンにアップグレードする必要があります。

概要

Compose を導入すると、効果的にアプリの APK サイズが大きくなり、 コンパイル プロセスによってアプリのビルド時間のパフォーマンスを向上させる 説明します。ただしこれらのトレードオフは Compose のメリット（特にデベロッパーの生産性の向上） おすすめしますたとえば、Google Play ストア チームが UI の作成に必要なコードが大幅に削減され、最大で 50%も削減できるため、 コードの生産性と保守性が向上します。

その他の事例紹介については、チームに Compose を導入するをご覧ください。

実行時のパフォーマンス

このセクションでは、Jetpack Compose でのランタイム パフォーマンスに関連するトピックについて説明します。 Jetpack Compose と View システムのパフォーマンスを比較し、 その測定方法について見ていきましょう

スマート再コンポジション

UI の一部が無効な場合、Compose は UI のみを再コンポーズしようとします。 更新が必要な部分です。詳しくは、 コンポーザブルと Jetpack Compose のドキュメントをご覧ください。

ベースライン プロファイル

ベースライン プロファイルは、 一般的なユーザージャーニーを高速化する 優れた方法ですベースラインを含める アプリのプロファイルを作成することで、コードの実行速度を、最初のデプロイから約 30% コードの解釈とジャストインタイム（JIT）コンパイルの手順を コードパスを指定します

Jetpack Compose ライブラリには独自のベースライン プロファイルが含まれており、 アプリで Compose を使用すると、こうした最適化が自動的に行われます。ただし、 これらの最適化は Compose ライブラリ内のコードパスにのみ影響するため、 ベースライン プロファイルを追加することをおすすめします。 Compose 外のコードパスをカバーできます。

ビューシステムとの比較

Jetpack Compose には、ビューシステムと比べて多くの点で改善されています。これらの改善は、 以降のセクションで説明します。

すべてがビューの拡張

あらゆるユースケースをサポートするには、画面に描画されるすべての View（TextView、Button、ImageView など）で、メモリ割り当て、明示的な状態トラッキング、さまざまなコールバックが必要になります。さらに、カスタム View オーナーは、 そうでないときに再描画を防ぐために、明示的なロジックを実装する たとえば、反復的なデータ処理に使用します。

Jetpack Compose は、いくつかの方法でこの問題に対処します。Compose に明示的な表現がない ビューを描画するための更新可能なオブジェクトです。UI 要素はシンプルでコンポーズ可能な関数 その情報が再生可能な方法でコンポジションに書き込まれること。これにより、 明示的な状態トラッキング、メモリ割り当て、コールバックを コンポーザブルは、すべての要素がそれを必要とするのではなく、特定の機能を必要とする 特定の View タイプの拡張機能です。

さらに、Compose はスマートな再コンポーズを行います。 変更の必要がなければ、以前に描画された結果を再生する。

複数のレイアウトパス

従来の ViewGroup は、メジャーとレイアウトの表現力が高い 複数のレイアウトパスが生じやすい API。こうした複数のレイアウトパスは、ビュー階層内の特定のネストポイントで実行されると、指数関数的な処理を発生させる可能性があります。

Jetpack Compose がレイアウトパスを 1 つ強制する すべてのレイアウト コンポーザブルに対して、API コントラクトを介して設定します。これにより Compose が効率的に ディープ UI ツリーを処理できます。複数の測定が必要な場合、Compose には 本質的測定値。

起動時のパフォーマンスを確認する

ビューシステムでは、特定のレイアウトを初めて表示する際に、XML レイアウトをインフレートする必要があります。Jetpack Compose では、レイアウトはカスタマイズできるため、 アプリの他の部分と同じようにコンパイルできます。

Compose のベンチマーク

Jetpack Compose 1.0 では、debug モードと release モードでアプリのパフォーマンスに顕著な違いがあります。アプリをプロファイリングする際は、代表的な時間指標については debug ビルドではなく必ず release ビルドを使用してください。

Jetpack Compose コードのパフォーマンスを確認するには、 Jetpack Macrobenchmark ライブラリ:手順について詳しくは、 方法については、 MacrobenchmarkSample プロジェクト。

また Jetpack Compose チームは、Macrobenchmark を使用して 発生する可能性があります。例については、遅延列のベンチマークをご覧ください。 そのダッシュボード 追跡する方法を学びました

Compose プロファイルのインストール

Jetpack Compose はバンドルされていないライブラリであるため、View システムの UI ツールキットのクラスとドローアブルJetpack Compose 1.0 はプロファイルを利用 リリースビルド用のインストールプロファイル インストーラを使用すると、実行すべき重要なコードをアプリから指定できます。 インストール時に事前（AOT）コンパイルする必要があります。Compose には、Compose アプリの起動時間を短縮してジャンクを減らすためのプロファイル インストール ルールが付属しています。