InstrumentsによるSwiftUIのパフォーマンス最適化

InstrumentsによるSwiftUIのパフォーマンス最適化

新しいSwiftUIのInstrumentsを紹介します。SwiftUIによるビュー更新の仕組み、更新がアプリのデータに及ぼす影響、それらの影響の原因と結果を新しいInstrumentsで視覚化する方法について説明します。このセッションの内容を十分理解できるよう、SwiftUIによるアプリの記述を理解しておくことをおすすめします。

関連する章
- 0:00 - イントロダクションとアジェンダ
- 2:19 - SwiftUIのInstrumentsの紹介
- 4:20 - 長時間を要するビュー本体の更新の診断と修正
- 19:54 - SwiftUIによる更新の原因と結果の理解
- 35:01 - 次のステップ
リソース
関連ビデオ

WWDC25
- InstrumentsによるCPUのパフォーマンス最適化
WWDC23
WWDC22
- SwiftUIによるカスタムレイアウトの作成
WWDC21
- SwiftUIの徹底解説
Tech Talks
- UIアニメーションの滞りおよびレンダーループに対する検討
こんにちはInstrumentsチームのJedと Apple MusicチームのStevenです良いアプリはパフォーマンスが優れていますアプリでは実行するどのコードも遅延の原因になる可能性がありますアプリを分析してコードのボトルネックとなり得る部分を特定し問題を解決してアプリの円滑な動作を確保することが重要です本日のセッションでは SwiftUIコードにボトルネックがある場合にそれを特定する方法を詳しく説明しますまた SwiftUIの動作を効率化する方法も紹介しますそもそもどうすれば問題を認識できるのでしょうか気付かれやすい症状の1つにヒッチやハングが原因でアプリの反応が遅いことがあります映像の一時停止やコマ落ちスクロール動作の遅延などですパフォーマンス問題を特定する最もよい方法は Instrumentsによるプロファイリングです今日は SwiftUIを使用したコードのパフォーマンス問題を診断する方法を詳しく説明しますまずは Instruments 26に含まれている新しい SwiftUI Instrumentを紹介します次にビュー本体の更新が長いアプリについて確認しそれがなぜ一般的な問題なのかを説明してから Instrumentを使ってそれを発見し修正します最後に SwiftUIの更新の理由とその影響について詳しく説明します Instrumentを使って不要な更新を特定しそれらをなくす方法をお見せしますパフォーマンスの問題にはさまざまな根本原因が考えられますがここでは SwiftUIの使い方が原因であるものに的を絞ります
アプリの問題がSwiftUIコードと無関係なものである場合は事態を把握する出発点として「Instrumentsによるハング分析」と「Instrumentsによる CPUのパフォーマンス最適化」の視聴をお勧めします
私達は共同であるアプリを開発しています Steven 現時点での成果を見せてもらえますか？了解です名前は「Landmarks」ですこのアプリでは世界各地の魅力的な名所を取り上げていますそれぞれのランドマークには現在地からの距離が表示されるので次にどの目的地に向かうのかや飛行機での長旅になるのか車で簡単に行けるのかなど想像を巡らすことができますアプリは今のところ良さそうですがテストしていたところスクロールが思った通りに動作しない時があるのに気づきましたその原因を突き止めたいと思います Jed 先ほど話していた新しいSwiftUI Instrumentを紹介してもらえますかはい Instruments 26には SwiftUIアプリのパフォーマンス問題を特定するための新しい手段が追加されましたそれが次世代のSwiftUI Instrumentです
更新されたSwiftUIテンプレートにはアプリのパフォーマンス評価に役立ついくつかのInstrumentが含まれていますまず新しいSwiftUI Instrumentがありますこれについては後で詳しく説明します
次に Time ProfilerですこれはアプリがCPUで実行している作業のサンプルを経時的に表示します後はハングとヒッチの各Instrumentがありますこれらはアプリの応答性をトラッキングします
アプリで潜在的なパフォーマンスの問題を調査する際はまず SwiftUI Instrumentから得られるトップレベルの情報を確認します
SwiftUI Instrumentトラックの最初のレーンは「Update Groups」で SwiftUIが動作している期間を示します
このレーンが空いている期間に CPU使用率が急上昇している場合は問題がSwiftUIの外にある可能性が高いことがわかります SwiftUI Instrumentトラックの他のレーンでは SwiftUIの長い更新とその発生時期を容易に特定できます
はビューの「body」プロパティの実行時間が長すぎる時を示していますでは時間が長すぎるビューとビューコントローラの表示可能な更新が特定されます
は前2つ以外の SwiftUIの長い動作を示していますパフォーマンス低下を生じさせている可能性があるすべての長い更新の概要をこれら3つのレーンで把握できます更新はオレンジと赤で表示されますこれはヒッチやハングに寄与している可能性に応じた色付けですこれらの更新が実際にアプリにハングやヒッチを発生させるかどうかはデバイスの状態によりますが長い更新を調べることそして赤の更新をまず確認することが通常は最適な出発点となります
SwiftUI Instrumentを使用するにはまずXcode 26をインストールします次にアプリの実行とプロファイリングを行うデバイスを最新の OSリリースにアップデートします最新リリースはSwiftUIトレースの記録に対応しています Landmarksアプリはもうプロファイリングできると思います -Steven 始めてください -ありがとう Jed
プロジェクトはすでにXcodeで開いています command + Iキーでプロファイリングを開始するとアプリがリリースモードでコンパイルされ Instrumentsが自動で起動します
テンプレートの選択画面で SwiftUIテンプレートを選びます
記録ボタンをクリックして記録を開始します
まずランドマークの一覧をスクロールします大陸ごとに水平方向のシェルフがあります
北米のシェルフの端まで横にスクロールしてビューを追加で読み込みます
記録の停止をクリックします
記録が停止された後 Instrumentsはデバイスからプロファイリングデータをコピーし分析用に処理します処理が完了したら SwiftUI Instrumentを使用して注目すべき潜在的なパフォーマンス問題があるかどうかを判断することができますすべての内容が見えやすいようにウインドウを最大化します
まずは SwiftUI Instrument トラックにあるトップレベルの長い更新レーンを調査します
実行時間が長すぎるビュー本体は SwiftUIでパフォーマンス問題の原因になることが多いためレーンを最初に調べます
オレンジと赤の長い更新がいくつかあるのでそれらを調査したいと思います SwiftUIトラックをクリックして拡大します
3つのサブトラック、、が表示されます各サブトラックでもトップレベルのレーンと同様に長い更新がオレンジと赤で表示されます残りの更新はグレーで表示されますトラックを選択します
下の詳細ペインにはプロファイリングセッション中に実行されたすべてのビュー本体の階層型の要約があります階層内で私のアプリのプロセスを展開すると実行されたすべてのビュー本体の更新に関するモジュールが一覧表示されます
ドロップダウンをクリックしの要約を選択することで長い更新だけに絞り込むことができます
数から調査が必要な長い更新がいくつかあることがわかります
モジュールをクリックして展開します LandmarkListItemViewに長い更新がいくつかあるためこのビューから始めます
ビュー名にカーソルを合わせると矢印が表示されます
それをクリックするとコンテキストメニューが開きますを選択しますするとこのビューの本体の長い更新が順番に記載された一覧が表示されます
長い更新の1つを右クリックしをクリックします
このビュー本体の更新の間隔がトレース内の選択範囲として設定されます次に Time Profiler Instrument トラックをクリックします
ここではビュー本体の実行中にCPUで起きていることを確認できます
Time Profilerは定期的に CPUでの実行内容をサンプリングしてデータを収集します各サンプルについてどの関数が実行中かチェックしその情報をプロファイリングセッションに保存するのです下のプロファイルの詳細ペインにはトレース中に記録されたサンプルのコールスタックが表示されますこの例ではビュー本体の実行中に記録されたサンプルになります
Optionキーを押しながらクリックし主スレッドのコールスタックを展開します
SwiftUIの動作が非常に深いコールスタックで表されていますここで最も興味深いのは LandmarkListItemViewですコールスタックを検索するため command + Fキーを押し検索フィールドに名前を入力します
ビュー本体がありました左端の列にコールスタックの各フレームに費やされた時間が Time Profilerによって表示されます
この列を見るとビュー本体に費やされた時間のほとんどは distanceという計算プロパティ内だったようです distanceで最も重い2つのフレームは 2つの異なるフォーマッタへの呼び出しです
この測定フォーマッタとこの数値フォーマッタです Xcodeに戻りコードで何が起こっているのかを確認しましょう
これはLandmarkListItemViewで一覧内の各ランドマークのビューです
そしてこれがTime Profilerで気づいた distanceプロパティですこのプロパティはランドマークからの距離をビューでの表示用に書式設定された文字列に変換します
これが数値フォーマッタです Time Profilerで見て作成の負荷が高かったものです
こちらは文字列を作成する測定フォーマッタですこれもビュー本体に長い時間が費やされる大きな要因となっていました
ビュー本体ではラベルテキストの作成のために distanceプロパティを読み取っていますこれはビュー本体の実行のたびに行われますビュー本体は主スレッドで実行されるためアプリは距離のテキストが書式設定されるのを待ってから UIの更新を続行します
なぜこれが重要かというとビュー本体の実行時間が1ミリ秒というのは長くないように思えますが積み重なると長い時間になる可能性があり特に画面上の多数のビューを更新する場合はそれが顕著になるからです SwiftUIがビュー本体を実行する時間についてはどのように考えればいいでしょういい質問ですまず Appleプラットフォームでのレンダリングループの動作を説明しますフレームごとにアプリが起動してタッチやキープレスなどイベントを処理しますそしてUIを更新しますその際変更されたSwiftUIビューの bodyプロパティを実行しますこの作業は各フレームの期限までにすべて完了する必要がありますアプリは作業をシステムに引き渡しシステムは次のフレームの期限までにビューをレンダリングしますそしてレンダリングされた出力はその期限が来るとすぐに画面に表示されますここではすべてが適切に機能しています更新は対応するフレームの期限が来る前に完了するためシステムが各フレームをレンダリングして画面上に表示するのに十分な時間がありますこれをビュー本体に時間がかかりすぎてヒッチが生じたアプリと比較してみましょう
前と同様先にイベントを処理してから UIの更新を実行しますしかしこの最初のフレームで UIの更新に時間がかかりすぎましたそのため UIの更新部分がフレームの期限を過ぎて実行されましたということは次の更新は後のフレームまで開始できませんこのフレームでは期限の時点でレンダラーに作業を引き渡す準備ができていません
その結果次のフレームのレンダリングが完了するまで画面に前のフレームが表示されたままになります画面への表示時間が長すぎるフレームを呼び出すと後のフレームが遅延しヒッチが生じますヒッチは映像の滑らかさを減少させますヒッチの詳細については「Understanding hitches in your app」の記事をご覧くださいまたこちらのTech Talkでもレンダリングループと各種ヒッチの修正方法を詳しく説明していますビュー本体の実行時間が重要な理由の理解に役立ったでしょうかええとても役に立ちましたビュー本体の更新の実行に必要以上の時間がかかる場合アプリがフレームの期限を守れずヒッチが発生するリスクがあるんですねそうすると本体の実行中ではなくビューを表示する前にランドマークごとに距離の文字列を計算しキャッシュする方法が必要になりますではコードに戻りましょう
こちらはビュー本体の更新のたびに実行されるdistanceプロパティですこの作業はビュー本体の実行中に行わないようにしてより一元的な場所に移動させることにします移動先は位置の更新を管理するクラスです
LocationFinderクラスには位置変更のたびに更新を受け取る役割があります書式設定された距離の文字列はビュー本体で計算するかわりに事前に作成してここにキャッシュすることができるのでビューが距離の文字列を表示するときにはいつでも計算が済んでいます
まずイニシャライザを更新して前にビュー本体で作成していたフォーマッタを作成します
測定フォーマッタを格納するため formatterプロパティを追加しました
イニシャライザの上部に前にビューで作成していた数値フォーマッタを作成します
また測定フォーマッタも作成し新しく追加したプロパティに格納しますフォーマットは変わらないため距離の文字列の更新が必要なときには常にフォーマッタを再利用すればビュー本体の実行時に毎回新しいフォーマッタを作り直すコストを防止できます次に必要なときにビューで文字列を使用できるよう文字列をキャッシュしておく手段が必要ですこれらの更新を管理するためのコードを追加します
ランドマークを格納する配列がありますこれは距離の計算に使います
距離の文字列を計算後にキャッシュするための辞書も用意しました
このupdateDistances関数は位置の変更のたびに文字列を再計算します
ここでフォーマッタを使用して距離のテキストを作成し
ここでテキストをキャッシュに格納します
そしてすぐにこの最後の関数を呼び出してキャッシュ済みのテキストを取得します
最後にもう1つ必要なのは位置が更新されたら文字列のキャッシュを更新することです
Jump Barのドロップダウンをクリックし
didUpdateLocations関数に移動しますこれは位置変更の際に CoreLocationが呼び出す関数です
ここで前に作成した updateDistances関数を呼び出します
ではビューに戻ります
ビューを更新してキャッシュ済みの値を使用します
以上の変更でビュー本体の更新の遅延を修正できたはずです
改善されたことを確認するために修正を実装してから記録した Instrumentsトレースを見てみましょう
トラックを選択すると詳細ペインのの要約で LandmarkListItemViewへの長い更新がなくなったことがわかります
要約には長いビュー本体の更新がまだ2つありますがそれらの更新はトレースのごく初期に発生していますこれはアプリが最初のフレームのレンダリングを準備しているからですアプリ起動直後の更新に時間がかかるのは珍しくありませんシステムがアプリの初期ビュー階層をビルドしますがこれはヒッチを招きませんここで重要な点はスクロール時のヒッチの原因になっていた可能性がある LandmarkListItemViewの長い更新が修正され一覧から消えたことですつまりすべてのビューの表示が正常に機能しているので SwiftUIの遅延はないと確認できます
ビュー本体の長い更新の修正はアプリのパフォーマンスを高める良い方法の1つですしかし他にも考慮すべきことがありますビュー本体の更新が無駄に多い場合もパフォーマンスの問題が発生します理由を探ってみましょう
これは前にJedが紹介した図ですが今回は他の更新よりも長くかかった更新が 1つあるのではなく比較的高速な更新がたくさんありそれらをすべてこのフレーム内で実行する必要があります
この余分な作業によりアプリが期限内にフレームを送信できなくなっています前と同様次の更新は1フレーム分遅れますレンダラーに引き渡すものがないためまたヒッチが発生します前のフレームが2フレームにわたって表示され続けるからです無駄なビュー更新がパフォーマンスに及ぼす影響についてお話しするのはそれが今取り組んでいるアプリの新しい機能に大きく影響しそうだからですすべてのランドマークをスクロールするのはいろいろな場所を見れて楽しいのですが行き先の優先順位を付けるのに苦労しますそこでそれを簡単にするアイデアを考えましたご覧ください各ランドマークに新しくハートボタンを追加しましたタップでお気に入りへの追加と削除ができます
コードを見てみましょう
LandmarkListItemViewに新しいハートボタンを表示するオーバーレイを追加しました
ボタンのアクションによってモデルデータクラスの toggleFavorite関数が呼び出されお気に入りへの追加／削除が行われます
ランドマークのアイコンのハートはお気に入りの場合は塗りつぶされそうでない場合は空になります
commandキーを押しながらtoggleFavoriteをクリックしこの関数に移動します
お気に入りを追加する方法はこうです
このモデルにお気に入りのランドマークの配列を格納しお気に入りが追加されたらランドマークを配列に追加します
お気に入りを削除する場合は逆の処理を行います
現時点ではこのような状態ですもちろんさらに作業が必要ですが開発中にInstrumentsで早くから頻繁にプロファイリングしておくのはいいことですでは新機能のパフォーマンスを確認してみましょう command + Iキーを押してアプリをビルドし Instrumentsに切り替えて
記録ボタンをクリックします
そして前と同様北米のリストまで下にスクロールし
右にスライドして
ハートをタップしミュアウッズをお気に入りにします家からそれほど遠くなくそれでいて行ったことがない場所だからです今度は上にスクロールして遠く離れた場所をお気に入りにしてみましょう富士山はどうでしょうきっと楽しい旅になりますここで記録を停止します
新しいお気に入りボタンをタップしても不要な更新が余分に発生しないことを確認したいと思います自分が予想する事態を念頭においてトレースを分析し予想から外れているものを探すことが潜在的な問題を特定するうえで効果的です
SwiftUI Instrumentトラックをクリックして展開しサブトラックを選びます
ミュアウッズと富士山の2つのお気に入りボタンをタップしたのでこの2つのビューが更新されたと予想しますボタンは下までスクロールした後にタップしておりトレースの後半に記録されています関心のある部分だけに注目するためトレースの後半をハイライトします
下にある詳細ペインを確認します階層を展開してビューの更新の一覧を表示します
驚いたことに LandmarkListItemViewはかなりの回数更新されていましたなぜでしょうか UIKitアプリでビューの更新をデバッグする場合は通常コードにブレークポイントを設定しバックトレースを調べてビューの更新理由を解明しますしかしLandmarksなどのSwiftUIアプリではうまく行きませんでした SwiftUIのコールスタックはわかりにくいようです Jed この手法がSwiftUIアプリでうまくいかないのはなぜでしょうか説明します Xcodeではブレークポイントでバックトレースが表示されるため UIKitアプリの命令型コードの原因と結果を把握できます UIKitは命令型フレームワークのため原因と結果のデバッグには多くの場合バックトレースが役立ちますここでラベルが更新されていることがわかります viewDidLoadのisOnプロパティを設定しているからですバックトレース内のいくつかのシステムフレームの名前から推測するにこれはアプリが最初のシーンを起動している間に起こったようです同じ内容を実行する類似の SwiftUIアプリと比較すると SwiftUI内に再帰的な更新がいくつかあるのがわかりますこれらの更新はフレームごとに AttributeGraph内で行われていますどれを見てもビューの更新が必要である具体的な理由はわかりません
SwiftUIは宣言型のためバックトレースからはビューの更新の理由を把握できませんでは SwiftUIビューの更新の原因はどうすればわかるでしょうかまず SwiftUIの仕組みを理解する必要があります
簡単なビューの例を通して SwiftUIがデータモデルであることを説明します AttributeGraphはビュー間の依存関係を定義して必要がない限りビューの再実行を回避します今日は細部まで説明しませんがここでアプリの更新の流れを理解するうえでの基礎を学べると思います
ビューはViewプロトコルへの準拠を宣言します次に bodyプロパティを実装して別のView値を返すことで外観と動作を定義します
OnOffViewは本体からTextビューを返し isOn状態変数の値に応じて変化するラベルを渡します
このビューがビュー階層に最初に追加されるとき SwiftUIはビュー構造体を格納する親ビューから属性というオブジェクトを受け取りますビュー構造体は頻繁に作り直されますが属性はIDを維持しビューの有効期間を通して状態を保ちますそのため親ビューの更新時にはこの属性の値は変わってもそのIDは変わりませんビューは独自の属性を作成して状態を格納し動作を定義するよう求められますそこでまず isOn状態変数用のストレージとその状態変数の変化をトラッキングする属性が作成されます次にビューは本体を実行するための新しい属性を作成します本体はこの両方の属性に依存しますビュー本体の属性は新しい値の生成を求められるたびに親ビューから渡されたビューの現在の値を読み取ります次に属性はそのビュー構造体のコピーを状態変数の現在の値で更新します次にそのビューの一時的なコピーの「body」計算プロパティにアクセスしそれから返される値を属性の更新値として保存しますビューの本体がTextビューを返したため SwiftUIはテキストの表示に必要な属性を設定します
テキストビューは環境に依存する属性を作成しますこれは前景色やフォントなど現在のデフォルトのスタイルにアクセスしてレンダリングされるテキストの外観を決定するためですこの属性はビュー本体への依存関係を追加して返されたText構造体からレンダリングする文字列にアクセスします最後に Textはもう1つ属性を作成しますスタイルテキストに基づいてレンダリングする内容を説明する属性です
次に状態変数を変更すると何が起こるかについて説明します状態変数を変更すると SwiftUIはビューをただちに更新するのではなく新しいトランザクションを作成しますトランザクションは次のフレームまでに行う必要のある SwiftUIビュー階層に対する変更を表します
このトランザクションは状態変数のシグナル属性を期限切れとしてマークします次のフレームに向けた更新の準備ができると SwiftUIはトランザクションを実行しスケジュールされた更新を適用します属性が期限切れとしてマークされたので
SwiftUIはこの期限切れとなった属性に依存する一連の属性をたどりそれぞれをフラグの設定によって期限切れとマークしますフラグの設定は速やかに実行され追加の作業はまだ行われませんその他のトランザクションの実行が済むと SwiftUIはこのフレームで画面に描画すべき内容を特定する必要がありますがその情報は期限切れとマークされているためアクセスできません
SwiftUIは描画内容を決定するためにこの情報のすべての依存関係を更新していきます
更新はStateシグナルなど期限切れの依存関係がないものから開始されますこれでビュー本体の属性の更新準備が整いました再実行され更新された文字列によって新しいText構造体の値が生成されますこれは既存の Apply styling属性に渡され描画すべき内容を特定するために必要な属性がすべて更新されるまで更新が続行されますこれでSwiftUIは「画面に何を描画すべきか」という疑問に答えることができます
「なぜビュー本体が実行されたのか」と考えるときの真の問題は「何がビュー本体を期限切れとマークしたのか」です他のビューなどの依存関係によってビュー本体がいつ期限切れとマークされるかは特にそれらのビューが自身のものであれば制御可能ですただし SwiftUIはビューを表示するために追加の作業も行いますこの作業は必須で通常は避けられませんがいつ行われるのかを理解しておくことは有益ですビュー更新の原因と結果の両方に関する情報が明らかになることは新しいSwiftUI Instrumentの大きな特長です原因と結果グラフにはそういった原因と結果の関係がすべて記録されこのようなグラフで表示されます
まず今調査しているビュー本体の更新を確認します更新はノードとして表示されビュー本体の更新であることを示すアイコンとそれに対応するビュータイプを示すタイトルが表示されます
そのノードに対して状態の変更を表すノードから矢印が出ています矢印に「Update」とあるのはビューの更新を生じさせたのが状態の変更だからですまた端に「Creation」というラベルがあればそれはビューを最初にビュー階層に表示させたものです
状態の変更ノードのタイトルは状態変数の名前とそれが関連付けられているビューのタイプを示しています状態の変更を選択すると値が更新された場所のバックトレースが表示されます
続いて原因と結果グラフの左側を見ると状態の変更がボタンのタップなどジェスチャーによって生じたことがわかります
Landmarksアプリの原因グラフから何がわかるでしょうか原因と結果グラフを確認してビュー本体の余計な更新が発生した理由を解明しましょう
これが原因と結果グラフのビューです LandmarkListItemView.bodyのノードが選択されていますグラフの青いノードが表しているのは私自身のコードの一部かまたはアプリの操作中に私が実行したアクションですグラフでは原因と結果の連鎖が左から右に進んでいます
「Gesture」ノードはお気に入りボタンのタップを表しています
タップによってお気に入りのランドマークの配列が更新され
それにより LandmarkListItemViewの本体が何度も更新されました予想よりもはるかに多い回数です
1つのお気に入りボタンのタップによって私がタップしたものだけでなく画面上の多数のアイテムビューが更新されているようですコードに戻って何が起こっているのかを突き止めましょう
LandmarkListItemViewに戻ります
modelData.isFavoriteを呼び出しランドマークを渡すことでランドマークがお気に入りになっているかどうかを確認します ModelDataは最上位のモデルオブジェクトで @Observableマクロを使用しますそれによりプロパティの変更に応じてビューが更新されます commandキーを押しながらisFavoriteをクリックしこの関数に移動します
ここでfavoritesCollection.landmarks 配列にアクセスしこのランドマークがお気に入りか確認しますそうすると @Observableが各アイテムビューとお気に入りの配列全体との間に依存関係を確立しますそのためお気に入りを配列に追加するたびに配列が変更されるので各アイテムビューの本体が実行されますこの仕組みを説明します
こちらは3つのLandmarkListItemViewsですそしてこちらはfavoritesCollectionを持つ ModelDataクラスでこれがお気に入りのランドマークを追跡します今はランドマーク2だけがお気に入りです� ModelDataクラスには isFavorite関数があり各LandmarkListItemViewはこの関数を呼び出してアイコンをハイライトするかどうかを決定します
isFavorite関数はコレクションにランドマークが含まれているかどうかをチェックしビューは各自のボタンをレンダリングします各ビューは間接的ですがお気に入りの配列にアクセスしたため @Observableマクロはそれぞれのビューについてお気に入りの配列全体への依存関係を作成しました
では新しいお気に入りを追加するため他のビューのお気に入りボタンをタップするとどうなるでしょうかビューがtoggleFavoriteを呼び出して新しいランドマークがお気に入りに追加されますすべてのLandmarkListItemViewsには favoritesCollectionへの依存関係があるためすべてのビューが期限切れとマークされそれらの本体は再実行されます
私が変更したのは 3のビューだけなのでこれは最適な動作ではありません必要なのはビューのデータ依存関係をより細分化してアプリのデータが変更されたときに必要なビュー本体だけが更新されるようにすることです
少し見直してみましょう各ビューにはお気に入りであるかどうかのステータスを持ったランドマークがあります
このステータスを追跡するためにビューのObservable ビューモデルを作成しますこのモデルにはお気に入りステータスを追跡するisFavoriteプロパティがあり各ビューは独自のビューモデルを持ちます
ビューモデルをModelDataクラスに格納できるようになりました各ビューは自身のモデルを取得し必要に応じてお気に入りの状態を切り替えられます各ビューはお気に入りの配列全体に依存するのではなく各自のランドマークのビューモデルのみに直接依存しますお気に入りを追加してみましょうボタンをタップすると ToggleFavoriteが呼び出されビュー1のモデルが更新されますビュー1は自身のビューモデルだけに依存しているためこのビューのみ本体が再実行されますこれらの変更がLandmarksにもたらした結果を見てみましょう
こちらは新しいビューモデルの実装後に記録したトレースですサブトラックを再度クリックしタイムラインの前と同じ部分を選択します
詳細ペインでプロセスと
Landmarksモジュールを展開します
更新が2つだけになっています変更したお気に入りは2つなので適切でしょう念のためグラフも確認しましょうビュー名にカーソルを合わせて矢印をクリックしを選択します
またグラフが表示されます
@Observableノードからビュー本体への矢印が示す更新は 2つのみで各ボタンに1つずつになっています各アイテムビューがお気に入りの配列全体に依存していたのを密接に結び付いたビューモデルに置き換えることでビュー本体の無駄な更新が大幅に減りましたこれでアプリはスムーズに動作するでしょうこの例ではビュー本体の更新の原因が限定的なものだったためグラフは比較的小型でしたしかし原因がより顕著な場合はグラフがもっと大きくなりますそれが起こり得る状況の1つがビューが環境から読み取るときです Jed 例を示してもらえませんか了解ですまず環境の仕組みについて説明します環境の値はEnvironmentValues 構造体に格納されますこれは値型であり辞書に似ていますこれらの各ビューは環境プロパティラッパーを使用して環境にアクセスするため EnvironmentValues構造体全体に依存しています環境内の値が更新されると環境への依存関係を持つ各ビューには本体を実行する必要があると通知されますすると各ビューは読み取り中の値が変更されたかどうかを確認します値が変更された場合はビュー本体を再実行する必要があります変更がなかった場合ビューはすでに最新の状態のため SwiftUIはビュー本体の実行をスキップできます原因と結果グラフでこれらの更新がどのようになるか見てみましょう
環境の更新を表すグラフには主に2種類のノードがあります External Environmentの更新には SwiftUIの外部から更新されるカラースキームなどアプリレベルの更新があります EnvironmentWriterの更新は SwiftUI内で起こる環境内の値の変更を表しますこのカテゴリに当てはまるのは .environment修飾子を使用してアプリ内で行う更新です例えばデバイスがダークモードに切り替えられてカラースキームの環境値が更新された場合これらのビューの原因と結果グラフはどのようになるでしょうかグラフにはView1の「External Environment」のノードが表示されますカラースキームはシステムレベルの環境の更新だからですグラフには View1の本体が実行されたことを示すノードも表示されます View2も環境を読み取るため View2にも原因としてExternal Environmentの更新が示されていますただしView2はカラースキーム値を読み取らないため本体は実行されませんグラフでは本体が実行されなかったビューの更新は淡色表示のアイコンで表されますこの場合これら2つの外部環境ノードは同じ更新を表します同じ更新のいずれかのノードにカーソルを合わせるかクリックするとわかりやすいようにどちらも同時に強調表示されます両方のビューの更新がグラフに表示されるのは環境の更新の結果としてビュー本体を実行する必要がない場合でもビューに関連する値の更新をチェックするためにコストがかかるからです環境から読み取りを行うビューがアプリに多数ある場合かかる時間はすぐ長くなりますそのため環境にはジオメトリ値やタイマーなど頻繁に更新される値を格納しないことが重要です原因と結果グラフの説明は以上ですこのグラフはアプリ内のデータの流れを簡単に視覚化してビューに無駄な更新を行わせないようにするために役立ちますこのセッションでは SwiftUIアプリで優れたパフォーマンスを実現するためのベストプラクティスを説明しましたビュー本体を高速に保つことが重要ですそれにより SwiftUIが画面にUIを表示する十分な時間を得られ遅延をなくせますビュー本体の不要な更新は膨れ上がる可能性があるので必要な場合のみビューが更新されるようデータフローを設計し頻繁に変更される依存関係には特に注意しましょうまた開発中の早い段階で頻繁に Instrumentsを使用しアプリのパフォーマンスを分析するようにしてください今日はたくさんのことを説明しましたが最も重要なポイントは1つです SwiftUIの高いパフォーマンスを確保するためビュー本体の更新はすばやく必要な時にのみ行うようにしましょう開発過程ではSwiftUI Instrumentを使ってアプリのパフォーマンスを確認してください
本日は SwiftUI Instrumentによるアプリのプロファイリングについて説明しましたが学ぶべきことは他にもありますビデオの説明にリンクされているドキュメントを確認してこのInstrumentの他の機能について学習してくださいまたアプリのパフォーマンスの分析と向上についてのその他の動画や参考資料へのリンクも追加しておきましたご視聴ありがとうございましたぜひ新しいSwiftUI Instrumentを使用してアプリのパフォーマンスを最大限に高めてください

