新しいMetricKitについて

こんにちは、私はYonniです。MetricKitチームの エンジニアです。

優れたアプリとゲームは、 パフォーマンスを監視・最適化します 実際の世界で、実際のデバイス上で。 MetricKitは、アプリの体験品質に関する リアルなインサイトを提供できる フレームワークです。 このセッションでは、まず MetricKitの概要から始め、 iOS 27での新機能についてお伝えします。 次に、最初のメトリクスレポートを 受け取る方法をご紹介します。 最初の診断レポートについても。 そして最後に、さらに豊富なデータを得るため アプリ内の特定の領域に パフォーマンス問題を結びつける方法を探ります。

まず、フレームワークの 概要から説明します。 アプリのパフォーマンスを最適化することは プロセスです。 データを収集することから始め、 問題を特定するために分析します。 各問題に対して、 根本原因を見つけるためにトリアージし、 修正して、結果を監視するために ステップ1に戻ります。 MetricKitは、そのワークフローの 収集部分を担います。 フレームワークは2種類のデータを提供します： メトリクスと診断情報です。 メトリクスは、パフォーマンスの 特定の領域が 全体的に改善しているか悪化しているかを 把握するのに役立ちます。 一方、診断情報は、どのコードパスが パフォーマンス問題を引き起こしているかを教えてくれます。

iOS 27では、フレームワークが ゼロから再構築されました 文脈豊かで表現力のある モダンなSwiftファーストAPIで。 新しいMetricKit APIは フレームワークの未来です。 本日ご紹介するすべての進化は この新しいAPIセットのみに 提供されるものです。 メトリクスは、アプリの 継続的な健全性に関するシグナルです。 起動時間、ハング、アニメーションのメトリクスは アプリがどれだけ レスポンシブでスムーズかを示します。 起動が遅いとユーザーをイライラさせ、 アプリを離れる原因になります。 一方、高速な起動により アプリのコア体験にすぐアクセスできます。

CPU、GPU、ディスク書き込み、ネットワーク転送などの リソース消費メトリクスは アプリがどれだけ負荷をかけているか、 デバイスの健全性にどう影響しているかを示します。

例えば、MetricKitの起動時間として 「初回描画時間」メトリクスがあります。 特定の時間範囲バケットに収まる 起動回数のヒストグラムを提供します。 このグラフは、アプリの起動にかかった 時間を示しています。 1日の間、誰かがアプリを開くたびに 記録されたものです。 ほとんどの起動は510〜540ミリ秒の間で、 いくつかの外れ値があります。 継続的なパフォーマンスを追跡することもできます MetricKitが提供するデータから 独自のインサイトを導き出すことで。 例えば、このアプリについて MetricKitが報告したところによると、 アプリの使用中に平均3秒の 合計ハング時間がありました。 アプリが30分間使用された間にです。 この情報を使って、1時間あたり6秒の 平均ハング率を導出できます。 すべてのデバイスにわたって このデータを集計すれば、 アプリのパフォーマンスのトレンドを 測定可能なシグナルとして得られます。

iOS 27では、MetricKitが 各メトリクスを提供できるようになりました アプリのステートの関数として。 例えば、複数のタブを持つアプリで ハング時間を測定する場合、 MetricKitはアクティブなタブが タブ1、タブ2、またはタブ3のときと 交差したメトリクスを提供できます。 これについては後ほど詳しく説明します。 iOS 27では、MetricKitが新しいメトリクス Metal フレームレートも提供するようになりました。 フレームレートは重要なメトリクスです ゲーム開発者がレンダリングパフォーマンスを 理解するための。 プラットフォーム向けにゲームを最適化する 詳細については、セッションをご覧ください 「Metal ゲームのパフォーマンス問題を 見つけて修正する」。 メトリクスに加えて、 MetricKitは診断情報も提供します。 診断情報には、特定するのに役立つ 有用な情報が含まれています どのコードパスが パフォーマンス問題を引き起こしたかを 調査して修正できるよう。

iOS 27では、MetricKitが メモリ例外診断を提供します。 アプリや拡張機能がメモリ制限を 超えて終了した際に、 何が起きたかについてより詳しいインサイトが得られます。

