MetricKitの新機能

MetricKitの新機能

MetricKitを導入して、電力とパフォーマンス低下を素早く検知し、Appに起きた問題のトラブルシュートをしましょう。CPUインストラクション、アニメーションヒッチ、終了理由といったAppで追跡することが可能な最新メトリクスを説明します。またハング、クラッシュ、ディスク書き込みのトラブルシュートの助けとなる、MetricKitでできる診断についてもお伝えします。

リソース
- - HDビデオ
  - SDビデオ
関連ビデオ

WWDC21
WWDC20
ダウンロード

こんにちは WWDCへようこそ
“MetricKitの最新情報” 私はフィル･アザールです電力と性能ツールチームのソフトウエアエンジニアです本日はiOS 14のMetricKitの新機能を皆さんにお伝えしますアプリケーションはユーザーのソフトウエア体験の重要な一部分ですそしてアプリケーションは今まで以上に使われるようになっていますアプリケーションがバッテリー持ちも良く性能も良く作られていればユーザーは喜びますそして全体としてのソフトウエア体験の向上にも貢献します私たちのチームはバッテリーの持ちと性能面を改善するために役立つ強力なツールをご提供することを使命としています昨年 MetricKitをはじめとしてそれを支援する数多くの― ツールを導入しましたデバイス上でバッテリー持ちと性能に関するメトリックを収集するフレームワークです本日はMetricKitの次のバージョンの新機能をお伝えできることにワクワクしています最初にMetricKitの使い方について簡単におさらいしますそれから新しい強力なメトリックと診断機能についての議論に移りますさらにそれらの新しいインターフェイスの詳細を見ていきますそれから簡単にまとめを行います
本日の最初の話題は MetricKitの使い方の再確認ですフレームワークとしてのMetricKitはまったくゼロから設計されアプリケーションを実行するユーザーやデバイスに直接アクセスできないことが多い開発サイクル段階における― データを提供するために開発されましたそのような段階とは例えば TestFlightのような外部ベータテストや App Storeへの出荷後がありますつまりデベロッパとして MetricKitをそのような段階で使用することでアプリケーションの性能データを多くの実利用者から実際に収集できるようになりますそれは性能上の不具合に関する傾向やパターンの発見を支援します MetricKitを使用するには以下の３つの簡単なステップに従ってください最初はMetricKitフレームワークをプログラムにリンクしてインポートすることです
２番目は共有インスタンスを作成することですいわゆるMetricManagerでフレームワークにおける問い合わせ先として機能するクラスです
最後にサブスクライバーデリゲートプロトコルを実装することでフレームワークからメトリックを受け取ることができますこれは実際のプログラムで前述のステップを実装する例ですこの例ではMySubscriberというカスタムクラスを実装してプログラムをクリーンな状態に保っています MetricKitフレームワークをリンクした後この新しいクラスをサブスクライバープロトコルに適合させて共有Metric Managerのインスタンスを作成しますそして新しいカスタムクラスからマネージャーへの参照を追加します
初期化解除の際にはカスタムクラスへの参照を削除することを推奨します
それが終わったら最後のステップはdidReceive プロトコルメソッドの実装ですこれでメトリックペイロードを受け取れるようになります
システムがどのようにこのペイロードを収集して MetricKitを通じてアプリケーションに届けるか確認しましょう１日の間にアプリケーションが利用されると OSは受動的にアプリケーションの性能データを収集しますデータは匿名化されプライバシーを保護するよう設計されていますそして１日の終わりにそのデータは 24時間分のペイロードとしてまとめられますこれがMetricKitペイロードですメトリックペイロードはMetricKit インターフェイスで強力に分類されていますペイロードにどのようなデータが含まれているか確認してみましょう MetricKitペイロードには様々な種類のデータが含まれています起動回数 CPU時間メモリなどですこれはあるMetricKitペイロードを人間が読めるように変換したものですこれを見るとデータの集計方法が大きく分けて３種類あることが容易にわかります累計平均および分類データです処理後のこのデータはアプリケーションのビルド間での不具合を特定するのに非常に有効です難しい問題に取り組む上でローカルのコンテクストと組み合わせて使うこともできますただし一部の分野では不具合の性質を完全に理解するのに現在のメトリックが不十分である可能性があります
よくある例を見てみましょう起動性能データですここでコールドランチの回数を見ることができますつまりメモリ内に何もリソースがないゼロの状態から起動された回数です再開の数よりずっと多くなっています典型的な性能のよいアプリケーションでは再開の数の方が起動の数よりずっと多くなることが期待できますここには何か不具合がありそうですもう一つのよくある例として累計CPU時間があります累計CPU時間が累計前面表示時間よりもずっと短くなっていることにご注意くださいこれは良いことのように見えますがこの稼働レベルが意味するのは性能上の不具合なのか向上なのかはっきりしません CPU時間はクロック周波数にも影響されるからですデベロッパとしての本能としてはこれをもっと正確に数値化したいでしょう現状ではそれは単純な問題ではありませんここに明らかに発展の余地がありますこの問題をより深く探るにはより詳細な情報が必要です今年 MetricKit 2.0でいくつかの新しいメトリックのご提供を開始しますこういったよくある問題例をより深く掘り下げることを支援する意図です私たちのチームではメトリックのサブセットを拡張するために努力しましたアプリケーションの負荷性能および安定性についてより明快なものとするためですその中にはCPU命令数スクロールヒッチアプリケーションからの退出回数が含まれます最初にCPU命令数について確認しましょう MetricKitでCPU命令数が MXCPUMetricクラスに新しく追加されましたこのメトリックはアプリケーションが発した― １日の累計命令数をまとめたものです CPU命令数はCPUを使ってアプリケーションが行った作業の絶対的なメトリックですそれはハードウェアや周波数のどちらにも依存しませんこれでアプリケーションの合計負荷をより正確に数量化することができます次にスクロールヒッチについてですスクロールヒッチは今年提供を開始する新しいメトリックですアプリケーションのグラフィック性能に関する洞察を支援しますスクロールヒッチとはスクロール中にレンダリングされたフレームが期待された時間内に画面上に出てこない場合にカウントされますこれは通常フレーム落ちの原因となり動作のスムーズさが阻害されているのがユーザーにも知覚できることになります MetricKitでは UIScrollViewsにおいてアプリケーションがスクロール中にヒッチを起こして消費した時間をご提供します
ヒッチの技術的詳細についてはスクロールヒッチとそれをXCTest メトリックで測定する方法を対象とした― 別のセッションをご覧になることをお勧めします最後ですが重要なこととしてアプリケーション終了の理由を追加しました今年アプリケーションの終了と強制終了に関するメトリックを提供します前面とバックグランド両方についてアプリケーションが終了した際の理由と回数について１日のまとめを受け取ることができますこれはアプリケーションの起動とバックグラウンド実行フレームワークに伴う― よくある問題を追跡するのに有用であると考えられますこれらのメトリックを利用して最良の実践を実装する方法に関するより詳細については今年のアプリケーション終了に関するセッション “Why did my app get killed?”をご覧になることをお勧めします以上が今年の新しいメトリックですこれらのメトリックを利用すると MetricKitデータを使って不具合を探すにあたってより高い確実性が得られるものと考えていますそれではメトリックペイロードに戻って何が起きているかまだ判断できない― ある分野に焦点を当てて詳細を見てみましょうアプリケーションハングヒストグラムに注意すべきデータエントリが見られますこれはユーザーの体験を深刻に妨害している可能性があります現在これは明らかに不具合ですしかしメトリックだけでは根本原因を特定できません何が起きたか判断するためにはハングした時点での後方追跡など追加の診断データが必要ですそこで今年のMetricKitのもう一つの重要な新機能ですそれは不具合の別のクラスについて原因の発見を支援します MetricKit診断です MetricKit 2.0は新しいインターフェイスを提供します目的とする診断情報にアクセスできるようにするものです診断情報は様々なタイプの不具合について対処可能ですハングクラッシュディスク書き込み例外処理およびCPU例外処理です
MetricKit 2.0で診断を受け取り始めるためには新しいMetricManagerSubscriber プロトコルメソッドを実装するだけで済みますそれだけですこの新しいプロトコルは昨年の didReceiveメトリックペイロードデリゲートメソッドとほとんど同じ外見ですそして私たちの予測ではほとんどの場合 MetricKitのために構築済みのパイプラインがそのまま使えますそしてこのプロトコルは見た目が同じだけではありません機能としても同じです意味的に言えば MetricKit診断機能は MetricKitメトリックとほとんど一緒です少し前からのタイムラインを見直してみましょうアプリケーションが１日使用されると MetricKitシステムはメトリックに加えて使用中に発生した不具合について診断情報を受動的に収集しますシステムはそれらをまとめて１日の並行診断ペイロードとして日常のメトリックペイロードに加えて使用できるようにしますハングのような不具合がメトリックにあった場合関連する診断ペイロードが存在すれば参照できるようになりました診断ペイロードはメトリックペイロードと同時に受け取れますこの診断ペイロードは付随するメトリックペイロードと効果的に１対１で対応できるようになっていますそれでは議論の方向を変えてこの新しいインターフェイスを詳しく見てみましょうそしてその能力に慣れましょう新しい診断インターフェイスは古いメトリックインターフェイスをミラーリングしています少数の新しい基本クラスに関して MXDiagnosticはすべての診断の継承元となる基本クラスです MXDiagnosticPayloadは１日の終わりにすべての診断を届ける搬送用クラスです MXCallStackTreeは新しいデータクラスで不具合が発生した時後方追跡をデバイス外で使えるよう― カプセル化します MXDiagnosticsはMXDiagnosticPayloadsに包含されていて不具合が発生した際のアプリケーションのメタデータを含みます例えば具体的なビルドバージョンや診断特有のデータです
診断特有のデータは今年提供を始めるもので各診断サブクラスのための特有のデータサブセットですそれらすべてに一貫しているのが MXCallStackTreeです
MXCallStackTreeは新しく提供を始めるデータクラスで不具合が発生した際の後方追跡をカプセル化したものですこれらの後方追跡はシンボル化されておらずデバイス外で処理するために設計されていますそして不具合の本質を診断して取り出せるように豊富な情報のセットが提供されるようになります
これはこの呼出スタックツリーを人が読めるような JSONに変換するとどのように見えるかという例です個々のフレームをATOSのようなツールでシンボル化するために必要なすべての情報がありますそこにはUUID オフセットおよび名称さらにフレームアドレスなどのバイナリ情報も含まれます
これらの新しい呼出スタックツリーデータ構造は移植可能性が高く今年ご提供する他の性能ツールでも使用されていますより詳細については新しい電力および性能APIに関する― セッションをご覧になることをお勧めします前にご説明したように今年４つの新しい MXDiagnosticをお届けしますハング CPU例外処理ディスク書き込み例外処理およびクラッシュですこれらの新しい診断サブクラスのそれぞれに含まれる― 独自のデータについて見ていきましょうまずはハングですハングとはユーザーの入力に対してアプリケーションからの反応が長期間にわたってなくなる不具合ですアプリケーションの主スレッドがブロックされるかビジー状態になるのが原因ですハングの診断用に MetricKitは今後アプリケーションの主スレッドが無反応になった時間と主スレッドの後方追跡を提供します次はCPU例外処理ですまたはXcode Organizerでエネルギーログと呼ばれるものですこれらの診断には使用されたCPU時間高いCPU使用率がサンプリングされた合計時間そしてCPUを使用したスレッドの後方追跡が含まれます CPU例外処理診断は Metricペイロードと一緒に使用することで再現が簡単ではないかもしれない不具合を特定する上で非常に有用です次にディスク書き込みですディスク書き込み例外処理診断は CPU例外処理診断とおおよそ同様ですそれぞれの診断には例外処理の原因となった書き込みの総合計数と過度の書き込みの原因となっている― スレッドの後方追跡が含まれますこれらの診断は１日あたり１ギガバイトという― しきい値をアプリケーションが超えた場合に生成されます最後ですが重要なものとしてクラッシュ診断があります今年 MetricKitがアプリケーションのクラッシュに関する診断を提供できることはすばらしいことですアプリケーションがクラッシュするたびにアクセス不良によるクラッシュの場合には例外処理情報強制終了理由バーチャルメモリ領域情報を含む MXCrashDiagnosticと後方追跡がMetricKit診断インターフェイスを通じて提供されますこれがMetricKit診断の最後の項目ですリアルな顧客の利用例における不具合の根本原因を特定するための強力な新しいツールです本日のお話をまとめましょう MetricKit 2.0には最適化の作業を次のレベルに高めることができる新機能が詰め込まれています顧客とベータテスターに発生する不具合をより深く理解するために新しいメトリックをご提供しますまたこれらの状況で発生する再現が難しい不具合を捉えることができるように対象を決めた診断情報をご提供します最後にこれらすべては余計な作業をほとんどなしで利用可能ですこれらの新機能は実装が簡単なインターフェイスや既存のインターフェイスを通じて提供されます
今年は大量のすばらしい新機能がありますそして役に立つ古い機能もぜひご確認いただくことをお勧めしますご覧いただきありがとうございます引き続きWWDC 2020をお楽しみください

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.
        }
    }
    
}

8:14 - Adopting MetricKit Diagnostics

func didReceive(_ payload: [MXDiagnosticPayload]) {
    for diagnosticPayload in payload {
        // Consume diagnosticPayload.
    }
}

特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。

クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。

リソース

関連ビデオ

WWDC21

WWDC20