import SwiftUI
import CoreLocation

/// A view that shows a single landmark in a list.
struct LandmarkListItemView: View {
    @Environment(ModelData.self) private var modelData

    let landmark: Landmark

    var body: some View {
        Image(landmark.thumbnailImageName)
            .resizable()
            .aspectRatio(contentMode: .fill)
            .frame(minWidth: 0, maxWidth: .infinity, minHeight: 0, maxHeight: .infinity)
            .overlay { ... }
            .clipped()
            .cornerRadius(Constants.cornerRadius)
            .overlay(alignment: .bottom) {
                VStack(spacing: 6) {
                    Text(landmark.name)
                        .font(.title3).fontWeight(.semibold)
                        .multilineTextAlignment(.center)
                        .foregroundColor(.white)

                    if let distance {
                        Text(distance)
                            .font(.callout)
                            .foregroundStyle(.white.opacity(0.9))
                            .padding(.bottom)
                    }
                }
            }
            .contextMenu { ... }
    }

    private var distance: String? {
        guard let currentLocation = modelData.locationFinder.currentLocation else { return nil }
        let distance = currentLocation.distance(from: landmark.clLocation)

        let numberFormatter = NumberFormatter()
        numberFormatter.numberStyle = .decimal
        numberFormatter.maximumFractionDigits = 0

        let formatter = MeasurementFormatter()
        formatter.locale = Locale.current
        formatter.unitStyle = .medium
        formatter.unitOptions = .naturalScale
        formatter.numberFormatter = numberFormatter
        return formatter.string(from: Measurement(value: distance, unit: UnitLength.meters))
    }
}

