WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Identify trends with the Power and Performance API

Identify trends with the Power and Performance API

Developer ToolsApp StorePerformance
元の動画を見る

ハイライト

App Store Connect は、2020 年に Xcode Organizer の総電力、パフォーマンス、I/O メトリクス、診断データを Power and Performance API としてオープンします。チームはトレンド、回帰、コールスタックをカスタム ダッシュボードやアラート プロセスに接続できます。

主要内容

Xcode 11 の Organizer は、オンライン アプリの総電力、パフォーマンス、および I/O メトリクスをすでに表示できます。問題は、このデータのほとんどが Xcode に保存されていたことです。チームが同じデータのバッチを独自の監視パイプライン、ダッシュボード、またはバグ システムに配置したい場合、手作業によるレビューのみに頼って、結論を他の場所に移すことができます。 (00:48)

このセッションで得られる答えは、App Store Connect API の Power and Performance API です。 Xcode Organizer の背後にあるメトリクス、診断、および新しいスマートな洞察を、プログラムでアクセス可能なデータに変換します。データはユーザーが共有に同意したデバイスから取得され、Apple はそれをサーバー側で集約し、API を通じて開発チームが利用できるようにします。 (01:21)

API の価値はリリース後に最も顕著になります。新しいバージョンがオンラインになると、チームは最新バージョンの productData そして insights、さまざまなデバイスとパーセンタイルでのバッテリーの消耗、起動、ディスク書き込み、ハング率、その他の指標の変化を観察します。回帰が発生した場合は、診断シグネチャを使用して主な問題グループを見つけ、診断ログを取得してコール スタックを確認します。 (04:26)

デモの MealPlanner にはこのプロセスがあります。写真を保存する機能が追加され、チームは API を通じて、最新バージョンでは全 iPhone ユーザーの 50 パーセンタイルでディスク書き込み回帰が発生していることを発見しました。次に、上位の診断署名を要求し、対応するログをダウンロードし、最後に新しいフォト関数によって発生したディスク書き込みをコール スタックから追跡します。 (10:24)

詳細

傾向、回帰、根本原因をカバーする 1 つの API リンク

(02:55) Apple は、このセッションで 4 種類の REST API リソースを紹介しました。App ID を使用して、最新バージョンの集約された指標と洞察を取得します。ビルド ID を使用して、特定のバージョンのインジケーターをダウンロードします。ビルド ID を使用して最上位の診断署名を取得します。シグネチャ ID を使用して診断ログをダウンロードします。公式の「コード」タブには、3 つのコア リクエストが表示されます。

GET /v1/apps/{id}/perfPowerMetrics
GET /v1/builds/{id}/diagnosticSignatures
GET /v1/diagnosticSignatures/{id}/logs

キーポイント:

  • perfPowerMetrics はアプリのリソース用であり、最新バージョンの集約されたメトリクスとスマートな分析情報を取得するために使用されます。
  • diagnosticSignatures はビルド リソース用であり、類似した質問を並べ替え可能な質問グループに集約するために使用されます。
  • diagnosticSignatures/{id}/logs 特定のシグネチャを対象とし、根本原因分析に使用できる匿名の診断ログをダウンロードするために使用されます。
  • トランスクリプトには、ビルド ID によって特定のバージョンのメトリクスをダウンロードするためのリソースについても言及されていますが、[コード] タブには特定の URL が示されておらず、記事には表示されていないエンドポイントも追加されていません。

perfPowerMetrics 返品 productData そして insights

(04:48) アプリケーションレベルのメトリクスは、App ID を使用してリクエストされます。戻り値は構造化された JSON であり、主に次の 2 つの部分に分かれています。 productData そして insights。

GET /v1/apps/{id}/perfPowerMetrics

キーポイント:

  • {id} は、App Store Connect API のアプリケーション ID です。
  • productData 集計されたメトリクスを保存します。各メトリックには、単位などの独自のメタデータがあります。
  • メトリックとデバイスの各組み合わせにより、50 パーセンタイルと 90 パーセンタイルが得られます。
  • メトリクスの概要には、最大 8 つの最近のアプリ バージョンが含まれます。
  • insights 以前のメトリックを使用してホット スポットを自動的にマークします。セッションで示された例では、起動時間は 90 パーセンタイルの iPhone ユーザーのみに返されます。

このステップはトレンド ダッシュボードに適しています。バックグラウンドタスクのリクエスト perfPowerMetrics Xcode Organizer で見られる傾向をチーム独自のツールに統合できるように、ストレージはメトリック、デバイス、パーセンタイル、バージョンごとに分離されています。

API にアクセスするには、App Store Connect トークンとメトリクスの Accept ヘッダーが必要です

(11:19) このデモでは、まず App Store Connect API キーを使用してアクセス トークンを生成し、次にそのトークンを使用してリクエストを行います。 perfPowerMetrics。公式コード スニペットには、次の 2 つの主要なヘッダーが示されています。 curl。