アプリがパフォーマンスメトリクスを取得する方法を 詳しく探っていきましょう。 人々が1日を通してアプリを使用する中で、 MetricKitは継続的にメトリクスを収集します アプリの起動、ハング、メモリ、CPUなど そしてそれを日次レポートとして アプリに配信します。 このレポートでは、MetricKitはアプリの 1日全体の使用状況をカバーするエントリを提供します。 また、より小さな内訳として 別のエントリも提供します。 通常、それぞれ数時間ごとです。 これらの小さな内訳は 関連するメトリクスがある場合にのみ 存在します。 データの構造はこのようになっています。 各インターバルの中で、 メトリクスはメトリクスグループに整理されます。 各グループはシステムの 一側面を表します。 .cpu、.memory、 .display、.gpuなどです。 グループの中には、個々の パフォーマンスメトリクスがあります。

コードで説明しましょう。 エントリーポイントは MetricManagerクラスです。 レポートを受信するには、 metricReportsプロパティを通じてawaitします。 このセットアップはアプリ起動時に行う必要があります サブスクリプションの遅延による データ損失を避けるために。 MetricManagerは生き続けている必要があります 後続のデータが準備できた際に ストリームがレポートを配信し続けられるよう。 これらわずかな行だけで、アプリは 構造化されたメトリクスデータを受信できるようになります。 通常は、これらのメトリクスを サーバーに送信したいでしょう 多くのデバイスにわたって アプリの健全性を調べられるよう。 MetricReportsはCodableに対応しており、 エンコードが簡単です JSONのような形式に変換して サーバーに送信できます。 JSONEncoderを作成して レポート全体をエンコードするだけです。

特定のメトリクスグループや特定の値だけに アクセスしたい場合は、 メトリクスレポートをさらに 詳しく調べることもできます。 そのためには、 intervalEntriesを反復処理します。 これには、1日全体を集計したエントリが含まれます 利用可能な場合は小さな内訳ウィンドウも。 次に、興味のあるグループに メトリクスを絞り込みます。 この場合、memoryMetricsには メモリグループのメトリクスのみが含まれます。 最後に、メトリクスのケースを switchで処理します アクセスしたいメトリクスの種類を このレポートでのそのメトリクスの値と共に。 この場合、コードはpeakMemoryの値のみを 処理します。 この処理はデタッチされたタスクまたは 専用のサービスクラスで行います アプリが起動したらすぐに。

ワークフローに戻りましょう。 これで収集フェーズが 完了しました。 分析に移る準備が整いました。

すべてのデバイスにわたるメトリクスの分析は データサイエンスの問題です。 この分析を可能にするには、 サーバーをセットアップする必要があります これらのレポートを取り込める そして、重要なディメンションに従って 集計できるサーバーを。 最適な統計分析が何かを 決定する必要があります 生成したいデータと 見つけたいインサイトに対して。 カスタム集計を使用することで、 ベースラインを得られます。 アプリがすでにどのように パフォーマンスを発揮しているかの把握です。 そして、集計されたメトリクスを監視して 状況が改善されているか 悪化しているかを検知します。

メトリクスを使ってアプリの問題を 特定する方法をご紹介しました。 次は、診断情報を使ってこれらの問題を 修正する方法についてお話しします。

メトリクスはアプリを監視する 優れた方法です。 メトリクスを収集し、 長期的にパフォーマンスを監視しながら、 ワークフローのトリアージフェーズに 入ることができます。 診断情報は、このフェーズで 特に役立ちます。

クラッシュやハングのような 問題が発生した場合、 システムはデバイス上で 診断情報をキャプチャします。 診断レポートは詳細情報を パッケージ化して MetricKitを通じて すぐにアプリに配信します。 その中には、問題をトリアージするための 有用な情報が含まれています。 例えば、多くの診断情報には バックトレースが含まれており イベント発生時の正確な コールスタックを確認できます。

最も重要な診断情報の1つは クラッシュに関するものです。 クラッシュ診断はバックトレースを 提供するだけでなく、 アプリが終了した理由も示します また、どのような種類の障害かを 示す例外タイプも含まれます。

iOS 27では、終了カテゴリが 各クラッシュがメトリクスで どのように記録されたかを示すようになりました。 これにより、 異常終了が増加傾向にある場合、 それらを個々の診断情報と 直接関連付けることができます。 この例では、シンボリケートされたバックトレースが スレッド開始時点のシステムから始まっています。 実行が下方に流れるにつれて、 アプリのコードに入ります。 クラッシュ箇所を見つけるには、 呼び出しを末端まで追うことができます。 ここで、実行はアプリの submitReport()関数に達して停止します。 これは、実行パスにおける 障害点がここであることを示しています。

