空間コンピューティングのためのアプリのパワーと性能の最適化

♪ ♪ ♪ どうも Royです Performanceチームのエンジニアです 今日は空間コンピューティングのため アプリをどう最適化するか学びます まずこのプラットフォームの 性能と電力における ユニークな特徴を見てみます そして性能プランの構築について アプリのprofileから始めます 最後にこのプラットフォームでの性能問題を 最適化する最善方法をいろいろと見てみます 空間コンピューティングにおいて 電力と性能は何が違うのでしょう？ まず 画面のコンテンツは アプリの更新に関わらず常に更新されます 体や手や目を動かせばいつでも コンテンツが更新されねばなりません つまりシステムは常に各フレームを レンダリングしているのです またプラットフォームは すべてのアプリを通し 映像を作り対話するため 常に空間アルゴリズムを実行し 同時に幾つものアプリを 動作することができます 人々はあなたのアプリを ほかのアプリと使用します マルチタスクと更なる システム作業をこなすため アプリのリソース活用を できる限り最適化しましょう 最高のユーザー体験には あなたのアプリの性能が必須なのです 人々はアプリが入力に即反応し スムーズな視覚更新で 没入感と安楽感が得られることを求めます では性能問題に関する アプリのプロファイルと 分析について話しましょう みなさんは既にほかの Appleプラットフォームから 性能メトリックをご存知でしょう どのプラットフォームでも 人々は起動が速く ディスクの摩耗を避け 電池を消費しないアプリを求めます また非効率なメモリ使用で 終了しないアプリを求めます 空間コンピューティングではこれらが 新しい意味になります 例えば電力です ユーザーは電池寿命ではなく 電力を求めます　それは熱圧のためです 最高の性能を維持するため アプリはシステム電力の使用を最適化し 熱圧の発生を妨げねばなりません フリーズもまたその例です これはアプリのメインスレッドが 作業中に一時停止することです しかしこのプラットフォームでは ほんの一瞬の停止でも 反応度に支障が出ます レンダリングはどうでしょう ほかのプラットフォームでは スムーズなインターフェイスや 3D動画のために レンダリング性能を最適化しています しかしここではレンダリング性能は システムが常にレンダリングしているため 静的コンテンツにも必須です すべてのプラットフォームでメトリックの プロファイルツールを提供しています 今日は空間コンピューティングアプリでの 性能問題発見についてカバーします Appleプラットフォームにおける メトリックの最適化については 「Ultimate Application Performance Survival Guide」をご覧ください アプリの最適化には InstrumentsやXcode Gaugesを使い 開発途中にプロファイルします いざアプリがリリースされれば さらなる最適化のため 現場からデータを収集します 開発途中のプロファイルについて 話しましょう RealityKit Traceは Instrumentsの新しいテンプレートで 空間コンピューティングアプリの 性能と電力をプロファイルします アプリのレンダリング性能が乏しかったり システム電力使用が増加した時などを 確認する素晴らしいツールです ほかにもテンプレートがたくさんあります このテンプレートについて さらに学びたければ 「Meet RealityKit Trace」をご覧ください アプリの性能と電力は どうアプリと対話するかによります Simulatorは実際のデバイスと 同じ作業を行わないため 性能データは正確ではないかもしれません デバイスでプロファイルすべきです オーディオやビデオの再生や FaceTimeやPersonasなど アプリでの様々なインタラクションで プロファイルします 数分にわたっての使用での よい性能と低システム電力使用を 確認してください 最後にほかのアプリが動作中で リソースを使用する間も プロファイルします もしiPadやiPhoneアプリを持ち込むなら 更なる最適化の必要性の確認のため デバイスでプロファイルしてください

