ハイライト
iOS 13 では MetricKit が導入されており、開発者はユーザー デバイスから集約されたパフォーマンス メトリクスを収集できます。しかし、当時は MXMetricPayload しかありませんでした。ハング時間のヒストグラムに例外が表示されたり、長時間ハングしたりすることはありますが、根本的な原因はわかりませんでした。iOS 14 には、クラッシュ診断とハング診断を提供する MXDiagnosticPayload が追加されています。各診断には、完全なコール スタック情報が含まれています。
主要内容
MetricKit の位置付けは明確です。開発者が実際のユーザー デバイスを見ることができないギャップを埋めるものです。アプリが TestFlight または App Store に登録された後は、通常、ユーザーの手にデバイスを渡すことはできず、ユーザーに Instruments を開かせることもできません。MetricKit はデバイス上の電力とパフォーマンスのデータを受動的に収集し、24 時間ごとにペイロードに集約して、匿名データをアプリに渡します。
iOS 13 の MetricKit はすでに「このバージョンは遅いですか?」という質問に答えることができます。起動時間、CPU 時間、メモリなどの集約された指標が得られ、ビルド間の傾向の比較に適しています。問題は、集計された指標は症状を指摘することしかできないことです。たとえば、コールド スタートの数が異常に増加した場合、またはハング期間のヒストグラムに長期的なハングが表示された場合は、根本原因がまだ見つかりません。
iOS 14 用 MetricKit 2.0 は両方向に拡張されます。1 つ目は、CPU 命令、スクロール ヒット、アプリケーションの終了という新しい指標です。これらにより、開発者はワークロード、スクロールのスムーズさ、終了理由をより正確に測定できるようになります。2 つ目は、新しい診断 (ハング、CPU 例外、ディスク書き込み例外、クラッシュ) を追加することです。診断ペイロードとメトリック ペイロードは同じ日に配信され、開発者はトレンドとコール スタックを同じトラブルシューティング リンクに配置できます。
このセッションの中心的な価値は、インジケーター名をさらにいくつか増やすことではありません。これにより、オンラインのパフォーマンスの問題が「異常な曲線の表示」から「十分な位置情報の取得」へと前進します。MetricKit は依然として遅延があり、集約されたプライバシー保護データ ソースですが、リリース後のパフォーマンス回帰トリアージをサポートするのに十分なコール スタック ツリー、例外原因、および診断メタデータを提供し始めています。
詳細
MetricKit へのアクセスは依然としてサブスクリプション モデルです
(02:11) MetricKit の基本的なアクセス プロセスは変更されていません。アプリのリンクとインポートMetricKit、作成するMXMetricManager.shared、カスタムオブジェクトを準拠させるMXMetricManagerSubscriber、メトリック ペイロードを受信するメソッドを実装します。
import MetricKit
class MySubscriber: NSObject, MXMetricManagerSubscriber {
var metricManager: MXMetricManager?
override init() {
super.init()
metricManager = MXMetricManager.shared
metricManager?.add(self)
}
override deinit() {
metricManager?.remove(self)
}
func didReceive(_ payload: [MXMetricPayload]) {
for metricPayload in payload {
// Do something with metricPayload.
}
}
}
キーポイント:
MXMetricManager.sharedこれは、アプリが MetricKit フレームワークと対話するための入り口です。metricManager?.add(self)システムによって集約されたメトリック ペイロードのサブスクライブを開始します。metricManager?.remove(self)マネージャが無効なサブスクライバを保持しないように、オブジェクトが解放されたときにサブスクライブを解除します。didReceive(_ payload: [MXMetricPayload])日ごとに集計されたパフォーマンス メトリクスの配列を受け取ります。- トランスクリプトには、ユーザーのプライバシーを保護するためにペイロードが匿名データであることが明確に記載されています。
ワークロード、流暢性、終了理由を補う新しい指標
(05:21)MXCPUMetricCPU命令を追加しました。アプリの累積リタイア命令を毎日カウントします。 CPU 時間はクロック周波数の影響を受けます。CPU 命令は、ハードウェアおよび周波数に依存しないワークロード指標であり、変更によって本当に CPU の動作が増加するかどうかを判断するのに適しています。
(05:48) スクロール ヒットはグラフィックス パフォーマンスを重視しています。セッションでは、スクロール時に予期された時間に画面に表示されないフレームとしてヒッチを定義します。ユーザーに見える結果は、アニメーションが滑らかではないということです。MetricKit はアプリを提供しますUIScrollViewスクロール中にヒッチが発生する時間の割合。
(06:28) アプリケーションの終了には、フォアグラウンドとバックグラウンドの終了理由の日次概要が表示されます。「退出した回数」をカウントするだけでなく、理由や回数ごとに内訳も表示します。Apple は、この種のデータが、バックグラウンドで実行されているフレームワークを使用するときに発生する起動時の問題や一般的な終了時の問題のトラブルシューティングに役立つことを特に指摘しています。
キーポイント:
- CPU 命令は、アプリが CPU 上で実行する実際の作業量を測定するために使用されます。
- スクロールヒッチは、スクロールヒッチをオンラインで集計可能な比例インジケーターに変えます。
- アプリケーションの終了 フォアグラウンドおよびバックグラウンドの終了理由を同日のパフォーマンス ペイロードに組み込みます。
- これらのメトリクスは、回帰傾向を形成するために、バージョン番号、デバイス タイプ、リリース バッチとともに保存するのに適しています。
診断とメトリクスは同じパイプラインを通過します
(08:14) iOS 14 の新しい診断では、コレクション アーキテクチャを書き直す必要はありません。サブスクライバは、別の受信を実装している限り、同じプロトコルを使用し続けます。MXDiagnosticPayload方法。
func didReceive(_ payload: [MXDiagnosticPayload]) {
for diagnosticPayload in payload {
// Consume diagnosticPayload.
}
}
キーポイント:
- メソッドの署名と受信
MXMetricPayloadバージョンはほぼ同じです。 - トランスクリプトには、診断のセマンティクスが基本的にメトリクスと同じであることが明確に記載されています。
- システムは 1 日以内に診断情報を受動的に収集し、最終的にそれを毎日の診断ペイロードにパッケージ化します。
- 診断ペイロードは、同じ日のメトリック ペイロードに対応し、既存のレポートおよびバックエンド処理パイプラインの再利用に適しています。
MXDiagnosticPayloadオフラインで処理できるコールスタックツリーを提供します
(09:18) 診断インターフェイスは、いくつかのタイプの基本オブジェクトで構成されます。MXDiagnostic診断基本クラスです。MXDiagnosticPayload1日以内にすべての診断を実行できる対象であり、MXCallStackTree回帰が発生したときのバックトレースをカプセル化します。各診断には、特定のビルド バージョンなど、問題が発生したときのアプリのメタデータも含まれています。
(10:08)MXCallStackTreeのバックトレースはシンボル化されていないデータであり、設計目標はオフライン処理です。トランスクリプト記述 JSON には、バイナリ UUID、オフセット、名前、フレーム アドレスなど、ATOS シンボル化に必要な情報が含まれています。この構造は、同じ年に Apple がリリースした他のパフォーマンス ツールにも登場します。
キーポイント:
MXDiagnosticPayloadアプリが集計値だけでなく、特定の診断を取得できるようにします。MXCallStackTreeリグレッションが発生したときにコールスタックツリーを保存します。- コールスタックはデフォルトではシンボル化されず、シンボルテーブルと組み合わせてデバイスの外部で処理する必要があります。
- バックエンドは、日付、バージョン、ビルドに基づいて、メトリック ペイロードの傾向を診断ペイロードのコール スタックに関連付けることができます。
4 種類の診断は、ハング、CPU、ディスク書き込み、クラッシュをカバーします。
(11:15) ハング診断は、アプリがユーザー入力に長時間応答しない状況を記録します。セッションは、メイン スレッドがブロックされている、またはビジーである理由を明確に示しており、ペイロードは、メイン スレッドが応答しない期間と、メイン スレッドのバックトレースを提供します。
(11:35) CPU 例外診断は、Xcode Organizer のエネルギー ログに対応します。これには、CPU 使用率が高い期間に消費された CPU 時間、合計サンプリング時間、および CPU 時間を消費したスレッド バックトレースが含まれます。ローカルでの再現が難しい CPU 回帰の処理に適しています。
(11:59) ディスク書き込み例外診断は、CPU 例外診断と非常によく似ています。例外をトリガーした書き込みの合計数と、過剰な書き込みの原因となったスレッド バックトレースが記録されます。Apple が指定したトリガー条件は、アプリが 1 日あたり 1 GB のディスク書き込みしきい値を超えることです。
(12:19)クラッシュ診断 由MXCrashDiagnostic急行。アプリがクラッシュするたびに、MetricKit は例外情報、終了理由、不正アクセス クラッシュ時の仮想メモリ領域情報、およびバックトレースを提供します。
キーポイント:
- ハング診断は、メインスレッドが長時間応答していないことを示しています。
- CPU 例外診断は、CPU 使用率が高い期間中のスレッド呼び出しスタックを示します。
- ディスク書き込み例外診断は、毎日の書き込みしきい値を超えた書き込みのソースを示しています。
- クラッシュ診断には、例外情報、終了理由、部分メモリ領域情報、コールスタックが含まれます。
重要ポイント
-
やるべきこと: アプリ用の MetricKit レポート レイヤーを作成します。 実行する価値がある理由: メトリクスと診断の両方に合格
MXMetricManagerSubscriber配信の場合、アプリ側のアクセスポイントが少ないです。 開始方法: 起動フェーズでサブスクライバーを作成し、別途実装しますdidReceive(_ payload: [MXMetricPayload])そしてdidReceive(_ payload: [MXDiagnosticPayload])、ペイロードをバックエンドで保存できる JSON に変換します。 -
やるべきこと: リリース後のパフォーマンス回帰ダッシュボードを作成します。 実行する価値がある理由: CPU 命令、スクロール ヒット、アプリケーションの終了はすべて、毎日集計されるオンライン インジケーターであり、古いバージョンと比較して新しいバージョンの変化を観察するのに適しています。 開始方法: ビルド バージョンに従ってメトリック ペイロードを保存し、まず CPU 命令、スクロール ヒッチ率、フォアグラウンド/バックグラウンド終了理由の 3 つの傾向グループを描画します。
-
対処方法: 診断をトリアージ キューに切り替えます。 実行する価値がある理由: ハング、CPU 例外、ディスク書き込み例外、クラッシュにはすべて、オフラインで処理できるバックトレースがあり、単純なパーセンテージ インジケーターよりも根本原因に近いです。 開始方法: バックエンドはビルド バージョンと診断タイプごとにグループ化され、呼び出しスタック ツリーはシンボル化されて集約され、発生頻度の高いスタックまたは新しいバージョンに影響を与えるスタックが優先されます。
-
何をすべきか: オンライン スクロール ヒッチ インジケーターを XCTest パフォーマンス テストに接続します。 実行する価値がある理由: MetricKit は実際のユーザーのスクロール中のヒッチ率を提供し、XCTest は CI でアニメーションの回帰を事前に測定できます。 開始方法: このサイトが提供する MetricKit データを使用してオンラインの傾向を監視し、10077 をコアとして参照します
UIScrollViewシナリオは、繰り返し実行できるパフォーマンス テストを補完します。
関連セッション
- Xcode Organizer を使用してパフォーマンスの問題を診断する — Xcode Organizer から集約されたパフォーマンス データ、バージョン回帰、ディスク書き込み診断、スクロール スタッター メトリクスを表示します。
- XCTest でアニメーション ヒットを排除する — XCTest を使用してスクロールとアニメーションの遅延を測定し、オンライン ユーザー デバイスに到達する前にパフォーマンスの低下を検出します。
- 電力およびパフォーマンス API を使用して傾向を特定する — App Store Connect API を通じて、電力、パフォーマンス、診断の傾向をチーム独自のダッシュボードとワークフローに統合します。
コメント
GitHub Issues · utterances