MetricKit をFirebaseやXcode Organizerのmetricsと比較してみた話

October 20, 2022

タクシーアプリ「GO」のiOSアプリを開発しているTanです。

今回はMetricKit 2.0を触ってみたことを紹介したいです。

はじめに

弊社は、2021年度下期より、エンジニアのスキルアップを促進するための取り組みとして Engineer Challenge Week 施策が導入されました。詳しくは、「取締役エンジニアとして考える新しい個人と組織の成長の形 - Engineer Challenge Week」とiOSチームメンバーの久利の記事「iOS アプリに Snapshot Test を導入検討してみた話」もiOSチームの取り組みについて紹介していたので、是非読んでみてください。

自分は入社して間も無いこともあり、チームメンバーが提案してくれた「MetricKitでパフォーマンス測定」を選びました。

背景

アプリのパフォーマンスへのモニタリングは大規模のアプリにとっては不可欠です。弊社のタクシーアプリ「GO」も1000万ダウンロードを超えたので、今後アプリのパフォーマンスをより正確的に把握したいため、FirebaseのPerformanceやXcode Organizerのmetricsを比較してみたいと思います。

MetricKitとは

WWDC2019にて発表されたデバイス上でバッテリー持ちと性能に関するメトリクスを収集するフレームワークです。

WWDC2020にてMetricKit2.0が発表されました。MetricKit2.0にはCPU instrctions・Scroll Hitched・App exit reasonsと不具合の原因を支援するMXDiagnosticが追加されました。

実装

AppDelegate.swiftにMetricKitをimport

import UIKit
import MetricKit

didFinishLaunchingメソッドでMXMetricManagerにSubscriberを追加

func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
    let metricManager = MXMetricManager.shared
    metricManager.add(self)
    return true
}

AppDelegateはMXMetricManagerSubscriberを拡張し、下記の二つメソッドを追加することによって、自社サーバかデータ収集サービスにデータを送ります。

extension AppDelegate: MXMetricManagerSubscriber {
  func didReceive(_ payloads: [MXMetricPayload]) {
    guard let firstPayload = payloads.first else { return }
    print(firstPayload.dictionaryRepresentation())
  }

  func didReceive(_ payloads: [MXDiagnosticPayload]) {
    guard let firstPayload = payloads.first else { return }
    print(firstPayload.dictionaryRepresentation())
  }
}

デバッグは実機しかできないので、繋がったらDebug > Simulate MetricKit Payloadsを選択すればconsole上にMXMetricPayloadとMXDiagnosticPayloadのデータがprintされます。

MXMetricPayloadとMXDiagnosticPayload

MXMetricPayload と MXDiagnosticPayload から得られる情報は以下です。

MXMetricPayload

パフォーマンス
- CPU情報
- ディスプレイ情報
- GPU情報
- 位置情報
- ネットワーク情報
応答性
- アプリの起動と再開
- アニメーションの応答性
- ユーザインタラクションに対する応答性
ストレージ
- ディスク情報

MXDiagnosticPayload(iOS14以降)

クラッシュ
- クラッシュレポート
- CPU例外レポート
- アプリビジーレポート
- ディスク書き込み例外レポート

Xcode Organizerとの比較

Xcode OrganizerにはMetricKitを導入してなくてもいくつかのデータが無料で提供しています。

バッテリ、ディスク書き込みなど様々なデータがバージョンごとに収集されます。

こちらの画像は弊社のアプリ「GO」の直近各バージョンのLaunch Timeです。左上のTop Launch Time 「90th percentile」は、計測された全データを小さい順に並べて 90 番目の値を示しています。以下の例ですと、バージョン 6.2.0 を利用しているユーザの 90% は 1460ms 以下でアプリを起動することができています。

そして、MXAppExitMetricでアプリ終了・強制終了の理由と発生回数が見れます。WWDC2020にてWhy is my app getting killed?に紹介された通り、アプリが強制終了されたのが様々な原因があり、MXAppExitMetricのデータを分析することによって、原因を掴みやすくなるではないかなと思います。

また、MXDiagnosticPayloadで診断データとCallStackTreeが取得でき、クラッシュしたところをより判断しやすくなります。

大きな違いはXcode Organizerが全体的に俯瞰ができて、MetricKitで取得できるデータは各デバイスまで深掘りすることができると思います。なので、定期的に全体のデータを俯瞰し、もしどこかが急におかしくなったらまたMetricKitで見ればいいでしょう。

Firebaseとの比較

FirebaseにはパフォーマンスをモニタリングするサービスPerformanceとクラッシュをレポートにするサービスCrashlyticsがあります。

Performanceには

ネットワークリクエスト
カスタムトレース
画面のレンダリング

があり、それぞれは

ネットワークレイテンシ
計測の始点と計測の終点の間のパフォーマンス
各画面毎のレンダリング遅延やフリーズ

を表示することができます。

一方、上記に記載した通り、MetricKitの強みはデバイスごとにMXMetricPayloadで収集できるCPU情報、GPU情報、アプリ終了・強制終了の理由などのデータが収集できるので、例えば、画面がフリーズした情報が得られた場合、MXMetricPayloadのCPU情報、GPU情報、app exits reasonsなどデータを見て総合的に分析できるのではないかなと思いました。

CrashlyticsにもMXDiagnosticPayloadにあるクラッシュレポート・CPU例外レポート・アプリビジーレポート・ディスク書き込み例外レポートを導入する要求がFirebase SDKのissueに提出され、2021年に導入するかどうかを検討するアンケートが公開されましたが、まだ実装はされていません。

以上、パフォーマンスをモニタリングする際に、各サービスの特徴を活かせばいいかなと思いました。