この情報を使って、この関数への 修正を対象にできます。 診断レポートを取得するには、 MetricManagerインスタンスの diagnosticReportsをawaitします。 MetricReportsと同様に、アプリが起動したら すぐにこのストリームのリスニングを開始します デタッチされたタスクまたは 専用のサービスクラスで。

MetricReportsと同様に、 DiagnosticReportsはCodableです。 このコードは受信した diagnosticReportsをawaitし、 JSONEncoderを使って JSONにエンコードします。 これで、この診断情報をすべて 分析サーバーに送信できます。

診断レポートも構造化されているので、 受信したいものを 選択することができます。 例えば、このコードは diagnosticReportsをawaitして、 さまざまな種類の診断情報の ケースをスイッチします。 クラッシュ診断の場合、 バックトレースを抽出します。 理由とカテゴリも。 この情報はアプリで 処理できます。 サーバーに送信するなど。 ハング診断の場合、 ハングケースを使って そのレポートを別の方法で処理できます。

アプリのメトリクスと診断レポートの 取得方法についてお話ししました。 次に、このデータを 文脈化する方法をご紹介します。 これまで、MetricKitが提供する メトリクスと診断情報は、 アプリのパフォーマンスの 全体的な状況を表しています。 しかし、個々の問題を調査するには、 より豊富で詳細なデータが必要な場合があります アプリの状態について より多くを伝える ユーザーフローや アプリの設定方法など。 MetricKitは文脈化されたデータを提供できます アプリについて定義した 意味のある情報に基づいた。 例を見てみましょう。 私は経費申請アプリを持っています。 従業員がレシートをスキャンして、 経費を申請し、カテゴリと予算別に 支出を追跡できます。 これらの機能は、Reportsタブと Spendingタブに整理されています。

私はスクロールヒッチのメトリクスに 注目しています。 1日の間に、 アプリの合計ヒッチ時間が 4.5秒あったことを示しています 5分間のスクロール中に。 それは1秒あたり15ミリ秒の ヒッチレートです。 しかし、それはすべてのアプリ使用にわたる 平均スクロールヒッチレートです。 ユーザーがReportsタブとSpendingタブを 行き来していても。 このメトリクスがどのようなアプリの条件下で 収集されたかを知るために、 StateReportingフレームワークを通じて アプリの状態を報告できます。 今から探っていきます。

状態とは、アプリの設定を説明するために 定義する情報です または動作を表し、MetricKitが メトリクスを集計できるようにします それらの特性の関数として。 ユーザーがアプリを使用するにつれて、 パラメータは使用方法に応じて 変化することがあります。

経費アプリでは、ユーザーは使用中に タブ間を移動するかもしれません。 Reportsタブで新しい経費を追加して アプリを離れ、 Spendingタブに戻ってくるかもしれません 日々の食費予算を 確認したいときに。 アプリがこれらの状態間を 遷移するにつれて、 これらの遷移を報告します。 そして、MetricKitはそれらを メトリクスと診断データと交差させます。

各状態にさらに詳細を 追加することもできます カスタム構造化タイプを追加することで。 経費アプリでは、ビュー内のアイテムについての 詳細が考えられます。 取引リストが小・中・大の リストと見なされるかどうか そのリストの取引が ソートされているかどうかなど。

これで、これらすべての状態にわたる 単一の混合メトリクスを得る代わりに、 例えば15 ms/sの総スクロールヒッチレートのような、 メトリクスは各個別の状態に対して 報告されます。 そして経費アプリでは、 各タブに個別のメトリクスがあります。 この例では、Spendingタブでの スクロールは非常にスムーズで、 ヒッチレートはわずか1 ms/sでした。 しかし、Reportsタブを スクロールすると、 ヒッチレートは71 ms/sに急上昇しました。 この粒度があれば、より焦点を絞った 結論を出すことができます： Spendingタブは良好なパフォーマンスです！ しかし、Reportsタブは 重大な中断が発生しています。 そこがまさに 最適化の取り組みを集中すべき場所です。