開発後 人々は様々な状況下で アプリを使用することでしょう 現場からのデータは実際に人々が 出くわす問題を見つけるのに最適の方法です アプリがベータかリリースされた時 MetricKitでユーザーから 診断レポートを受け取れます Xcode Organizerは 電力問題の発見に役立つ エネルギー診断など ユーザー承諾のデバイスからの 統合性能データを提供します 収集するデータのすべてが 障害の発見に役立ち アプリの性能向上を優先できます では空間コンピューティングアプリの 最適化についてです 性能問題はいろんなところから発生します 今日はいくつかの重要エリアの 最適化の方法を カバーします　それらはレンダリング ユーザー入力とARKit オーディオとビデオ再生にSharePlay そしてシステムプレッシャーによるアプリ終了です 素晴らしいユーザー体験において レンダリング性能は 最優先事項の一つです 見てみましょう このプラットフォームでは レンダリングはアプリから始まります アプリはコンテンツを 更新する責任があります すべてのAppleプラットフォーム同様 アプリのインターフェイスは メインスレッドで敏速に 更新されねばなりません ほかのアプリと 3D空間でレンダリングされるため 更新はsystem render serverに送られます Render serverは常時動作し アプリやユーザー入力 そして空間とその環境から 更新を処理します これらの更新と新しいフレームにレンダリングし Compositorに送り出します Compositorは常にレンダリングします そしてリフレッシュレートに基づき 新しいフレームをディスプレイに送ります これで心地よい体験を提供できます リフレッシュレートは通常 毎秒90フレームですがそれ以上も可能です Compositorが常時ディスプレイを更新する間 優れたユーザー体験にはアプリからの迅速な 視覚更新が必要です レンダリングに時間がかかるコンテンツや 更新があればrender serverは 最適レンダリングレイテンシの 締切を過ぎてしまいます つまりフレームYの代わりに フレームY+1で compositorに届いてしまうのです これによりディスプレイの視覚更新が遅れ アプリの反応が鈍く感じられます 特にひどいレンダリング停止の場合 アプリの終了につながります アプリの作成がSwiftUIかUIKit RealityKitかMetalのいずれであれ フレーム落ちを減らし render serverで作業を済ませるよう コンテンツを最適化し更新すべきです ではSwiftUIとUIKitの 使用最適化についてです このプラットフォームは アプリ更新がなくても 静的インターフェイスコンテンツの レンダリングをシステムは行います このレンダリング作業は オーバードローで増加します オーバードローは仮想コンテンツの前に 半透明コンテンツがあると発生します GPUは両方のコンテンツをレンダリングしますが 半透明コンテンツが不透明なら GPUはその後ろのコンテンツを レンダリングする必要はありません もしZオフセットの 重なるインターフェイスビューがあれば 半透明を足すのは避けましょう またアプリのインターフェイスが 画面のピクセルを使えば使うほど ウインドウのレンダリング作業が増えます デフォルトサイズを小さくしましょう 通常render serverの インターフェイスリドローは アプリ更新で実行されますが このプラットフォームでは core animation layersの dynamic content scalingでも実行されます この習性によりテキストや ベクトル基盤の コンテンツの解像度は 鮮明な画像を可能にするため ユーザーが見ている箇所によって変わります これによりアプリの更新がなくても 更に高スケールで より頻繁なコンテンツの リドローにつながる可能性もあります SwiftUIとUIKitは これがデフォルトでオンですが custom Core Animationや Core Graphicsレンダリングを行うアプリは オプトインできます これらの視覚的利点や トレードオフは 「Explore rendering for spatial computing」をご覧ください これらのリドローによる損失は offscreen render passesに影響され shadowsやblurやmaskingなど 視覚効果によって引き起こされます これらの効果をアプリから減らし システムがレンダリングしやすくしましょう リドローを最小化するため 不必要なview updatesは 可能な限り避けましょう 例えばSwiftUIでは@Observableを使います @Observableは細かい変更トラッキングで 不要なレイアウト更新を削減します 次にRealityKitでの3Dレンダリングの 最適化について話しましょう SwiftUIは空間コンピューティングのための RealityViewを追加しました SwiftUI階層内でRealityKit 3Dシーンを ネイティブに表示することができます これらのRealityKit機能のために 3Dシーンを最適化することで アプリはこのプラットフォームに 適するはずです これらの3Dシーンでは そこに含まれるアセットの複雑さにより 各フレームの render server作業量が著しく増加します ではこれらのアセットの 最適化から始めましょう Reality Composer Proはアセットで RealityKitシーンを作成するのに役立ちます Mesh renderingから particlesやanimations physicsにaudio workなど このツールは シーン全体における統計を提供することで 性能のインパクトを理解することできます これらの統計を調べる上で 通常低い数値は 作業量が少なく レンダリング性能の向上を意味します このことは 「Create 3D models for Quick Look spatial experiences」で 3Dアセットの視覚的及び 電力使用におけるベストプラクティスを 学ぶことができます メッシュレンダリングは特に 3Dレンダリングのコア部です 複雑なメッシュやmaterialsはすぐに 性能の障害となりえます メッシュアセットのジオメトリの 最適化が必要です Materialの共有箇所を結合し メッシュのパーツを減らします 三角形と頂点の数が多い メッシュジオメトリも 負担が大きくなります 必要なら少ない数のアセットを 使用しましょう 3Dメッシュのオーバードローによる影響を 最小化しましょう インターフェイスコンテンツ同様 透明度の使用を少なくします Reality Composer Proの Physically Based materialは 環境照明があり最適化されており 最小限の透明性メッシュが最適ですが 半透明や大きいコンテンツには unlit surfaceのカスタムmaterialの使用を お勧めします 組み込みのlighting texturesか 簡単なvisualsを使用しましょう これにより複雑な計算を避け 障害を避けることができます RealityKitでのビルドや materialsについては この2つのセッションをご覧ください 最適化されたコンテンツの使用は レンダリングに最適です しかしRealityKitで更に アプリを最適化することができます アプリがRealityKitコンテンツを更新する時 更新はrender serverに送られ それらを応用しレンダリングします しかし短時間に多くの更新があると render serverに障害をもたらします 例えば あなたのアプリが RealityKit entitiesを素早く作り 破壊していたとします 複雑なアニメーションが多かったり SwiftUI viewsの更新が多かったり 1つのフレームに大量のアセットを 読み込んでいるかもしれません あらかじめentitiesを作成しておき 必要に応じて隠したり見せたりします シーン階層に応じて足したり取り除いたり isEnabled flagを使用したりします メッシュentity階層を平らにして 更新されるentitiesを減らします コードベースアニメーションには 更新率を減らすか 更新するアニメーションentitiesの数を 減らしましょう またRealityKit entitiesの更新時 誤って過剰なSwiftUIリドローを 起こさないようにします 添付を使う時はSwiftUIコンテンツを 最適化するように そのレンダリングも 最適化するようにしましょう 複雑なアセットの読み込みも レンダリング更新に負担をもたらします 複雑なアセットはまた アプリの起動やコンテンツの読み込みに 影響を及ぼします Asynchronous-loading APIsで メインスレッドの妨害をさけ アセットをあらかじめ 読み込ませておきましょう 同じアセットを使うentitiesは そのアセットを共有すれば 読み込みが一度で済みます 読み込み時間とメモリ使用に最適化された Reality Composer Proのexported filesを 使用しましょう またtexture compressionが得られます アセットのサイズの減少で 読み込み時間が速まりますが Reality Composer Pro filesでは既に texture compressionがなされるため 実行する必要はないかもしれません 最後にRealityKitでの没入型体験について 話しましょう アプリが専用のFull Spaceに 移動を求めると それが唯一前景で 作動している体験になります ポータルの使用やフル没入型体験になると システムはまた 環境の一部及び全部を隠します アプリはRealityKitコンテンツで その空間を埋める環境を作り出せます Shared SpaceやFull Spaceのシーン以上に 没入型コンテンツはディスプレイに 多くのピクセルでレンダリングされます つまりそのコンテンツのレンダリングが より多くGPUで行われます GPU電力使用のために コンテンツを最適化しましょう まず電力使用の最適化のため Reality Composer Proで unlit surfaceの custom materialを使用します Baked lighting texturesを使用したり time-based animationsで dynamic lightingの感じを得られます システムパワーとレンダリング性能のため materialをプロファイルするのです またフル没入型体験を Metalで作成できます Metalで3Dエンジンや体験を作っているなら そこで最適化できることを話しましょう MetalをCompositorServices フレームワークと使用すると render serverを避けrendered surfaceを 直接compositorに送り出せます 「Discover Metal for immersive apps」で この詳細を学ぶことができます CompositorServicesを使用する時 更新毎compositorが 新しいフレームを受け取るよう Metal frame submissionsを整調します 各フレーム毎に新しいfoviation mapと post predictionをクエリしてください GPU作業をエンコードするため 使用し始める直前に この入力データをクエリします これら3項目を実行することで ユーザーの動きと入力に呼応する 敏感な仮想コンテンツが保証されます もしアプリが新フレームの提示に 時間がかかりすぎると システムが終了させます フレームの長い停止を避けましょう アプリを動作している間 Metal System Trace Instruments templateで GPU性能をプロファイルしましょう Reality Composer ProでMetalアプリや custom materialsから 時間のかかるfragmentと vertex shaderを実行すると システムレンダリング時間に影響があります fragmentとvertexの時間削減のため ALU instructionsと shadersのtexture accessesを減少させます Metalでは可能な限り compute shadersを使用します GPU性能の最適化については 以下のセッションをご覧ください アプリをインターフェイスと 3Dレンダリング性能のために 最適化することは ユーザー体験全体のためになります 次は入力性能についてです このプラットフォームでは入力に 目と手と声とハードウェアを使用できます 入力のアプリ更新は メインスレッドで処理されます これに時間がかかれば アプリが遅く鈍感に感じられます メインスレッドの入力更新はディスプレイの リフレッシュレイトに基づく期限より 早くなくてはなりません このハードウェアは通常 90Hz以上のリフレッシュレイトです 90Hzリフレッシュレイトは 最適レイテンシの8ミリ秒以下に 入力更新を抑えます 空間コンテンツと対話する時 ユーザーがどのインターフェイスや 3D objectsと対話を試みているか システムがhit testingを行います RealityKitコンテンツには physics collidersを 対話のために足します これらのcollidersを足す時は dynamic collidersではなく 負荷が少ないstatic collidersを 可能な限り使用してください アプリでの余分なhit testingを減らすため 対話コンテンツの重複を避けてください 次はARKitです このプラットフォームでは各アプリを通し 映像と対話を作り出すため ARKitアルゴリズムが 常に動作しています アプリがARKitデータをどう使い どう仮想コンテンツに 据えつくかによりシステム電力と 視覚的円滑さに影響を与えます 例えばアプリはARKitやRealityKitを使って ユーザーの環境や頭や手に アンカーコンテンツを 取り付けることができます 各アンカーがシステムに作業を追加します コンテンツをアンカーする時 ユーザーの空間内で アンカーが常に追跡されるべきか 考慮してください RealityKitでAnchorComponentを使う時 once tracking modeで 継続的追跡による負荷を避けましょう 持続的及び一時的アンカーの数を 最小限に抑えましょう 特に持続的アンカーは 各アプリか追加されるため あなたのアプリから 追加しすぎないようにしましょう ARKitデータを使用する時 更なる最適化が可能です アプリのコンテンツに 古すぎるARKitデータを適用すると アプリの映像は入力とズレて 見えるかもしれません 使用直前にARKitデータをクエリし 即座に更新するよう適用します Post predictionsは計算に負荷がかかります 通常カスタムMetal レンダリングエンジンしか このデータを必要としません コンテンツをシーンに配置したいだけなら RealityKitが最適の選択です メッシュのscene understandingのための collision dataも負荷がかかります このデータを使用するなら アプリから不要になればオフにしましょう 次に空間コンピューティングにおける オーディオとビデオ再生です 空間オーディオが デフォルトとして使用されます オーディオ出力のためユーザーの位置や その環境及び音源などの情報を リアルタイムでシステムは処理します アプリが空間オーディオの処理を 起こしすぎると システムの電源使用で問題になるか オーディオ出力に遅れが生じます これらの問題が見られれば 空間オーディオの過剰処理削減に 3つの箇所に注目せねばなりません 音源の同時再生 動く音源の数 そしてサウンドステージのサイズです これらはいずれも計算量を 増加させる変数です ではビデオを見てみましょう Shared Spaceで同時に幾つも ビデオを再生できます 各ビデオにつきシステムはrender serverで デコードしレンダリングせねばなりません 最高のビデオ鑑賞のために レンダリングされたビデオフレームは 一貫した間隔で ディスプレイに表示されねばなりません レンダリングが時間内に完了するよう render serverにパワーと時間を与えるため ビデオ再生時 アプリは インターフェイスと3Dコンテンツの 更新を最小限にするべきです フレームレートも作業に影響します 最適の性能と電力のためにビデオは 24Hzか30Hzを使用するようにしましょう 最後にデバイスで再生及びレンダリングが必要な アプリからの同時ビデオの数を 極力減らすようにしましょう ビデオのプレゼン方法を選択する時 違った機能や性能のために どのように最適化したいか考えましょう 詳しくは 「Create a great spatial playback experience」を ご覧ください 次はSharePlayについてです このプラットフォームは 人々とのコラボや繋がりで まったく新しい体験を開きます 最高のSharePlayグループ体験を 作り出すために アプリが長時間にわたり最高の性能を 維持できるようにせねばなりません SharePlayにおける 最高の空間コンピューティング性能は 基本から始まります まずローカル性能のためアプリを プロファイル及び最適化します そしてSharePlay中のアプリの性能を調べ デバイスを通し同調化される 負荷の大きいレンダリング更新を避けます 最高の性能維持を妨げる熱圧を作り出す システム電力が必要にならぬよう 電力においてアプリを プロファイルしましょう このためにアプリのどの作業と機能が アプリのSharePlay体験に 必須なのかを考慮し 必要のないものはすべてオフにします 最後に熱圧及びメモリ負荷による アプリの終了を見てみましょう 人々はこのデバイスを 暑い場所で使用するかもしれません すべてのAppleプラットフォーム同様 デバイスを使用中に 低温と安楽さを維持するため システムが熱圧状況下での 計算資源を管理します 計算資源が低いことは アプリの性能に影響します システムは危機的な熱圧や レンダリング期限に遅れると アプリを終了させるかもしれません 熱圧下ではアプリの作業を減らし いい性能を維持したまま熱圧がそれ以上 上昇するのを避けます これは thermalStateDidChangeNotificationに サブスクライブして可能になります 熱圧が上がると それに応じてアプリのコンテンツや 更新を順応させます 熱圧下でアプリがどう性能するかは Xcodeでthermal inducersを使い デバイスの高熱状態を シミュレーションします 熱圧については 過去のセッション 「Designing for Adverse Network and Temperature Conditions」をご覧ください 次はメモリ負荷についてです デバイスにはシステムと 動作中のアプリの間で共有される 限られたメモリがあります デバイスがこのリミットに近付くと 活発に使用されていないアプリから システムはアプリを終了し始めます メモリを過度に使用するアプリも 使用中でも終了させられます これだけは避けたいものです アプリのメモリ使用量をできる限り減らせば これを避けることができます このプラットフォームではおそらく インターフェイスや3Dレンダリング オーディオ・ビデオ再生に 大部分のメモリを使用します アプリにインターフェイス コンテンツがあるなら オフスクリーン・レンダリングパスや ウインドウやメディアの数を最小化し レンダリング・メモリの割当てを 減らしましょう RealityKitの3Dメモリでは テクスチャーの解像度やメッシュや パーティクルのジオメトリサイザーが メモリ使用量に大きく影響します できる限り減らすようにしましょう オーディオ・ビデオの再生中 オーディオ・ビデオファイルからの メモリ使用量を評価しましょう 解像度やビットレート　フォーマットや 長さを変える時は ユーザー体験と性能をメモリ使用量と比べ トレードオフを考慮しましょう すべてのAppleプラットフォームにおける メモリ負荷の減少については これらをご覧ください このプラットフォームでは 性能が大きくユーザー体験に影響します 性能と電力問題の発見に 開発段階から活発に アプリをプロファイルしましょう 空間コンピューティングのために 重要なメトリックにおける 性能計画を立てましょう そしてレンダリングや電力など 今日話したエリアで 最適化を試みましょう 最後にMetricKitやXcode Organizerで 現場からの性能データを集めましょう このプラットフォームの みなさんのアプリと体験を 楽しみにしています ありがとうございました ♪