12:13 - LocationFinder Class with Cached Distance Strings

import CoreLocation

/// A class the app uses to find the current location.
@Observable
class LocationFinder: NSObject {
    var currentLocation: CLLocation?
    private let currentLocationManager: CLLocationManager = CLLocationManager()

    private let formatter: MeasurementFormatter

    override init() {
        // Format the numeric distance
        let numberFormatter = NumberFormatter()
        numberFormatter.numberStyle = .decimal
        numberFormatter.maximumFractionDigits = 0

        // Format the measurement based on the current locale
        let formatter = MeasurementFormatter()
        formatter.locale = Locale.current
        formatter.unitStyle = .medium
        formatter.unitOptions = .naturalScale
        formatter.numberFormatter = numberFormatter
        self.formatter = formatter

        super.init()
        
        currentLocationManager.desiredAccuracy = kCLLocationAccuracyKilometer
        currentLocationManager.delegate = self
    }

    // MARK: - Landmark Distance

    var landmarks: [Landmark] = [] {
        didSet {
            updateDistances()
        }
    }

    private var distanceCache: [Landmark.ID: String] = [:]

    private func updateDistances() {
        guard let currentLocation else { return }

        // Populate the cache with each formatted distance string
        self.distanceCache = landmarks.reduce(into: [:]) { result, landmark in
            let distance = self.formatter.string(
                from: Measurement(
                    value: currentLocation.distance(from: landmark.clLocation),
                    unit: UnitLength.meters
                )
            )
            result[landmark.id] = distance
        }
    }

