Performance for Conversion! 分散トレーシングでボトルネックを 特定せよ

In Android apps, sluggish startups and janky scrolling directly lead to user churn and lower conversion rates. However, as projects grow in complexity, it becomes difficult with common tools—such as Firebase Performance Monitoring—to pinpoint why performance metrics are dropping and where the actual bottlenecks lie.

For example, if the time to first frame is slow, you might assume delays in data-layer execution or image decoding are to blame, but in reality the root cause can reside in asynchronous operations outside the app—such as TCP connection establishment or DNS resolution through a CDN. Moreover, I/O contention can also trigger performance issues, so investigating bottlenecks that cannot be reproduced locally is extremely challenging.

In this session, we’ll cover the fundamentals of distributed tracing—widely used on the backend—and explain how to leverage it in Android apps. We’ll introduce techniques and monitoring strategies that clarify causal relationships between in-app processes and system-level operations, helping you identify performance issues more easily while maintaining high quality in the app, which is beloved by users worldwide in diverse environments.

Furthermore, we’ll discuss the design and operation of tracing with OpenTelemetry, highlight differences from Firebase Performance and Systrace, present examples of a mobile-customized SDK implementation, and share real-world case studies of performance improvements. By the end, you’ll understand the technologies and mechanisms needed to uncover what “slow loading” really means.

Proposed Session Outline

- Why traditional methods struggle to pinpoint performance issues
- What is distributed tracing?
- Core concepts: trace, span, and context propagation
- OpenTelemetry and its ecosystem
- Comparison with Firebase Performance and Systrace
- Designing and introducing distributed tracing for Android apps
- Granularity of measurement units
- Designing and implementing a lightweight mobile SDK
- Data collection and sampling
- Visualization and operations
- Observability with tools like Grafana
- Best practices for alert design
- Problem-solving flow and results
- Case study: observability→performance metric degradation→investigation→improvement→re-observability
- Reflections and future outlook
- Changes in the development process before and after implementation
- Future potential of distributed tracing (including AI-driven monitoring, etc.)

Transcript

