アプリの「もっさり」を解決！MetricKitを活用したアプリのパフォーマンス改善

iOSDC Japan 2025にて登壇した内容になります。
----------------------------------------------------------------

―「最近アプリがもっさりしてきた」「なんだか動作がもたつく」―
こうしたパフォーマンスに関するフィードバックを一度は受け取ったことがあるのではないでしょうか。
しかし、この「もっさり」は一体なにが原因で、どれくらい遅いのか？定性的な印象だけでは、改善の手がかりがつかめません。
弊社が開発しているアプリでも、特に利用頻度の高いユーザーから「もっさりする」といった声が寄せられていました。
そんな見えない「もっさり」の正体を明らかにし、改善につなげるためにMetricKitを活用しました。

## このトークで話すこと
本トークでは、ユーザーの「アプリがもっさりする」という定性的な問題を、MetricKitを使って定量的に分析し、改善した方法を紹介します。

- MetricKitの概要と選定理由
- MetricKitを使ったパフォーマンスの見える化
- メトリクスの収集プロセス
- メトリクスの分析手法と整理方法
- メトリクスの分析から見えたボトルネックとなっていたCoreDataの処理
- 実際に行った改善アプローチとその効果
- CoreDataの処理の最適化
- 計算量を意識した実装
- 結果：処理時間を大幅短縮し、ユーザー満足度も向上
- コードのパフォーマンスを測定する方法

あなたのアプリにも、ユーザーがまだ言葉にしていない「もっさり」が潜んでいるかもしれません。
パフォーマンス改善の第一歩は、現在の状態を正しく測ること。つまり、「定量化」です。
本トークを通じて、ユーザーの体感を数字で捉え、改善へつなげる方法を知ることができます。
ユーザーから「アプリが軽くなった！」という喜びの声を聞く方法を一緒に学びましょう！

Transcript