    // Call this function from the view to access the cached value
    func distance(from landmark: Landmark) -> String? {
        distanceCache[landmark.id]
    }
}

extension LocationFinder: CLLocationManagerDelegate {
    func locationManagerDidChangeAuthorization(_ manager: CLLocationManager) {
        switch currentLocationManager.authorizationStatus {
        case .authorizedWhenInUse, .authorizedAlways:
            currentLocationManager.requestLocation()
        case .notDetermined:
            currentLocationManager.requestWhenInUseAuthorization()
        default:
            currentLocationManager.stopUpdatingLocation()
        }
    }
    
    func locationManager(_ manager: CLLocationManager, didUpdateLocations locations: [CLLocation]) {
        print("Found a location.")
        currentLocation = locations.last
        // Update the distance strings when the location changes
        updateDistances() 
    }
    
    func locationManager(_ manager: CLLocationManager, didFailWithError error: any Error) {
        print("Received an error while trying to find a location: \(error.localizedDescription).")
        currentLocationManager.stopUpdatingLocation()
    }
}

16:51 - LandmarkListItemView with Favorite Button

import SwiftUI
import CoreLocation

/// A view that shows a single landmark in a list.
struct LandmarkListItemView: View {
    @Environment(ModelData.self) private var modelData

    let landmark: Landmark

