Xcode Instrumentsでパフォーマンス改善に挑戦してみた話

Xcode Instrumentsでパフォーマンス改善に挑戦してみた話 学習記録

インタラクティブウィジェットの実装が落ち着いたころ、一覧画面をスクロールすると時々カクつくことが気になり始め、Xcode Instrumentsでのパフォーマンス調査に挑戦しました。

1. どのツールを使えばいいか分からず迷った

Instrumentsを開くと、Time Profiler、Allocations、Core Animationなど数多くのツールが並んでいて、最初はどれを使えばいいのか全く見当がつきませんでした。

カクつき・動作が重い → Time Profiler
メモリが増え続ける → Allocations / Leaks
アニメーションが滑らかでない → Core Animation(Hitches)

症状に応じてツールがある程度決まっていると知り、今回のスクロール時のカクつきには「Time Profiler」を使うところから始めることにしました。目的を決めずに触っていると情報量に圧倒されてしまうと実感しました。

2. 何もしていない時間まで計測に含めてしまっていた

最初にTime Profilerで記録したとき、アプリを起動してから何もせず放置している時間も含めて計測してしまい、結果が薄まって原因を特定しづらくなっていました。

問題が起きる操作(スクロール)だけをピンポイントで記録するようにし、それ以外の待機時間はできるだけ含めないようにしたところ、原因箇所がグラフ上ではっきり浮かび上がるようになりました。計測範囲を絞ることの大切さを学びました。

3. メインスレッドをふさいでいる処理に気づかなかった

Time Profilerの結果を見ても、最初はどの行が問題なのか読み取れず、ただの数字の羅列にしか見えませんでした。

Main Thread の呼び出しスタックを重い順に確認
→ 画像のリサイズ処理がメインスレッドで実行されていた

呼び出しスタックをたどっていくと、セルに表示する画像をその場でリサイズする処理がメインスレッド上で毎回実行されていることが分かりました。スクロール中に重い処理が挟まると、画面の更新がブロックされてカクついて見える、という仕組みを初めて実感を伴って理解できました。

4. バックグラウンドに逃がしただけで満足しかけた

画像のリサイズ処理をバックグラウンドスレッドに移したところ、体感は改善したものの、本当に直ったのか確信が持てないまま「良くなった気がする」で終わらせそうになりました。

修正後にもう一度Time Profilerで同じ操作を記録し、メインスレッドの負荷が実際に下がっていることを数値で確認して初めて、改善できたと言い切れる状態になりました。感覚だけで判断せず、計測前後を比較することの重要性を学びました。

まとめ

  • 症状に応じて使うInstrumentsのツールはある程度決まっている。目的を決めてから触る
  • 計測は問題の起きる操作だけに絞る。無関係な待機時間を含めると原因が見えにくくなる
  • Time Profilerでは、メインスレッドの呼び出しスタックを重い順にたどると原因箇所が見えてくる
  • 改善したかどうかは体感ではなく、修正前後の計測結果を数値で比較して判断する

「なんとなく重い」という曖昧な感覚を、具体的な数値と原因箇所に変換できたのが今回の一番の収穫でした。

次は、CryptoKitでデータを暗号化してみた話をまとめます。


本記事は生成AI(Claude)を活用して執筆・編集しています。内容は実体験に基づき、執筆者本人が確認・監修しています。

コメント

タイトルとURLをコピーしました