忙しい人向けの Data Essentials in SwiftUI: Part 2 - #WWDC20
パフォーマンス
SwiftUI は View の Identity とライフタイムを管理する。View は軽量かつ安価である必要がある。
SwiftUI の全体のライフサイクルはこのようになる。イベントが Source of Truth を変更させ、それを契機に View がコピーされ再レンダリングされる。
このサイクルのどこかに遅い処理があると、パフォーマンスに影響が出る。
View の初期化は軽量に保ち、body は純粋な関数にし、body プロパティがいつ呼び出されるか想定しないこと。
以下は、ReadingList ビューが生成される度に、ReadingListStore がヒープに確保されるため遅い。オブジェクトは毎回リセットされるためバグの原因にもなる。
解決策は @StateObject を使うこと。
Source of Truth を変更するものとして、UI 上のアクションの他、タイマーや通知もあり、これらは「イベントソース」と呼ばれる。
新しいイベントソースが追加された。クロージャを受け取るものもあるが、その処理はメインスレッドで実行されることに注意（必要ならバックグラウンドキューの利用も考慮する）。
ライフタイム
View はデータのライフタイムを管理する便利な道具。このセッションで登場した Property wrapper はすべて View 上で動作する。
シーン（Scene）は独立した状態を保持するために、状態はルートの View で宣言するとよい。
App に @State 宣言することで、アプリ全体の Source of Truth となる。
アプリが強制終了から復帰した場合のステートの復元として、SceneStorage と AppStorage が追加された。
SceneStorage はシーン毎に保存されるステート。
例えば、選択状態などを保存・復元するのに適している。
AppStorage はアプリのスコープで動作し、値は UserDefaults に保存される。
アプリの設定値などを保存するのに適している。
コードはこのようになる。
最も柔軟なツールとなるのが ObservableObject。このセッションで紹介したツールは、それぞれ適切に使い分ける必要がある。
免責
・本記事は公開情報のみに基づいて作成されています。
・要約（意訳）のみなので、詳細はセッション動画をご確認ください。
関連記事
役に立った記事などありましたらサポート頂けると嬉しいです。