提供する各状態は ドメインにスコープされています。 ドメインはアプリの機能や 領域を表します。 ドメインは特定の時点で 1つのアクティブな状態しか持てません。 別々のドメインを使うと、複数の状態を 同時に保持できます。 経費アプリでは、 実験的な変更をテストしていて、 パフォーマンスに役立つかどうかを 知りたいと思っています。 実験をオンにすると、 経費はデータベースから 小さなバッチで取得されます。 オフにすると、 代わりに大きなバッチを使用します。 タブの状態を配置することで バッチサイズの状態を 別々のドメインに配置することで、 MetricKitは各タブと各バッチサイズに対して 別々のメトリクスを配信します。

状態は遷移モデルに従います。 アプリは移行先の状態を報告します。 MetricKitはその状態に どれだけ留まるかを追跡します。 開始と終了のペアはなく、 アプリは現在いる状態を報告します。 任意の時点で。

アプリで状態を報告するには、まず StateReportingフレームワークをインポートします。 次に、ドメインを作成します。 通常はリバースDNS文字列です。 MetricManagerインスタンスを セットアップする際に登録します。 最後に、アプリが定義した状態に入るときに 遷移を報告します。 この場合、アプリは 状態に遷移します 文字列「Reports」で識別される。 データをさらに詳細化したい場合は、 これらの状態に追加の 構造化情報を提供できます ReportableMetadataマクロを使って 独自のstructを定義することで。 次に、このメタデータタイプで 新しいStateReporterを作成します。 最後に、ラベルとカスタムタイプを含めて 遷移を報告します。 この例では「Reports」状態に遷移し、 ViewConfiguration structも 提供します listSizeの値と、このリストのアイテムが ソートされているかどうかを含む。

アプリに状態を追加する前は、 メトリクスレポートはアプリの すべての使用状況にわたる広範なメトリクスを提供します。 stateEntriesプロパティには 状態を意識したメトリクスが含まれます。 報告された状態がない場合、 これは空になります。 状態を追加した後、MetricReportには StateEntry値が含まれるようになります。 状態エントリはアプリのメトリクスを 認識する別の方法を提供します。 各状態には独自のStateEntryがあり、 その個別の状態で過ごした時間にわたって 集計されたメトリクス値が含まれます。 このデータを分析サーバーに 送信する準備ができたら、 MetricReportデータを状態報告ドメイン別に グループ化することを選択できます。 JSONEncoderを設定して 状態エントリを各ドメイン別にグループ化します。 エンコーダーのuserInfoプロパティに encodingFormatKeyキーを設定します 値byStateReportingDomainに。 これで、レポートがエンコードされると、 状態エントリとインターバルエントリの両方が、 アプリのパフォーマンスメトリクスを 含みます。 レポートに存在する各ドメインと状態で グループ化されて。

状態を定義する際に覚えておくべき ベストプラクティスを紹介します。

ドメインは狭くスコープされるべきです。 各アプリ領域がその状態を持てるよう それらの状態のデータを 理解できるようにするために。

状態遷移は安定した意味のある フェーズを表す必要があります。 一時的なUIイベントではなく。 各状態の意味を慎重に検討して、 回帰が現れた場合に 修正を対象にするのに十分な情報を 状態が提供できるようにします。 アプリ内の状態遷移の数を 慎重に計画してください 各状態とドメインが生成するデータを どのように解釈する予定かを。 状態が多すぎると、 データが細かくなりすぎて 全体像の解釈が 実際に難しくなる可能性があります。 オーバーヘッドを最小化するために 状態数の上限もあります。 最後に、 Points of Interest intrumentを使って リリース前に報告する状態が 期待通りであることを検証してください。 MetricKitを使えば、パフォーマンスの問題を これまで以上に速く見つけて修正できます。 継続的にデータを監視して パフォーマンス作業のターゲットと 計画を立てましょう。

MetricManagerを使ってパフォーマンスメトリクスの 収集を開始し、 アプリの健全性を監視しましょう。

診断情報を分析して 改善の具体的な機会を特定しましょう。 アプリの重要な状態を報告することで 得られるデータを文脈化しましょう。 MetricKitが提供する 新しい種類のデータを探索しましょう。 メモリ診断や Metal フレームレートメトリクスなど。 最後に、MXMetricManager APIを 使用している場合は、 新しいMetricManager APIに 移行してください これらの新しい機能を すべて活用するために。 ありがとうございました。素晴らしいWWDCを！