    var body: some View {
        Image(landmark.thumbnailImageName)
            .resizable()
            .aspectRatio(contentMode: .fill)
            .frame(minWidth: 0, maxWidth: .infinity, minHeight: 0, maxHeight: .infinity)
            .overlay { ... }
            .clipped()
            .cornerRadius(Constants.cornerRadius)
            .overlay(alignment: .bottom) { ... }
            .contextMenu { ... }
            .overlay(alignment: .topTrailing) {
                let isFavorite = modelData.isFavorite(landmark)
                Button {
                    modelData.toggleFavorite(landmark)
                } label: {
                    Label {
                        Text(isFavorite ? "Remove Favorite" : "Add Favorite")
                    } icon: {
                        Image(systemName: "heart")
                            .symbolVariant(isFavorite ? .fill : .none)
                            .contentTransition(.symbolEffect)
                            .font(.title)
                            .foregroundStyle(.background)
                            .shadow(color: .primary.opacity(0.25), radius: 2, x: 0, y: 0)
                    }
                }
                .labelStyle(.iconOnly)
                .padding()
            }
    }
}

17:20 - ModelData Class

/// A structure that defines a collection of landmarks.
@Observable
class LandmarkCollection: Identifiable {
    // ...
    var landmarks: [Landmark] = []
    // ...
}