1. DroidKaigi 2025 Performance for Conversion! 分散トレーシングでボトルネックを 特定せよ Andrey Chernov
2. Andrey Chernov andousan Android Engineer @ pixiv Android歴9年 KMPの信者 o11y ❤ 2 inetand inetand
3. このセッションのゴール Performance for CVR！パフォーマンス管理の重要性 既存ツール (Firebase, Systrace) のスケールにおける限界 分散トレーシングの概念と有効性の説明 モバイルアプリでの分散トレーシング（OTel）の導入方法 Otelの導入と運用の具体的なイメージ 3
4. パフォーマンス管理が重要な理由 4
5. パフォーマンス管理が重要な理由 • アプリ起動時間が遅いと 離脱率が⤴ • アプリの体験がスムーズ でないとCVRが⤵ 5 Madhavan, N. , 2024, Improving Mobile App Performance: A Comprehensive Approach
6. パフォーマンス管理が重要な理由 6
7. パフォーマンス管理が重要な理由 • 遅いと離脱率が⤴ • 遅いとは何か？ アプリの起動時間が以下の閾値に達すると、長すぎると判断される • コールド スタートに 5 秒以上かかっている。 • ウォーム スタートに 2 秒以上かかっている。 • ホットスタートに 1.5 秒以上かかっている。 指標の閾値がストア毎で異なる 7
8. パフォーマンス管理が重要な理由 • ユーザーからのFBの時点で気づく のは遅い • 様々な要因があるので継続的に パフォーマンス変動 の観測が必要 8 Environment
9. パフォーマンス指標 9 プロダクトのドメインに依存しない指標の例
10. 画面初期表示までの時間 (TTID) 測定するイベント • プロセスの開始 • 画面の初期化 • 初回フレームの描画（初回状態の描画） 10
11. 画面完全表示までの時間 (TTFD) 11 測定するイベント • プロセスの開始 • 画面の初期化 • データの読み込み • レイアウト・描画
12. 画像読み込み開始から描画完了までの時間 アプリ側の考慮 • デコーディング • Bitmapのキャッシュヒット • Disk/Memory • 画像フォーマット • BitmapTransformation 12
13. リクエストにかかる時間 ネットワークの考慮 • CDN経由でのDNS解決 • 環境の問題 • 端末の問題 13
14. アプリ起動時間（AppStartup） • Cold • Warm • Hot 14
15. アプリ起動時間 15
16. このセッションのゴール Performance for CVR！パフォーマンス管理の重要性 既存ツール (Firebase, Systrace) のスケールにおける限界 分散トレーシングの概念と有効性の説明 モバイルアプリでの分散トレーシング（OTel）の導入方法 Otelの導入と運用の具体的なイメージ 16
17. Firebase Performance Custom traces 17
18. Firebase custom traces • カスタムなパフォーマンス指標の 測定と管理が可能 • ユーザーの環境ではコンテンツの 表示が重い場合の調査に有効 18
19. Firebase custom traces • カスタムトレースに関連するユー ザーセッション詳細画面 • 一部のトレースに限定して集計さ れる 19
20. 実際の測定 アプリ起動時間 　 ネットワークリクエストの詳細トレース 20
21. アプリ起動時間（Cold） • デフォルト指標！ 21
22. アプリ起動時間 22
23. アプリ起動時間 • あれ？コールドだけ？ • バックグラウンド起動判定フラグは？ • 結論：Cold起動以外の集計データが必要な場合は独自で 測定しなければいけない 23
24. 実際の測定 アプリ起動時間 　 ネットワークリクエストの詳細トレース 24
25. リクエスト時間（詳細トレース） • ケース ◦ 海外ユーザーから「コンテンツの読み込みが遅い」 というFBを受ける ◦ 手元では特に問題はないので、ユーザーの環境で測定する 25
26. ネットワークリクエストの測定 26 fun provideOkHttpClient(): OkHttpClient { return OkHttpClient.Builder() .eventListenerFactory { TimingEventListener() } .build() } Kotlin override fun dnsStart(call: Call, domainName: String) { super.dnsStart(call, domainName) dnsTrace = FirebasePerformance.startTrace("dns_lookup") } override fun dnsEnd(call: Call, domainName: String, inetAddressList: List<InetAddress>) { super.dnsEnd(call, domainName, inetAddressList) dnsTrace?.stop() } Kotlin
27. リクエスト時間（詳細トレース） • 各フェーズの測定ができた！ 27
28. トレースが分散している問題 28
29. Firebase Custom Tracesでいける？ 29
30. Firebase Performanceの限界 30
31. Firebase Performanceの制限 ① • トレースの関係性がない。子のトレースも設定できない • カスタムトレースのAPIが限定的 ◦ Trace の開始時間として、任意の startTime 指定不可 31 FirebasePerformance.startTrace("").
32. Firebase Performanceの制限 ② • BigQuery への集計データのエクスポートが24時間置きに 行われている • ディレイがあるのでSLO設定ができない 32
33. サンプリング 33
34. サンプリングの種類 34 Head-based Sampling 一定の確率でTrace参照せずに判断する Tail-based Sampling Traceを参照した上で判断する ランダムにトレースを選択 遅いトレースやエラーを含んだトレースを選択
35. Head-based サンプリング • 一定の確率・割合 で、スパンの欠損なく、 トレースを送信対象に含める • どれを残せばいいかの選定は行わない • エラーや比較的に遅いトレースも サンプリングされてしまう 35 Head-based Sampling 一定の確率でTrace参照せずに判断する ランダムにトレースを選択
36. Tail-based サンプリング • トレースの内容を参照 した上で サンプリングする方法 • エラーを含むトレース • 全体的なレイテンシーに基づいて サンプリングする • 特定の属性 があるトレースを含む など 36 Tail-based Sampling Traceを参照した上で判断する 遅いトレースやエラーを含んだトレースを選択
37. Firebase Performanceの制限 ③ サンプリングの制御不可 • サンプリング方式は固定 （head-samplingのみ） • カスタムトレースのセッションのサ ンプリング 37
38. 従来の手法では問題箇所の特定が難しい • Firebase Performanceで「ライトに導入 → 大枠の把握」し、結局 手元でプロファイルを行ったり、最適化を試みる • トレースの文脈となる情報が見れない • トレースの因果関係もわからない • 情報が分散しているので、照らし合わせることが難しい 38
39. このセッションのゴール Performance for CVR！パフォーマンス管理の重要性 既存ツール (Firebase, Systrace) のスケールにおける限界 分散トレーシングの概念と有効性の説明 モバイルアプリでの分散トレーシング（OTel）の導入方法 Otelの運用の具体的なイメージ 39
40. 分散トレーシング 因果関係をつけてボトルネックを特定する 40
41. 分散トレーシングとは • 元々はマイクロサービスを可視化するための手段である （network中心） • 処理の流れを網羅的に記録する仕組み • 複数サービスやアプリ内の処理を 1 本のトレースとして可視化 • 遅延・エラーの原因を特定しやすい • 分散トレーシングではトレースがパフォーマンス調査のルートである 41
42. バックエンドの例 42 *https://opentelemetry.io/ja/docs/concepts/observability-primer/ より ※バックエンドのトレースをアプリのトレースと一環して集計可能
43. トレースが分散している問題 43
44. トレースが分散している問題 44
45. OpenTelemetry 分散トレーシングを実現するための仕様と計装 45
46. OpenTelementry（OTel）とは • CNCF*のOSS規格 1. メトリックス 2. ログ 3. トレース • 三本柱のシグナルを提供する標準化された 仕様とOSSの計装SDK 46 *CNCF（Cloud Native Computing Foundation）プロジェクト
47. OpenTelementry（OTel）とは • OTLP + SDK • ベンダー非依存 • ツール選定が柔軟 47 *https://opentelemetry.io/ja/docs/languages/#status-and-releases 言語API & SDK | OpenTelemetry
48. OpenTelementry（OTel）とは • コレクター • ベンダー非依存 • ツール選定が柔軟 48 *https://opentelemetry.io/ja/docs/collector/ コレクター | OpenTelemetry
49. OpenTelemetryの主な概念 シグナルという概念について 49
50. • 収集・処理・エクスポートされるテレメトリデータのカテゴリ • 主なシグナル • トレース（Traces） • メトリクス（Metrics） • ログ（Logs） • バゲッジ（Baggage） • イベント（Event） OpenTelemetryのシグナルとは 50
51. Trace & Span • トレース：アプリ内での処理の経 路を示す • トレースは個別処理単位の スパンでできている • span1.parent_idとして span2.idを設定すると親子 関係ができる 51
52. Metrics & Logs Metrics • 数値ベースの集計データ • 時系列で「状態の変化」を監視 • CPU使用率、エラーレート、レイテンシー分布 などを計測 • Counter, Gauge, Histogram など Logs • テキスト／構造化ログ 52
53. OpenTelemetry Context 伝搬 53
54. このセッションのゴール Performance for CVR！パフォーマンス管理の重要性 既存ツール (Firebase, Systrace) のスケールにおける限界 分散トレーシングの概念と有効性の説明 モバイルアプリでの分散トレーシング（ OTel）の導入方法 Otelの運用の具体的なイメージ 54
55. OpenTelemetry in Mobile モバイルアプリの環境には本当に適応可能なのか？ 55
56. OpenTelemetry SDK • otel-android SDK • otel-java SDK • Embrace Android SDK • Embrace Kotlin SDK • Datadog Tracing Android SDK • Elastic OTel Android SDK 56
57. 簡単なSDKを作ってみる 57 名付けて、Catracer SDK ※ Cat Racerじゃないよ
58. Catracer SDK とは • 軽量版のOpenTelemetry Android SDK（独自SDK） • Embrace Kotlin SDK を基盤実装として利用 • 特定のSDKに依存しない設計になっている。KMPも対応可能 • ゴール ◦ アプリレベルでSpanを管理する（永続化を含む） ◦ Dozeモードやバックグラウンド制限に対応した同期 ◦ 特定OTel SDKに依存しないこと 58 *https://github.com/embrace-io/opentelemetry-kotlin/tree/main | OpenTelemetry Kotlin SDK by Embrace
59. 独自SDKの仕様 定義対象：Span, Trace, Tracer のみ Tracer：Span の生成・終了管理 Span：属性、トレースContext伝搬 Trace：複数Spanの集合として処理 59
60. 独自SDKの設計 60 expect class Catracer { fun startSpan( name: String, parent: CatSpan? = null, attributesMap: Map<String, String> = emptyMap(), startTimeNanos: Long? = null ): CatSpan fun getOngoingSpan(spanDeclaration: AppSpanDeclaration): CatSpan? } Kotlin
61. 独自SDKの設計 61 expect class CatSpan { val attributes: Map<String, Any> val name: String val traceId: String? val spanId: String? val parentSpan: CatSpan? val isRecording: Boolean fun start(startTimeMs: Long? = null): Boolean fun stop(stopTimeMs: Long? = null) fun putAttribute(key: String, value: String) } Kotlin
62. 独自SDKの設計 62 interface AppSpanDeclaration { val spanName: String } enum class AppSpans(override val spanName: String) : AppSpanDeclaration { COLD_APP_STARTUP_SPAN("cold_app_startup"), HOME_SCREEN_FULLY_RENDERED("first_screen_fully_rendered"); } Kotlin
63. 実際に測定してみよう！ ユーザーの環境で指標を測定する 63
64. 実際の測定 アプリ起動時間（ Cold） 　 ネットワークリクエストの詳細トレース 64
65. アプリ起動時間（Cold） 65
66. class App : Application() { var processStartupTimestamp: Long? = null override fun attachBaseContext(base: Context?) { processStartupTimestamp = SystemClock.elapsedRealtimeNanos() super.attachBaseContext(base) } Kotlin 66
67. class App : Application() { override fun onCreate() { super.onCreate() val tracer = Catracer by inject() catracer.startSpan( AppSpans.COLD_APP_STARTUP_SPAN, startTimeNanos = processStartupTimestamp ) val handler = Handler(Looper.getMainLooper()) handler.post(DetectStartFromBackgroundRunnable(tracer)) //... Kotlin 67
68. registerActivityLifecycleCallbacks(object : ActivityLifecycleCallbacks { override fun onActivityCreated( activity: Activity, savedInstanceState: Bundle? ) { catracer.getOngoingSpan(AppSpans.COLD_APP_STARTUP) ?.putAttribute("has_been_started_by_user", "true") } 　　override fun onActivityResumed(activity: Activity) { catracer.getOngoingSpan(AppSpans.COLD_APP_STARTUP)?.stop() unregisterActivityLifecycleCallbacks(this) } //... Kotlin 68
69. registerActivityLifecycleCallbacks(object : ActivityLifecycleCallbacks { override fun onActivityCreated( activity: Activity, savedInstanceState: Bundle? ) { catracer.getOngoingSpan(AppSpans.COLD_APP_STARTUP) ?.putAttribute("has_been_started_by_user", "true") } 　　override fun onActivityResumed(activity: Activity) { catracer.getOngoingSpan(AppSpans.COLD_APP_STARTUP)?.stop() unregisterActivityLifecycleCallbacks(this) } //... Kotlin 69
70. /** * 仕組みの説明 * 1) この Runnable は、App#onCreate 内でメインスレッドにポストされる * 2) アプリプロセスがバックグラウンドから起動された場合、この Runnable は どの Activity#onCreate よりも先に実行される * 3) 一方、アプリがユーザーによって起動された場合は、必ず Activity#onCreate がこの Runnable より先にシステムによってスケジューリングされる */ class DetectStartFromBackgroundRunnable( private val tracer: Catracer ) : Runnable { override fun run() { val span = tracer.getOngoingSpan(AppSpans.COLD_APP_STARTUP_SPAN) ?: return if (!span.attributes.containsKey("has_been_started_by_user")) { // スパンをキャンセルするか、もしくはあえてバックグラウンドのケースを記録するか } } } Kotlin 70
71. アプリ起動時間 71
72. アプリ起動時間の測定結果 72
73. アプリ起動時間の測定結果 73
74. 実際の測定 アプリ起動時間（Cold） 　 ネットワークリクエストの詳細トレース 74
75. ネットワークリクエストの測定 75 fun provideOkHttpClient(tracer: Catracer): OkHttpClient { return OkHttpClient.Builder() .eventListenerFactory { TimingEventListener(tracer) } .build() } Kotlin override fun dnsStart(call: Call, domainName: String) { super.dnsStart(call, domainName) dnsSpan = startSpanForMetric("dns_lookup") } override fun dnsEnd(call: Call, domainName: String, inetAddressList: List<InetAddress>) { super.dnsEnd(call, domainName, inetAddressList) dnsSpan?.stop() } Kotlin
76. 76 ネットワークリクエストの測定結果
77. このセッションのゴール Performance for CVR！パフォーマンス管理の重要性 既存ツール (Firebase, Systrace) のスケールにおける限界 分散トレーシングの概念と有効性の説明 モバイルアプリでの分散トレーシング（OTel）の導入方法 Otelの運用の具体的なイメージ 77
78. OpenTelemetryの可視化と運用 78 測定から観測まで
79. バックエンド 79
80. OpenTelemetry Collector 80
81. OpenTelemetry Collector 81
82. OpenTelemetry Collector 82
83. OTel Collector の正体 83 …
84. OpenTelemetry Collector 84 • 非柔軟 • 単一障害点 • 帯域幅が狭い • スケール不能 • OTelを始めるのに最適 • アプリとコレクターの 関係が明確 …
85. Gateway 設定パターン 85 1. アプリからSDK経由でOTLPデータをLoadBalancer(nginx)に送信 2. nginxは負荷を分散し、複数のコレクターに転送 3. コレクターはデータを複数のバックエンドに送信 * https://opentelemetry.io/docs/collector/deployment/gateway/ Gateway | OpenTelemetry …
86. OpenTelemetry を立ち上げる 86
87. Agent Collector + Jaegerの設定 87
88. Collector + Jaegerエクスポーターの設定 88 > andousan@andousan otel % docker compose -f docker-compose.yaml up bash
89. Collector + Jaegerエクスポーターの設定 89
90. Agent Collector （複数バックエンド） 90
91. Grafana (alloy) 91
92. Honeycomb 92
93. DataDog 93
94. 結果考察 94
95. 導入前後での観測プロセスの変化 95 Before After
96. パフォーマンス問題調査のフロー（FPM） ケース：画像表示までの時間が閾値を超える場合がある 1. Firebase Performanceでのパフォーマンスの異変に気づく 2. Android Studioのプロファイラーを利用して手元で調査する 3. ユーザー環境の問題の場合は調査が難航する 4. この先は手探り 96
97. Firebase Performance (before) • 遅いのか • 早いのか 97
98. パフォーマンス問題調査のフロー（Otel） ケース：画像表示までの時間が閾値を超える場合がある 1. 関連のログ・メトリックス等を参考にする 2. モニタリングの時点でボトルネックを特定する 3. パフォーマンスを改善する策を検討する 4. 対策を入れたらリリース（Feature Toggle利用可） 98
99. OpenTelemetry + Grafana (after) 99
100. OpenTelemetry + Grafana (after) 100
101. OpenTelemetry + Grafana (after) 101
102. Firebase Performance vs OTel 102 Firebase Performance OpenTelemetry SDK Open Source ❌ 🟢 Vendor-Lock Free ❌ 🟢 分散トレーシング対応 ❌ 🟢 自動計装 🟢 🔺（独自実装） サンプリング制御可否 ❌ 🟢 バックエンド・インフラの 分散トレース ❌ 🟢 Logの対応 ❌ 🟢
103. NEXT 103
104. OTel SDKのオート計装 一部の実装ではFirebase Performanceのようにオート計装 （Zero-code instrumentation）を利用可能 ◦ ANR（応答停止）: 約5秒以上 UI が応答しない場合に Tracing 発行 ◦ クラッシュ（未処理例外）: 例外の名前、メッセージ、スレッド情報など付きで Tracing 発行 ◦ フレームの描画が >16ms（slow）または >700ms（frozen）において Tracing 発行 ◦ Fragment ライフサイクルや UI インタラクションも自動追跡可能 104
105. AIと連携したモニタリングについて • MCPのサーバーなどを利用すれば、任意のトレースに対して モニタリングの段階で以下のような改善の提案をしてくれる 105 In mobile apps, you can preload a connection before it’s actually needed: For example, as soon as the splash screen appears, fire an async HEAD or small request to the API to open the TCP/TLS connection. By the time the UI needs data, the connection is already live.
106. AIと連携したモニタリングについて • 一部のバックエンドではすでに導入されている 106
107. KMP対応の OpenTelemetry SDK • expect/actual で 各プラットフォームで実装を指定すれば KMPを 対応したSDKが実装可能 ◦ Android: opentelemetry-kotlin SDK ◦ iOS: opentelemetry-swift SDK 107
108. オミットしたテーマ • アプリのバックエンドのテレメトリデータ連携 （Context propagation） • Baggage • 指標とメトリックスの関連付け（Examplar） • ランタイムプロファイラ（α） • などなど 108
109. ご清聴ありがとうございました 109