1. アプリの「もっさり」を解決︕ MetricKitを活⽤した アプリのパフォーマンス改善 Arata Goto / @otouto555 2025/09/20 iOSDC Japan 2025 1
2. ⾃⼰紹介 ・Arata Goto （@otouto555） ・新卒5年⽬ ・FPS/筋トレ ・⼈⽣初登壇 ・株式会社レコチョク 2
3. ミッション ⾳楽市場の最⼤活性化 ビジョン ⼈と⾳楽の新しい関係をデザインする ⾳楽×
4. 事業領域 直販Eコマース DX/運⽤等 業務⽀援 ソリューション BtoB BtoC 定額制サービス アラカルト インディーズ 活動⽀援 メディア ⾃主盤CD販売/グッズ販売/ライブ⽀援等 エージェント DIY向け ディストリビューション ディストリビューション ⾳楽配信 for Biz
5. 本題
6. 本⽇伝えたいこと
7. 測定をしよう︕
8. 突然ですが 8
9. パフォーマンス測定 してますか︖ 9
10. こんなお問合せが 10
11. アプリがもっさりする 11
12. アプリがもっさりする 12
13. もっさりとは︖ 13
14. もっさりとは︖ もっさりは定性的で捉えにくい問題 14
15. もっさりとは︖ もっさりは定性的で捉えにくい問題 もっさりを定量化したい︕ 15
16. もっさりとは︖ もっさりは定性的で捉えにくい問題 もっさりを定量化したい︕ 定量化することで •具体的な改善施策を⽴てやすくなる •改善後の効果検証も⾏いやすくなる 16
17. 定量化するための⽅法を探す
18. もっさり感を定量化するために iOSアプリのパフォーマンス測定フレームワーク のMetricKitを導⼊ •アプリの描画時間 •アプリのUI操作ができなくなる（ハング）時間 •メモリ使⽤量 •ディスク書き込み量 •診断データ など 18
19. よし︕データを集めるぞ︕
20. 20 STOP! ⚠ ⚠
21. ✋このままデータを 闇雲に収集する前に
22. 仮説を⽴てる
23. 仮説を⽴てよう • 仮説なしに闇雲にデータを集めても、 何を⾒れば良いか分からない •「何を検証したいか」が明確だと、 必要なデータが特定しやすい 23
24. 問い合わせしていただいた ユーザーを調査する
25. お問い合わせユーザの傾向を探る 25 「お気に⼊り楽曲登録」の 利⽤率が⾼いユーザー
26. 【仮説】 楽曲登録処理周りと パフォーマンスに関係がありそう
27. メトリクスを追加 iOSアプリのパフォーマンス測定フレームワーク のMetricKitを導⼊ • アプリの描画時間 • アプリのUI操作ができなくなる（ハング）時間 • メモリ使⽤量 • ディスク書き込み量 • 診断データ など • 楽曲登録件数←NEW!!! 27
28. なぜMetricKitなのか
29. 利⽤シーン別の⽐較表 29 Xcode Organizer MetricKit データの 収集範囲 全ユーザーの 集計値 ユーザーごと の個別データ いつ使うか 全体の傾向を 確認 特定問題の 詳細調査
30. メトリクスの収集プロセス
31. 集めたメトリクスの流れ 31 サーバー アプリ
32. 集めたメトリクスの流れ 32 BigQuery アプリ
33. 収集されるメトリクスの例
34. 収集されるメトリクスの例（メモリ） 34 "memoryMetrics" : { "peakMemoryUsage" : "200,000 kB", "averageSuspendedMemory" : { "averageValue" : "100,000 kB", "standardDeviation" : 0, "sampleCount" : 500 }
35. "memoryMetrics" 収集されるメトリクスの例（メモリ） 35 メモリに関するメトリクス
36. "peakMemoryUsage" : "200,000 kB", 収集されるメトリクスの例（メモリ） 36 ピーク時のメモリ使⽤量
37. "averageSuspendedMemory" : { "averageValue" : "100,000 kB", "standardDeviation" : 0, "sampleCount" : 500 収集されるメトリクスの例（メモリ） 37 サスペンド状態のメモリ使⽤量
38. 収集されるメトリクスの例（ハング時間） 38 "applicationResponsivenessMetrics": { "histogrammedAppHangTime": { "histogramNumBuckets": 2, "histogramValue": { "0": { "bucketCount": 50, "bucketStart": "0 ms", "bucketEnd": "100 ms" }, "1": { "bucketCount": 60, "bucketStart": "100 ms", "bucketEnd": "400 ms" } n=110
39. n=110 収集されるメトリクスの例（ハング時間） 39 "0": { "bucketCount": 50, "bucketStart": "0 ms", "bucketEnd": "100 ms" },
40. n=110 収集されるメトリクスの例（ハング時間） 40 "1": { "bucketCount": 60, "bucketStart": "100 ms", "bucketEnd": "400 ms" } c
41. 収集されるメトリクスの例（ハング時間） 41 ヒストグラム形式の データは扱いづらい n=110
42. 収集されるメトリクスの例（ハング時間） 42 中央値を代表値として 集計する n=110
43. 収集されるメトリクスの例（ハング時間） 43 データ数は110個 →55番⽬のデータ n=110
44. 収集されるメトリクスの例（ハング時間） 44 100~400の中央の値を 代表値として取得する n=110 250ms
45. 集めたメトリクスの分析
46. 分析する メトリクスと楽曲登録件数の 相関係数を調査 相関係数: 2つのデータ（変数）の 関係性の強さを⽰す指標 46
47. 分析する •「楽曲登録件数が多いユーザーほど ハング時間が⻑い」 •その他のメトリクスと楽曲登録件数 には関連性が⾒られない 47
48. ハング時間と楽曲登録件数との関係 48
49. ハング時間と楽曲登録件数との関係 49 弱い正の相関（0.34）が⾒られる
50. ハング時間と楽曲登録件数との関係 50 かなりのユーザーが2.5秒以上の ハング時間を体感している
51. 分析の結果まとめ •楽曲取得処理がハング時間の増加に 関与 •そこのボトルネックを解消すれば、 ハング時間を削減できそう 51
52. ハング時間と楽曲登録件数との関係 52 ハング時間が全体的に削減するはず
53. 原因となっている コードを探す
54. Time Profilerで計測する ボトルネックの処理を探すために Instruments > Time Profilerを使⽤ 54
55. Time Profilerで計測する 55 ボトルネックの処理を探すために Instruments > Time Profilerを使⽤
56. Time Profilerで計測する 56 •メインスレッドでハングしている場所 を検出できた •この段階でAPIではなく、アプリ側に 問題があることも切り分けできた
57. 問題となっていた処理 57 APIから楽曲リストを取得 楽曲ごとにCoreData検索 差分があれば更新・保存
58. 問題となっていた処理 58 // メインスレッドで実⾏ apiTracks.forEach { apiTrack in let storedTrack = fetch(id: apiTrack.id) storedTrack.update(apiTrack) save() }
59. 問題となっていた処理 59 // メインスレッドで実⾏ apiTracks.forEach { apiTrack in let storedTrack = fetch(id: apiTrack.id) storedTrack.update(apiTrack) save() } APIから取得した楽曲リスト
60. 問題となっていた処理 60 // メインスレッドで実⾏ apiTracks.forEach { apiTrack in let storedTrack = fetch(id: apiTrack.id) storedTrack.update(apiTrack) save() } CoreDataから楽曲情報を取得
61. // メインスレッドで実⾏ apiTracks.forEach { apiTrack in let storedTrack = fetch(id: apiTrack.id) storedTrack.update(apiTrack) save() } 問題となっていた処理 61 差分を更新し保存
62. イケテナイポイント 62 // メインスレッドで実⾏ apiTracks.forEach { apiTrack in let storedTrack = fetch(id: apiTrack.id) storedTrack.update(apiTrack) save() }
63. イケテナイポイント 63 毎回CoreData取得・更新処理 // メインスレッドで実⾏ apiTracks.forEach { apiTrack in let storedTrack = fetch(id: apiTrack.id) storedTrack.update(apiTrack) save() }
64. イケテナイポイントまとめ 🙅 メインスレッドで重い同期処理を実⾏ している 🙅 CoreDataのアクセス回数が増えている 64
65. ボトルネックを解消する
66. 以下の点に着⽬ メインスレッドで重い同期処理を実 ⾏していないか︖ CoreDataのアクセス回数は減らせな いか︖ 計算量を削減できないか︖ 66
67. 以下の点に着⽬ メインスレッドで重い同期処理を実 ⾏していないか︖ 67
68. let context = CoreDataStore.shared.viewContext LocalMusicStore.updateTracks( with: tracksInfo, in: context ) メインスレッドの処理を改善する 68
69. let context = CoreDataStore.shared.viewContext LocalMusicStore.updateTracks( with: tracksInfo, in: context ) メインスレッドの処理を改善する 69 メインスレッド⽤のcontext
70. メインスレッドの処理を改善する CoreDataStore.performBackgroundTask { context in LocalMusicStore.updateTracks( with: tracksInfo, in: context ) { // 保存完了を通知する処理など } } 70
71. メインスレッドの処理を改善する CoreDataStore.performBackgroundTask { context in LocalMusicStore.updateTracks( with: tracksInfo, in: context ) { // 保存完了を通知する処理など } } 71 バックグラウンド⽤のcontextを使⽤
72. 以下の点に着⽬ メインスレッドで重い同期処理を実 ⾏していないか︖ 72
73. 以下の点に着⽬ ✅ メインスレッドで重い同期処理を 実⾏していないか︖ 73
74. 以下の点に着⽬ ✅ メインスレッドで重い同期処理を 実⾏していないか︖ CoreDataのアクセス回数は減らせな いか︖ 74
75. CoreDataのアクセス回数を減らす 75 apiTracks.forEach { apiTrack in let storedTrack = fetch(id: apiTrack.id) storedTrack.update(apiTrack) save() }
76. CoreDataのアクセス回数を減らす 76 apiTracks.forEach { apiTrack in let storedTrack = fetch(id: apiTrack.id) storedTrack.update(apiTrack) save() } 楽曲の数だけCoreDataへの検索・更新処理 が⾛る
77. // 1回だけ取得する let storedTracks = fetchAllFromDB(trackIDs) // 1回だけ更新する saveAllToDB() Coredataのアクセス回数を減らす 77
78. // 1回だけ取得する let storedTracks = fetchAllFromDB(trackIDs) // 1回だけ更新する saveAllToDB() CoreDataのアクセス回数を減らす 78 CoreDataへの検索・更新処理を最⼩限にする
79. 以下の点に着⽬ ✅ メインスレッドで重い同期処理を 実⾏していないか︖ CoreDataのアクセス回数は減らせな いか︖ 79
80. 以下の点に着⽬ ✅ メインスレッドで重い同期処理を 実⾏していないか︖ ✅ CoreDataのアクセス回数は減ら せないか︖ 80
81. 以下の点に着⽬ ✅ メインスレッドで重い同期処理を 実⾏していないか︖ ✅ CoreDataのアクセス回数は減ら せないか︖ 計算量を削減できないか︖ 81
82. 計算量を削減する 82 apiTracks.forEach { apiTrack in … = storedTracks.first { $0.ID == apiTrack.ID } // 更新処理 }
83. 計算量を削減する 83 apiTracks.forEach { apiTrack in … = storedTracks.first { $0.ID == apiTrack.ID } // 更新処理 } CoreDataから取得した保存済み楽曲リスト
84. 計算量を削減する 84 apiTracks.forEach { apiTrack in … = storedTracks.first { $0.ID == apiTrack.ID } // 更新処理 } first(where:)のO(n)で楽曲を取得
85. 計算量を削減する let trackDictionary = Dictionary(uniqueKeysWithValues: storedTracks.map { ($0.ID, $0) } ) apiTracks.forEach { apiTrack in … = trackDictionary[apiTrack.ID] // 更新処理 } 85
86. 計算量を削減する let trackDictionary = Dictionary(uniqueKeysWithValues: storedTracks.map { ($0.ID, $0) } ) apiTracks.forEach { apiTrack in … = trackDictionary[apiTrack.ID] // 更新処理 } 86 楽曲IDと楽曲のDictionary型を作成する
87. 計算量を削減する let trackDictionary = Dictionary(uniqueKeysWithValues: storedTracks.map { ($0.ID, $0) } ) apiTracks.forEach { apiTrack in … = trackDictionary[apiTrack.ID] // 更新処理 } 87 O(1)で楽曲を取得
88. 以下の点に着⽬ ✅ メインスレッドで重い同期処理を 実⾏していないか︖ ✅ CoreDataのアクセス回数は減らせ ないか︖ ✅ 計算量を削減できないか︖ 88
89. 改善後の結果
90. 修正前のハング時間と楽曲登録件数 90
91. 修正後のハング時間と楽曲登録件数 91
92. 修正後のハング時間と楽曲登録件数 92 ハング時間が全体的に削減
93. ハング時間のパーセンタイル値の⽐較 93 バージョン 90パーセンタイル A（修正前） 2.76秒 B（修正後） 0.67秒 データを⼩さい順に並べたとき、初めから数えて 全体の90%に位置する値を90パーセンタイルという
94. 🎉改善できた🎉
95. しかし
96. もっと早い段階から パフォーマンスの低下に 気づけたのでは︖
97. ボトルネックの処理は引き継ぎ時点で発⽣ 97 プロジェクトの引き継ぎ時に パフォーマンスを⾒る観点がなかった
98. パフォーマンスの低下に気づくために 【開発中】 • XCTestのパフォーマンステスト • Time Profiler 【リリース後】 • MetricKit • Xcode Organizer • Firebase Performance Monitoring 98
99. 開発からリリース後まで パフォーマンスを監視できる 仕組みを作る
100. まとめ
101. 現状を知るためにまずは測定しよう • 測定すれば傾向が⾒えてくる • 改善効果も数字で把握できる •「測定 → 改善 → 検証」を回せる • パフォーマンスの低下に気づくこと ができる仕組みを作ろう 101
102. 測定がユーザー体験の 向上への⼀歩となる