/// A class the app uses to store and manage model data.
@Observable @MainActor
class ModelData {
    // ...
    var favoritesCollection: LandmarkCollection!
    // ...

    func isFavorite(_ landmark: Landmark) -> Bool {
        var isFavorite: Bool = false
        
        if favoritesCollection.landmarks.firstIndex(of: landmark) != nil {
            isFavorite = true
        }
        
        return isFavorite
    }

    func toggleFavorite(_ landmark: Landmark) {
        if isFavorite(landmark) {
            removeFavorite(landmark)
        } else {
            addFavorite(landmark)
        }
    }

    func addFavorite(_ landmark: Landmark) {
        favoritesCollection.landmarks.append(landmark)
    }

    func removeFavorite(_ landmark: Landmark) {
        if let landmarkIndex = favoritesCollection.landmarks.firstIndex(of: landmark) {
            favoritesCollection.landmarks.remove(at: landmarkIndex)
        }
    }
    // ...
}

20:50 - OnOffView

struct OnOffView: View {
    @State private var isOn = true
    var body: some View {
        Text(isOn ? "On" : "Off")
    }
}

29:21 - Favorites View Model Class

@Observable class ViewModel {
    var isFavorite: Bool
    
    init(isFavorite: Bool = false) {
        self.isFavorite = isFavorite
    }
}

