このページは日本語には対応しておりません。随時翻訳に取り組んでいます。
翻訳に関してご質問やご意見ございましたら、
お気軽にご連絡ください。
概要
Real User Monitoring は、Android Vitals や Apple の MetricKit などのフレームワークにインスピレーションを得た一連のデータポイントを含む「モバイルバイタル」を提供し、モバイルアプリケーションの応答性、安定性、リソース消費に関するインサイトの取得に役立てることができます。「モバイルバイタル」は、不良、中程度、良好の 3 種類に分類されます。
アプリケーションのモバイルバイタルは、Digital Experience > Performance Summary に移動してアプリケーションを選択することで表示できます。
RUM モバイルアプリのパフォーマンスダッシュボードにアクセスするには、Performance タブに切り替え、View Dashboard リンクをクリックします。
様々なアプリケーションのバージョンに渡るデータポイントを表示する折れ線グラフで、アプリケーションの全体的な健全性とパフォーマンスを理解することができます。アプリケーションのバージョンでフィルターをかけたり、特定のセッションやビューを表示するには、グラフをクリックしてください。
また、RUM エクスプローラーでビューを選択し、セッションでのアプリケーションのユーザー体験に直接関連する推奨ベンチマーク範囲を観察することができます。Refresh Rate Average などのメトリクスをクリックし、Search Views With Poor Performance (パフォーマンスの悪いビューを検索) をクリックすると、検索クエリにフィルターが適用され、追加のビューが調査されます。
テレメトリー
以下のテレメトリーで、モバイルアプリケーションのパフォーマンスに関するインサイトを提供します。
| 測定項目 | 説明 |
|---|
| リフレッシュレート | スムーズで素早い動作のユーザーエクスペリエンスを確保するには、アプリケーションのフレームレンダリングが 60Hz 以下である必要があります。
RUM は、@view.refresh_rate_average および @view.refresh_rate_min ビュー属性を使用して、アプリケーションのメインスレッドディスプレイのフレッシュレートを追跡します。
注: リフレッシュレートは、0～60 fps の範囲で標準化されています。たとえば、120fps のレンダリングが可能なデバイスでアプリケーションが 100fps で実行している場合、Datadog のモバイルバイタルで 50fps と報告されます。 |
| 遅延レンダリング | スムーズで素早い動作のユーザーエクスペリエンスを確保するには、アプリケーションのフレームレンダリングが 60Hz 以下である必要があります。
RUM は、@view.refresh_rate_average および @view.refresh_rate_min ビュー属性を使用して、アプリケーションのディスプレイのフレッシュレートを追跡します。
遅延レンダリングで、16ms または 60Hz 以上かかっているビューを監視できます。
注: リフレッシュレートは、0～60 fps の範囲で標準化されています。たとえば、120fps のレンダリングが可能なデバイスでアプリケーションが 100fps で実行している場合、Datadog のモバイルバイタルで 50fps と報告されます。 |
| フレームのフリーズ | 700ms 以上でレンダリングされるフレームは、アプリケーション上でスタック、または無反応のように見えます。これはフレームのフリーズと分類されます。
RUM は、完了までに 100ms 以上かかったタスク実行時間のある long task イベントを追跡します。
フレームのフリーズで、エンドユーザーにフリーズしているように表示される (レンダリングに 700ms 以上かかっている) ビューを監視し、アプリケーション内の動作の遅れを排除できます。 |
| アプリケーションの無反応 | アプリケーションの UI スレッドが 5 秒以上ブロックされると、Application Not Responding (ANR) エラーがトリガーされます。アプリケーションが前景にある場合、システムによりユーザーにモーダルダイアログが表示され、アプリケーションの強制終了が可能になります。
RUM では、ANR の発生を追跡し、ANR が起きた場合にメインスレッドをブロックするスタックトレースの全体をキャプチャします。 |
| バージョン別クラッシュフリーセッション | 通常、未処理の例外またはシグナルが原因でアプリケーションが予期せず終了すると、アプリケーションのクラッシュが報告されます。アプリケーションにおいて、クラッシュのないユーザーセッションはユーザーエクスペリエンスと全体的な満足度に直接的につながります。
RUM では、完全なクラッシュレポートを追跡し、Error Tracking で経時的な傾向を把握できます。
クラッシュフリーセッションで、業界基準の速度を維持し、Google Play ストアでアプリケーションを高位置にランク入りさせることが可能になります。 |
| 毎秒の CPU ティック | CPU の使用量が多いと、ユーザーのデバイスのバッテリー寿命に影響します。
RUM は、各ビューの 1 秒あたりの CPU ティックと、セッション中の CPU 使用率を追跡します。推奨範囲は、良好な場合は 40 未満、中程度の場合は 60 未満です。
選択した期間の平均で CPU ティック数が最も多い上位ビューは、アプリケーションの Overview ページの Mobile Vitals で見ることができます。 |
| メモリ使用状況 | メモリの使用量が多いと、OutOfMemoryError が発生し、アプリケーションがクラッシュして、ユーザーエクスペリエンスが低下する可能性があります。
RUM は、セッション中に各ビューでアプリケーションが使用する物理メモリの量をバイト単位で追跡します。推奨範囲は、良好な場合は 200MB 未満、中程度の場合は 400MB 未満です。
選択した期間の平均で最もメモリを消費した上位のビューは、アプリケーションの Overview ページの Mobile Vitals で確認できます。 |
| 測定項目 | 説明 |
|---|
| リフレッシュレート | スムーズで素早い動作のユーザーエクスペリエンスを確保するには、アプリケーションのフレームレンダリングが 60Hz 以下である必要があります。
RUM は、@view.refresh_rate_average および @view.refresh_rate_min ビュー属性を使用して、アプリケーションのメインスレッドディスプレイのフレッシュレートを追跡します。
注: リフレッシュレートは、0～60 fps の範囲で標準化されています。たとえば、120fps のレンダリングが可能なデバイスでアプリケーションが 100fps で実行している場合、Datadog のモバイルバイタルで 50fps と報告されます。 |
| 遅延レンダリング | スムーズで素早い動作のユーザーエクスペリエンスを確保するには、アプリケーションのフレームレンダリングが 60Hz 以下である必要があります。
RUM は、@view.refresh_rate_average および @view.refresh_rate_min ビュー属性を使用して、アプリケーションのディスプレイのフレッシュレートを追跡します。
遅延レンダリングで、16ms または 60Hz 以上かかっているビューを監視できます。
注: リフレッシュレートは、0～60 fps の範囲で標準化されています。たとえば、120fps のレンダリングが可能なデバイスでアプリケーションが 100fps で実行している場合、Datadog のモバイルバイタルで 50fps と報告されます。 |
| フレームのフリーズ | 700ms 以上でレンダリングされるフレームは、アプリケーション上でスタック、または無反応のように見えます。これはフレームのフリーズと分類されます。
RUM は、完了までに 100ms 以上かかったタスク実行時間のある long task イベントを追跡します。
フレームのフリーズで、エンドユーザーにフリーズしているように表示される (レンダリングに 700ms 以上かかっている) ビューを監視し、アプリケーション内の動作の遅れを排除できます。 |
| バージョン別クラッシュフリーセッション | 通常、未処理の例外やシグナルによりアプリケーションが予期せず終了した場合、アプリケーションのクラッシュ が報告されます。アプリケーションにおいて、クラッシュのないユーザーセッションはユーザーエクスペリエンスと全体的な満足度に直接的につながります。
RUM では、完全なクラッシュレポートを追跡し、Error Tracking で経時的な傾向を把握できます。
クラッシュフリーセッションにより、業界のベンチマークに遅れを取ることなく、Apple App Store でアプリケーションを高いランキングに保つことができます。 |
| ハングレート | Apple の定義によると、アプリケーションのハングレートは、「250 ミリ秒以上の無応答の時間だけをカウントして、アプリが無応答である 1 時間あたりの秒数」に相当します。Datadog でアプリのハングレートを計算するには、アプリハングレポートを有効にし、専用セクションに従ってください。 |
| 毎秒の CPU ティック | CPU の使用量が多いと、ユーザーのデバイスのバッテリー寿命に影響します。
RUM は、各ビューの 1 秒あたりの CPU ティックと、セッション中の CPU 使用率を追跡します。推奨範囲は、良好な場合は 40 未満、中程度の場合は 60 未満です。
選択した期間の平均で CPU ティック数が最も多い上位ビューは、アプリケーションの Overview ページの Mobile Vitals で見ることができます。 |
| メモリ使用状況 | メモリの使用量が多いと、Watchdog の終了が発生し、ユーザーエクスペリエンスが低下する可能性があります。
RUM は、セッション中に各ビューでアプリケーションが使用する物理メモリの量をバイト単位で追跡します。推奨範囲は、良好な場合は 200MB 未満、中程度の場合は 400MB 未満です。
選択した期間の平均で最もメモリを消費した上位のビューは、アプリケーションの Overview ページの Mobile Vitals で確認できます。 |
| 測定項目 | 説明 |
|---|
| リフレッシュレート | スムーズで素早い動作のユーザーエクスペリエンスを確保するには、アプリケーションのフレームレンダリングが 60Hz 以下である必要があります。
RUM は、@view.refresh_rate_average および @view.refresh_rate_min ビュー属性を使用して、アプリケーションのメインスレッドディスプレイのフレッシュレートを追跡します。
注: リフレッシュレートは、0～60 fps の範囲で標準化されています。たとえば、120fps のレンダリングが可能なデバイスでアプリケーションが 100fps で実行している場合、Datadog のモバイルバイタルで 50fps と報告されます。 |
| 遅延レンダリング | スムーズで素早い動作のユーザーエクスペリエンスを確保するには、アプリケーションのフレームレンダリングが 60Hz 以下である必要があります。
RUM は、@view.refresh_rate_average および @view.refresh_rate_min ビュー属性を使用して、アプリケーションのディスプレイのフレッシュレートを追跡します。
遅延レンダリングで、16ms または 60Hz 以上かかっているビューを監視できます。
注: リフレッシュレートは、0～60 fps の範囲で標準化されています。たとえば、120fps のレンダリングが可能なデバイスでアプリケーションが 100fps で実行している場合、Datadog のモバイルバイタルで 50fps と報告されます。 |
| フレームのフリーズ | 700ms 以上でレンダリングされるフレームは、アプリケーション上でスタック、または無反応のように見えます。これはフレームのフリーズと分類されます。
RUM は、完了までに 100ms 以上かかったタスク実行時間のある long task イベントを追跡します。
フレームのフリーズで、エンドユーザーにフリーズしているように表示される (レンダリングに 700ms 以上かかっている) ビューを監視し、アプリケーション内の動作の遅れを排除できます。 |
| アプリケーションの無反応 | Android の場合、アプリケーションの UI スレッドが 5 秒以上ブロックされると、Application Not Responding (ANR) エラーがトリガーされます。アプリケーションが前景にある場合、システムによりユーザーにモーダルダイアログが表示され、アプリケーションの強制終了が可能になります。
RUM では、ANR の発生を追跡し、ANR が起きた場合にメインスレッドをブロックするスタックトレースの全体をキャプチャします。 |
| バージョン別クラッシュフリーセッション | 通常、未処理の例外またはシグナルが原因でアプリケーションが予期せず終了すると、アプリケーションのクラッシュが報告されます。アプリケーションにおいて、クラッシュのないユーザーセッションはユーザーエクスペリエンスと全体的な満足度に直接的につながります。
RUM では、完全なクラッシュレポートを追跡し、Error Tracking で経時的な傾向を把握できます。
クラッシュフリーセッションで、業界基準の速度を維持し、Google Play ストアでアプリケーションを高位置にランク入りさせることが可能になります。 |
| 毎秒の CPU ティック | CPU の使用量が多いと、ユーザーのデバイスのバッテリー寿命に影響します。
RUM は、各ビューの 1 秒あたりの CPU ティックと、セッション中の CPU 使用率を追跡します。推奨範囲は、良好な場合は 40 未満、中程度の場合は 60 未満です。
選択した期間の平均で CPU ティック数が最も多い上位ビューは、アプリケーションの Overview ページの Mobile Vitals で見ることができます。 |
| メモリ使用状況 | メモリの使用量が多いと、メモリ不足によるクラッシュが発生し、ユーザーエクスペリエンスが低下する可能性があります。
RUM は、セッション中に各ビューでアプリケーションが使用する物理メモリの量をバイト単位で追跡します。推奨範囲は、良好な場合は 200MB 未満、中程度の場合は 400MB 未満です。
選択した期間の平均で最もメモリを消費した上位のビューは、アプリケーションの Overview ページの Mobile Vitals で確認できます。 |
| ウィジェット構築時間 | これは UI スレッドでフレームを構築するのにかかる時間です。スムーズなアニメーションを保証するために、60 FPS の場合は 16ms、120 FPS の場合は 8ms を超えないようにしてください。
この値が高い場合は、このビューの構築方法を最適化する必要があることを意味します。Flutter ドキュメントの Control Build Cost を参照してください。 |
| ラスター時間 | これはラスタースレッドでフレームをラスタライズするのにかかる時間です。スムーズなアニメーションを保証するために、60 FPS の場合は 16ms、120 FPS の場合は 8ms を超えないようにしてください。
この値が高い場合は、ビューのレンダリングが複雑であることを意味します。Flutter ドキュメントの [Identifying Problems in the GPU Graph][12] を参照してください。 |
| 測定項目 | 説明 |
|---|
| リフレッシュレート | スムーズで素早い動作のユーザーエクスペリエンスを確保するには、アプリケーションのフレームレンダリングが 60Hz 以下である必要があります。
RUM は、@view.refresh_rate_average および @view.refresh_rate_min ビュー属性を使用して、アプリケーションのメインスレッドディスプレイのフレッシュレートを追跡します。
注: リフレッシュレートは、0～60 fps の範囲で標準化されています。たとえば、120fps のレンダリングが可能なデバイスでアプリケーションが 100fps で実行している場合、Datadog のモバイルバイタルで 50fps と報告されます。 |
| JS リフレッシュレート | スムーズで素早い動作のユーザーエクスペリエンスを確保するには、アプリケーションのフレームレンダリングが 60Hz 以下である必要があります。
RUM は、@view.js_refresh_rate.average、@view.js_refresh_rate.min および @view.js_refresh_rate.max ビュー属性を使用して、アプリケーションの JavaScript スレッドディスプレイのフレッシュレートを追跡します。
注: リフレッシュレートは、0～60 fps の範囲で標準化されています。たとえば、120fps のレンダリングが可能なデバイスでアプリケーションが 100fps で実行している場合、Datadog のモバイルバイタルで 50fps と報告されます。 |
| 遅延レンダリング | スムーズで素早い動作のユーザーエクスペリエンスを確保するには、アプリケーションのフレームレンダリングが 60Hz 以下である必要があります。
遅延レンダリングでは、平均フレームレートが 55fps 未満のビューを監視できます。
注: リフレッシュレートは、0～60 fps の範囲で標準化されています。たとえば、120fps のレンダリングが可能なデバイスでアプリケーションが 100fps で実行している場合、Datadog のモバイルバイタルで 50fps と報告されます。 |
| フレームのフリーズ | 700ms 以上でレンダリングされるフレームは、アプリケーション上でスタック、または無反応のように見えます。これはフレームのフリーズと分類されます。
RUM は、完了までに 100ms 以上かかったタスク実行時間のある long task イベントを追跡します。
フレームのフリーズで、エンドユーザーにフリーズしているように表示される (レンダリングに 700ms 以上かかっている) ビューを監視し、アプリケーション内の動作の遅れを排除できます。 |
| アプリケーションの無反応 | アプリケーションの UI スレッドが 5 秒以上ブロックされると、Application Not Responding (ANR) エラーがトリガーされます。アプリケーションが前景にある場合、システムによりユーザーにモーダルダイアログが表示され、アプリケーションの強制終了が可能になります。
RUM では、ANR の発生を追跡し、ANR が起きた場合にメインスレッドをブロックするスタックトレースの全体をキャプチャします。 |
| バージョン別クラッシュフリーセッション | 通常、未処理の例外またはシグナルが原因でアプリケーションが予期せず終了すると、アプリケーションのクラッシュが報告されます。アプリケーションにおいて、クラッシュのないユーザーセッションはユーザーエクスペリエンスと全体的な満足度に直接的につながります。
RUM では、完全なクラッシュレポートを追跡し、Error Tracking で経時的な傾向を把握できます。
クラッシュフリーセッションで、業界基準の速度を維持し、Google Play ストアでアプリケーションを高位置にランク入りさせることが可能になります。 |
| 毎秒の CPU ティック | CPU の使用量が多いと、ユーザーのデバイスのバッテリー寿命に影響します。
RUM は、各ビューの 1 秒あたりの CPU ティックと、セッション中の CPU 使用率を追跡します。推奨範囲は、良好な場合は 40 未満、中程度の場合は 60 未満です。
選択した期間の平均で CPU ティック数が最も多い上位ビューは、アプリケーションの Overview ページの Mobile Vitals で見ることができます。 |
| メモリ使用状況 | メモリの使用量が多いと、メモリ不足によるクラッシュが発生し、ユーザーエクスペリエンスが低下する可能性があります。
RUM は、セッション中に各ビューでアプリケーションが使用する物理メモリの量をバイト単位で追跡します。推奨範囲は、良好な場合は 200MB 未満、中程度の場合は 400MB 未満です。
選択した期間の平均で最もメモリを消費した上位のビューは、アプリケーションの Overview ページの Mobile Vitals で確認できます。 |
| 測定項目 | 説明 |
|---|
| リフレッシュレート | スムーズで素早い動作のユーザーエクスペリエンスを確保するには、アプリケーションのフレームレンダリングが 60Hz 以下である必要があります。
RUM は、@view.refresh_rate_average および @view.refresh_rate_min ビュー属性を使用して、アプリケーションのメインスレッドディスプレイのフレッシュレートを追跡します。
注: リフレッシュレートは、0～60 fps の範囲で標準化されています。たとえば、120fps のレンダリングが可能なデバイスでアプリケーションが 100fps で実行している場合、Datadog のモバイルバイタルで 50fps と報告されます。 |
| 遅延レンダリング | スムーズで素早い動作のユーザーエクスペリエンスを確保するには、アプリケーションのフレームレンダリングが 60Hz 以下である必要があります。
RUM は、@view.refresh_rate_average および @view.refresh_rate_min ビュー属性を使用して、アプリケーションのディスプレイのフレッシュレートを追跡します。
遅延レンダリングで、16ms または 60Hz 以上かかっているビューを監視できます。
注: リフレッシュレートは、0～60 fps の範囲で標準化されています。たとえば、120fps のレンダリングが可能なデバイスでアプリケーションが 100fps で実行している場合、Datadog のモバイルバイタルで 50fps と報告されます。 |
| バージョン別クラッシュフリーセッション | 通常、未処理の例外またはシグナルが原因でアプリケーションが予期せず終了すると、[アプリケーションのクラッシュ][5]が報告されます。アプリケーションにおいて、クラッシュのないユーザーセッションはユーザーエクスペリエンスと全体的な満足度に直接的につながります。
RUM では、完全なクラッシュレポートを追跡し、Error Tracking で経時的な傾向を把握できます。
クラッシュフリーセッションで、業界基準の速度を維持し、Google Play ストアでアプリケーションを高位置にランク入りさせることが可能になります。 |
| ハングレート | Apple の定義によると、アプリケーションのハングレートは、「250 ミリ秒以上の無応答の時間だけをカウントして、アプリが無応答である 1 時間あたりの秒数」に相当します。Datadog でアプリのハングレートを計算するには、Datadog の設定で “Track Non-Fatal App Hangs” を有効にしてください。 |
| 毎秒の CPU ティック | CPU の使用量が多いと、ユーザーのデバイスのバッテリー寿命に影響します。
RUM は、各ビューの 1 秒あたりの CPU ティックと、セッション中の CPU 使用率を追跡します。推奨範囲は、良好な場合は 40 未満、中程度の場合は 60 未満です。
選択した期間の平均で CPU ティック数が最も多い上位ビューは、アプリケーションの Overview ページの Mobile Vitals で見ることができます。 |
| メモリ使用状況 | メモリの使用量が多いと、Watchdog の終了が発生し、ユーザーエクスペリエンスが低下する可能性があります。
RUM は、セッション中に各ビューでアプリケーションが使用する物理メモリの量をバイト単位で追跡します。推奨範囲は、良好な場合は 200MB 未満、中程度の場合は 400MB 未満です。
選択した期間の平均で最もメモリを消費した上位のビューは、アプリケーションの Overview ページの Mobile Vitals で確認できます。 |
その他の参考資料