curl -X GET -H "Authorization: Bearer ${JWT}" -H "Accept: application/vnd.apple.xcode-metrics+json,application/json" https://api.appstoreconnect.apple.com/v1/apps/${id}/perfPowerMetrics

キーポイント:

  • Authorization: Bearer ${JWT} App Store Connect API キーによって生成されたトークンを使用します。
  • Accept 両方を宣言します application/vnd.apple.xcode-metrics+json そしてプレーンな JSON。
  • ${id} は、MealPlanner などの対象アプリのアプリ ID です。
  • 応答は両方を返します productData そして insights、デモンストレーションは回帰の概要を直接チェックします。 insights。

診断シグネチャ 類似した問題をグループ化する

(08:19) 回帰を発見した後の次のステップは、ビルド ディメンションから診断シグネチャを取得することです。セッションでは、2020 年には Xcode と API を通じてディスク書き込み診断署名にアクセスできることが明示されています。

GET /v1/builds/{id}/diagnosticSignatures

キーポイント:

  • {id} は、App Store Connect API によって提供されるビルド ID です。
  • 戻ってきた data リストには複数の署名が含まれており、各署名には一意の ID と属性があります。
  • 署名文字列は Xcode UI の呼び出しフレームに対応し、この一連の呼び出しスタックを表すために使用されます。
  • weight は正規化された署名の重みであり、署名の相対的な重要性を示します。
  • 応答には、署名 ID がすでに含まれている関連 URL も含まれており、引き続きログを要求できます。

デモでは、MealPlanner はまず最新のアプリ バージョンのビルド ID を使用して上位の署名を要求し、次に上位のディスク書き込み署名を取得してさらなる分析を行います。

診断ログはデバイスのメタデータと呼び出しスタック ツリーを提供します

(09:42) シグネチャ ID を取得した後、対応する診断ログをリクエストできます。これには、単一デバイスからの匿名の診断詳細が含まれます。

GET /v1/diagnosticSignatures/{id}/logs

キーポイント:

  • {id} は前の署名 ID です diagnosticSignatures 応答。
  • diagnosticMetadata 含まれています deviceType、 osVersion、 buildVersion およびその他の情報。
  • このようなディスク書き込みイベントがもたらすもの callStacks。
  • 各呼び出しスタック フレームには次の内容が含まれます rawFrame、解析されたフレーム情報と subFrames。
  • 横断することによって subFrames ルート フレームから下方向に進むと、完全なコール スタック ツリーを復元できます。
  • トランスクリプトでは、このコール スタック JSON 構造が MetricKit と共有されており、解析ロジックの再利用に適していると明確に述べられています。

デモの最後のステップは、呼び出しスタックを整形して出力することです。 Yeonoh は下のフレームから上を見上げ、重いディスク書き込み I/O を引き起こす新しい写真保存関数を見つけて、最適化のためにソース コードの場所に戻ります。 (13:22)

重要ポイント

  • やるべきこと: リリース後のパフォーマンス傾向ダッシュボードを作成します。 実行する価値がある理由: perfPowerMetrics 集約されたメトリクスの最新バージョンが提供され、データ粒度にはメトリクス、デバイス、50 パーセンタイル、90 パーセンタイルが含まれます。 開始方法: App ID を使用してリクエストします GET /v1/apps/{id}/perfPowerMetrics 定期的に書く productData バージョンごとにタイミング ライブラリに取り込み、まず起動、バッテリ消耗、ディスク書き込み、ハング率という 4 つの傾向を描画します。

  • やるべきこと: スマートな分析情報を回帰アラートに接続します。 実行する価値がある理由: Insights JSON には、分析されたバージョン、回帰の概要、影響を受けるデバイスおよびパーセンタイルが直接含まれており、読み取り可能なアラートに変換するのに適しています。 開始方法: 読む insights 新しいバージョンごとに十分なオンライン データが得られたら、概要文字列、影響を受けるデバイス、パーセンタイルを Slack または問題トラッカーに書き込みます。

  • 内容: 診断トリアージ作業指示を自動的に生成します。 実行する価値がある理由: diagnosticSignatures 同様の問題を集約して、 weight, そのため、チームは最も大きな影響を与える署名に最初に対処できます。 起動方法: 異常なビルドリクエストの場合 GET /v1/builds/{id}/diagnosticSignatures、 並べ替え weight、署名文字列と関連ログの URL を作業指示書に添付します。

  • 内容: コール スタック パーサーのセットを再利用して、API ログと MetricKit 診断を処理します。 実行する価値がある理由: セッションでは、診断ログのコール スタック JSON 構造が MetricKit と共有されることが明確に述べられています。同じパーサーで、サーバー側の集約ログとデバイス側の診断をカバーできます。 始め方: まずは callStacks のエントリー GET /v1/diagnosticSignatures/{id}/logs、再帰的に走査します subFrames 読み取り可能なフレーム ツリーとデバイス メタデータを出力します。

関連セッション

コメント

GitHub Issues · utterances