29:21 - ModelData Class with New ViewModel

@Observable @MainActor
class ModelData {
    // ...
    var favoritesCollection: LandmarkCollection!
    // ...

    @Observable class ViewModel {
        var isFavorite: Bool
        init(isFavorite: Bool = false) {
            self.isFavorite = isFavorite
        }
    }

    // Don't observe this property because we only need to react to changes
    // to each view model individually, rather than the whole dictionary
    @ObservationIgnored private var viewModels: [Landmark.ID: ViewModel] = [:]

    private func viewModel(for landmark: Landmark) -> ViewModel {
        // Create a new view model for a landmark on first access
        if viewModels[landmark.id] == nil {
            viewModels[landmark.id] = ViewModel()
        }
        return viewModels[landmark.id]!
    }

    func isFavorite(_ landmark: Landmark) -> Bool {
        // When a SwiftUI view, such as LandmarkListItemView, calls
        // `isFavorite` from its body, accessing `isFavorite` on the 
        // view model here establishes a direct dependency between
        // the view and the view model
        viewModel(for: landmark).isFavorite
    }

    func toggleFavorite(_ landmark: Landmark) {
        if isFavorite(landmark) {
            removeFavorite(landmark)
        } else {
            addFavorite(landmark)
        }
    }

    func addFavorite(_ landmark: Landmark) {
        favoritesCollection.landmarks.append(landmark)
        viewModel(for: landmark).isFavorite = true
    }

    func removeFavorite(_ landmark: Landmark) {
        if let landmarkIndex = favoritesCollection.landmarks.firstIndex(of: landmark) {
            favoritesCollection.landmarks.remove(at: landmarkIndex)
        }
        viewModel(for: landmark).isFavorite = false
    }
    // ...
}

31:34 - Cause and effect: EnvironmentValues

struct View1: View {
    @Environment(\.colorScheme)
    private var colorScheme

    var body: some View {
        Text(colorScheme == .dark
                ? "Dark Mode"
                : "Light Mode")
    }
}

struct View2: View {
    @Environment(\.counter) private var counter

    var body: some View {
        Text("\(counter)")
    }
}

関連する章

リソース

関連ビデオ

WWDC25

WWDC23

WWDC22

WWDC21

Tech Talks