Jetpack Compose での再編成範囲とパフォーマンスの最適化に関する前回の記事では、主にコード レベルからいくつかの最適化を実行する方法を紹介し、いくつかの注目すべき最適化について言及しました。この記事では主に、実行に役立つツール レベルの手段が公式に提供されているものを理解したいと考えています。 Compose デバッグ パフォーマンス デバッグ。
通常のデバッグモード
これは前の方法と同じで、最初にブレークポイントを中断してからデバッガーをアタッチしますが、ブレークポイントで表示される情報は以前とは異なります。
ここで不親切な点は、ブレークポイントがトリガーされたときにパネルに表示されるブレークポイント情報がすべて Java であるため、kotlin コードに対応するのは実際には簡単ではないことです。公式が要求しているため、実際には通常の kotlin コードで大丈夫です。kotlin をサポートしていますあらゆる面で優れており、デバッグツールとしても当然悪くありません。ただし、Compose の場合、Compose コンパイラはコンポーザブル コードに多くの魔法を適用するため、コンパイルされた Java コードは元の kotlin ソース コードと大きく異なる可能性があり、そのため実際のビューがコードと異なる場合があります。
したがって、ここでコンポーザブル関数に関連する有用な情報を見つけようとすると、難しいかもしれません。
公式もこれに気づいたため、Android Studio Hedgehog | 2023.1.1 (コード名: hedgehog) から、デバッガーに少し変更が加えられました: ブレークポイントがトリガーされると、デバッガーはコンポーザブル関数とその関数のパラメーターをリストします。これにより、開発者は再編成を引き起こす可能性のある変更をより簡単に特定できるようになります。たとえば、コンポーザブルを一時停止すると、デバッガはどのパラメータが " " であるか、または " " のままであるかを正確に通知できるため、再構成の原因をより効率的に確認できます。ChangedUnchanged
各パラメータと対応する状態がRecomposition Stateの下にリストされていることがわかります。パラメータの状態分類は次のとおりです。
- Unchanged State : このパラメータは変更されていません
- Changed : パラメータの値が変わりました
- Uncertain : 不確実、Compose はパラメータが変更されたかどうかをまだ評価中です
- Static : Compose は、このパラメータが決して変更されないことを確認しました
- Unstable : パラメータは不安定なタイプです
レイアウトインスペクター (レイアウトインスペクター)
アプリを実行した後、[ツール] > [レイアウト インスペクター]を選択します。
インターフェイスはデフォルトでは次のようになります。
コンポーネント タグを選択すると、対応するコンポーネント ツリーがパネルの左側に展開され、現在のコンポーネントのプロパティ値がパネルの右側に表示されます。
注: レイアウト インスペクターに Compose コンポーネントが表示されない場合は、APK から META-INF/androidx.compose.*.version ファイルが削除されていないことを確認してください。これらは、レイアウト インスペクタが動作するために必要です。
余分な境界線を削除するには、目のアイコン ボタンのドロップダウン オプション [境界線を表示]をオンにします。
3Dプレビュー
右下隅の小さな手のアイコン ボタンをクリックして 3D プレビュー モードに入り、マウスをスライドしてさまざまな視点の効果を確認します。
この効果はクールですが、あまり役に立ちませんが、レイアウト階層を理解するのに役立ちます。さまざまなレイヤーの間隔を変更するには、上の [レイヤー間隔] 進行状況バーをクリックします。
孤立したレイアウト
表示するレイアウトが複雑な場合は、左側のコンポーネントツリーパネルで表示したい部分を選択し、その部分だけを表示することができます。具体的には、コンポーネント ラベルを右クリックし、 [サブツリーのみを表示]または[親のみを表示]を選択します。
完全なビューを復元するには、ビューを右クリックし、[すべて表示]を選択します。
ライブアップデート
ライブ レイアウト インスペクターを有効にするには、レイアウト インスペクター ツールバーから[ライブ アップデート]ボタンを選択します。(API 29+ で実行されているデバイスまたはエミュレータが必要)
Live Layout Inspector には、デバイス上のビューの変更に応じてコンポーネント ツリーとレイアウト表示を更新する動的なレイアウト階層が含まれています。（実体験比較カード）
レイアウト階層スナップショットのエクスポートとインポート
スナップショット機能は、レイアウトの詳細な 3D レンダリング、ビューのコンポーネント ツリー、コンポーズまたはハイブリッド レイアウト、インターフェイス内の各コンポーネントの詳細なプロパティなど、レイアウト インスペクターを使用するときに通常表示されるデータをキャプチャします。
スナップショットをキャプチャするには、レイアウト インスペクター ツールバーの [スナップショットのエクスポート] アイコンをクリックし、必ず*.li拡張子を付けてファイルを保存します。インポートするときは、「スナップショットのインポート」アイコンをクリックし、*.li拡張子が付いたファイルも選択します。
組換え回数を取得する
Compose レイアウトをデバッグする場合、UI が正しく実装されているかどうかを知るためには、コンポーザブルがいつ再結合されるかを知ることが重要です。たとえば、再編成が多すぎる場合、アプリが不必要な作業を実行している可能性があります。一方、コンポーネントが期待どおりに再構築されないと、予期しない動作が発生する可能性があります。
アプリを操作すると、コンポーザブルが再編成またはスキップされるタイミングがレイアウト インスペクターに表示されます。Android Studio Flamingo では、UI 内でコンポーザブルが再編成される場所を識別できるように、再編成が強調表示されます。
まず、次の図に示すように、 「再構成カウントを表示」にチェックを入れます。
次に、前述したようにLive Update を有効にする必要があります。
次に、デバイス上で Compose インターフェイスを操作すると、再編成数とスキップ再結合の数が表示されます。
コンポーネント ツリーでは、レイアウト階層の隣に 2 つの列が表示されます。最初の列は各ノードの組み合わせの数を示し、2 番目の列は各ノードのスキップ数を示します。
再編成が頻繁に行われるコンポーネントが疑わしいと思われる場合は、 [コンポーネント ツリー]パネルでコンポーネントをダブルクリックすると、分析のために対応するコードが表示されます。
注: 再構成数を確認するには、アプリがターゲット API 29 以降、または Compose 1.2.0 以降を使用していることを確認してください。
コンポーザブル ノードを選択すると、コンポーザブルのディメンションとパラメータが表示されます。ただし、インライン関数の場合はパラメータを表示できません。コンポーザブルを選択すると、右側のプロパティパネルにも同様の情報が表示されます。
リセット数は、アプリとの特定の操作中の再編成やスキップを理解するのに役立ちます。カウントをリセットしたい場合は、「コンポーネント ツリー」パネルの上部近くにある「リセット」ボタンをクリックします。
アクティビティの再開を回避する
レイアウト インスペクターが正しく機能するには、次のグローバル設定のいずれかが必要です。グローバル設定を指定しない場合、レイアウト インスペクターによって自動的に設定されます。
-
adb shell settings put global debug_view_attributes_application_package <processname>このオプションは、指定されたプロセスを確認するための追加情報を生成します。 -
adb shell settings put global debug_view_attributes 1このオプションは、デバイス上のすべてのプロセスを検査する追加情報を生成します。
グローバル設定を変更すると、アクティビティが再起動される可能性があります。アクティビティの再起動を回避するには、Android Studio で関連する設定を変更するか、デバイス設定で開発者向けオプションを変更します。
Android Studio で自動更新を有効にするには、メニューから[Run] > [Edit Configurations]を選択して、[Run /Debug Configurations]を開きます。次に、「その他」タブに移動し、「レイアウト インスペクターのオプション」の下にある「アクティビティを再起動せずにレイアウト インスペクターに接続する」チェックボックスをオンにします。
組成トレース
システム トレースは、デバイスのアクティビティの記録をトレース ファイルに保存し、一定期間にわたるアプリのシステム プロセスの全体像を提供する Android ツールです。Android Studio Flamingo以降では、Composeトレース機能を使用してシステム トレースプロファイラーで Compose 関数を表示できるようになりました。Compose トレースを使用すると、低ノイズのシステム トレースを楽しみ、コンポジションに関するメソッド トレース レベルの詳細を取得できるため、どの Compose 関数が実際に再コンポジションされているかを理解するのに役立ちます。
再組織追跡の使用を開始するには、少なくとも次のバージョンに更新する必要があります。
- Android Studio フラミンゴ カナリア 5
- 作成UI：1.3.0-beta01
- Composeコンパイラ：1.3.0
- 実行中のデバイスまたはエミュレータは API 30 以上である必要があります。
さらに、次のCompose Runtime Tracing依存関係を追加する必要があります。
implementation("androidx.compose.runtime:runtime-tracing:1.0.0-alpha03")
system tracingAndroid は、と の2 つのレベルのトレースをサポートしていますmethod tracing。
-
system tracing特別にマークされた領域のみを追跡するためtracing、オーバーヘッドが低く、アプリケーションのパフォーマンスに大きな影響を与えません。system tracingコードの特定の部分がどれくらいの時間実行されているかを確認するのに最適です。 -
method tracingアプリケーション内のすべての関数呼び出しをトレースします。これは非常にコストがかかるため、アプリケーションのパフォーマンスに大きな影響を与える可能性がありますが、何が起こっているのか、どの関数が呼び出されているか、どのくらいの頻度で呼び出されているかを完全に把握できます。
デフォルトでは、system tracing個々のコンポーズ可能な関数は含まれていません。で入手可能ですmethod tracing。ただし、トレース作成をオンにすると、再構成を含むシステム トレースを実行すると、システム トレース内にコンポーズ可能な関数が自動的に表示されます。system tracingこれは、の低侵入性とmethod tracing詳細レベルの両方を活用します。
システムトレース
システム トレースを取得し、新しい再編成トレースの動作を確認するには、次の手順に従います。
1.プロファイラーを開きます。
2. CPU タイムラインをクリックします。
3. CPU を選択し、[システム トレース]を選択して、[記録]ボタンをクリックします。
4. アプリに移動して、追跡する UI インターフェイスを操作し、[停止] ボタンをクリックします。
5. 再編成トレースでコンポーザブルを確認できるようになります。キーボード (WASD) とマウスを使用してトレースをズームしたりパンしたりできます。図内の結合可能な項目をダブルクリックすると、そのソース コードが表示されます。
AS で表示する場合は、主に Threads の下の主軸を表示します。
6. フレーム グラフでは、コンポーザブル、ファイル番号、行番号も確認できます。
AS ではパネルが小さいので不便に感じますが、トレース記録結果を右クリックしてファイルをエクスポートし、[ https://ui.perfetto.dev/でトレース ファイルを開く] を選択してファイルをインポートすることもできます。閲覧用に。（このウェブサイトは比較的広くて操作しやすいです）
インポート後、アプリケーションのパッケージ名 (applicationId) を見つけて、Choreographer#doFrame下のボックスに注目します。
特定のコンポーザブル バーの下に長時間空白のギャップがある場合は、誰かがコンポーザブルの再編成呼び出しをブロックしていることを意味します。
この場合、大きなオブジェクトがあるか、時間のかかるメソッドが存在することが考えられます。
trace疑わしい場所には次のマークを付けることができます。
システム追跡のために再実行した後、長い空白のギャップが確かに疑わしいマークで埋められていることが判明し、推測が検証されました。
解決策は、remember初回のみ消費し、その後の再編成が毎回再作成されないようにラッピングを使用することです。
もちろん、Kotlin コルーチンを使用して、時間のかかる部分をメインスレッドから実行することもできます。
APK サイズのオーバーヘッド
私たちの目標はこの機能のオーバーヘッドを最小限に抑えることですが、Compose コンパイラーが APK に埋め込まれた文字列を追跡するため、Compose アプリの APK サイズは増加します。アプリケーションが Compose をあまり使用しない場合、またはより大きな完全な Compose アプリケーションである場合、このサイズの増加は比較的小さい可能性があります。これらのトレース文字列は難読化されていないため、前に示したようにトレース ツールに表示できます。バージョン 1.3.0 以降、Compose コンパイラはこれらをすべてのアプリケーションに挿入します。
次のプロガード ルールを追加することで、運用ビルドでトレース文字列を削除できます。
-assumenosideeffects public class androidx.compose.runtime.ComposerKt {
boolean isTraceInProgress();
void traceEventStart(int,int,int,java.lang.String);
void traceEventStart(int,java.lang.String);
void traceEventEnd();
}
これらの機能は将来変更される可能性がありますが、変更があれば Compose のリリース ノートに記載されます。
それらを保持すると、APK サイズのコストが発生しますが、分析される APK がアプリ ユーザーが実行しているものと同じであることが保証されることに注意してください。
上記の参考資料は公式サイトからのものです。 構成トレースの概要とデバッグ Jetpack Compose
コンポジション トレースを試すには、最新バージョンの Android Studio を使用することをお勧めします。現在、Flamingo を使用して公式の設定に従って試してみますが、最終的に失敗します。設定には問題ありませんが、コンポーザブル関数の名前ができませんシステム トレースによって生成されたトレース レコードで見つかります。ただし、正式機能もテスト中であり、将来的には安定版がリリースされるはずです。