Closed2023/05/15にクローズ1

Unityパフォーマンスチューニングで簡単にできそうな部分まとめ＃１

Unity

eisuke

指標まとめ

パフォーマンスの目標をざっくり決める

に目指すべき指標が決まれば基準となる端末。

フレームレート(60フレーム)
メモリ(最大使用量１GB)
遷移時間（３秒以内）
熱（連続1時間で暑くならない）
バッテリー消費量（1時間でバッテリー消費２０％）
など

現状のパフォーマンス量を取得する

以下のような表を作りまとめる
ネイティブの検証ツールを使うのがおすすめ
動作保証端末を決める
品質設定の仕様を決める
- 品質設定の高、中、低を決める
- 端末の情報から品質設定を自動切り替えできるようにする
パフォーマンス情報を画面上に見れるようにする

チューニングフロー

計測し原因を求めること。推測はダメ
修正したら結果を比較すること。
どこかのパフォーマンスが良くなっていてもどこかが悪くなっている時もある。

メモリ調査方法

あるシーンでのメモリ使用量をメモする
違うシーンに遷移する
以上の動作を３〜５回ほど繰り返す

処理落ち原因の切り分け

瞬間的な処理落ち
定常的な処理落ち

以上の二つに分けるとする。

スパイクが瞬間的な処理落ち。
定常処理負荷が定常的な処理落ちにあたります。

瞬間的な負荷を調査する

GCによるスパイクでないか？
重い処理によるスパイクでないか？
- Instantiate 処理
- 大量のオブジェクト、あるいは階層が深いオブジェクトのアクティブ切り替え
- 画面のキャプチャ処理など

定常的な負荷を調査する

1 フレーム内での処理をいかに削減するかが重要
- 画面の解像度を下げた際に処理負荷が劇的に改善するかつ Profiler で計測した際に Gfx.WaitForPresent が存在する場合はGPUバウンドであると考えられる
  - GPUバウンド
    - Frame Debugger を利用して調査する
    - 解像度が適切か
      - UI 要素だけデバイスのフル解像度で描画されている
      - ポストエフェクト用の一時テクスチャの解像度が高いなど
    - 不要なオブジェクトがあるか
    - バッチングが適切か(描画対象をまとめて描画する事をバッチングと言う)
      - Static Batching
      - Dynamic Batching
      - GPU Instancing
      - SRP Batcher など
    - 個別に負荷をみる
      - 描画するオブジェクトが多すぎないか
      - 1 オブジェクトの頂点数が多すぎないか
      - シンプルな Shader に付け替えて処理負荷が改善するか
  - CPUバウンド
    - CPU (Profiler) を利用します。Deep Profile を利用して調査し、特定のアルゴリズムに大きな処理負荷がかかっていないか

イベントの実行順序

クラスと構造体を選ぶ基準について

構造体を検討すべき条件:
型のインスタンスが小さく、有効期間が短いことが多い場合
他のオブジェクトに埋め込まれることが多い場合
構造体を避ける条件: ただし、型が次のすべての特性を持つ場合を除く
- プリミティブ型（int、double など）と同様に、論理的に単一の値を表すとき
- インスタンスのサイズが 16 バイト未満である
- 不変（イミュータブル）である
- 頻繁にボックス化する必要がない

(Unity で頻繁に使用されている Vector4 や Quaternion など、16 バイト未
満ではありませんが構造体で定義されています。これらを効率よく扱う方法を確認し
た上で、コピーコストが増大しているようでしたら回避する方法を含めて選択し、場
合によっては自前で同等の機能を持った最適化版を作ることも検討してください。)

プロファイリングツール

Unity Profiler

ビルド前に行う作業は Development Build を有効にすることです。この設定が有
効化されることでプロファイラーと接続ができるようになります。

また、より詳細に計測を行う Deep Profile というオプションもあります。このオプ
ションを有効にすると、すべての関数コールの処理時間が記録されるため、ボトルネッ
クとなる関数の特定が容易にできます。欠点としては計測自体に非常に大きなオーバー
ヘッドを要するため、動作が重くなり、メモリも大量に消費します。そのため処理に
とても時間がかかっているように見えても、通常のプロファイルではそれほどでもな
いこともあるので注意してください。基本的には通常のプロファイルでは情報が足り
ない場合にのみ使用します。

テクスチャの設定

Read/Write
- 有効にした場合は GPU メモリだけでなくメインメモリにもコピーされるため、2 倍の消費量になってしまいます。そのため Texture.GetPixel や Texture.SetPixel といった API を使用せず Shader でしかアクセスしない場合、必ず無効
- ランタイムで生成したテクスチャは、リスト 4.1 で示すように makeNoLongerReadable を true に設定することで、メインメモリへのコピーを回避できます
Generate Mip Maps
- 有効にするとテクスチャのメモリ使用量が約 1.3 倍になる
- この設定は 3D 上のオブジェクトに対して行うことが一般的で、遠くのオブジェクトに対して、ジャギ軽減やテクスチャ転送量削減を目的に設定します。
- 2D スプライトやUI 画像に対しては基本的に不要なので、無効に
Aniso Level
- オブジェクトを浅い角度で描画した際に、テクスチャの見栄えをボケずに描画するための機能です。
- この機能は主に地面や床など遠くまで続いているオブジェクトに使用されます。
- Aniso Level 値が高いほどその恩恵を受けられますが、処理コストはかさみます。
- テクスチャをインポートするとデフォルトでは値が 1 になっています
圧縮設定
- テクスチャは特別な理由がない限り圧縮するべき
- 圧縮設定に関してはヒューマンエラーが起きないように TextureImporterを利用し自動化することを推奨

メッシュ設定

Read/Write Enabled
- デフォルトでは無効になっています
- ランタイム中、メッシュにアクセスする必要がなければ無効にしておきましょう。
  - Unity 上に配置して、AnimationClip を再生するくらいの使い方であれば、Read/Write Enabled は無効で問題ありません
- 有効にすると、CPU でアクセス可能な情報をメモリに保持するためメモリを 2 倍消費します
Vertex Compression
- Vertex Compression はメッシュの頂点情報の精度を float から half に変更するオプション
- ランタイム時のメモリ使用量とファイルサイズを小さくすることが可能
- Project Settings -> Player」の Other で設定ができる
Mesh Compression
- Mesh Compression はメッシュの圧縮率を変更できます。
- 圧縮率が高いほどファイルサイズが小さくなりストレージの占める割合が削減
Optimize Mesh Data
- メッシュに不要な頂点データを自動で削除する機能
- 不要な頂点データの判定には使用している Shader から自動判定
- Project Settings -> Player の Other で設定が可能
  (ただしこのオプションは頂点データが自動削除されるので便利ですが、予期せぬ不
  具合を引き起こす可能性があるので注意しましょう。たとえばランタイムで Material
  や Shader を切り替えた際、アクセスしたプロパティが削除されており描画結果がお
  かしくなることがあります。他にも Mesh のみをアセットバンドル化する際、Material
  の設定が正しくなかった場合に不要な頂点データと判定されることもあります。これ
  は Particle System のような Mesh の参照だけを持たせる場合にありがちです。)

Material

パラメーターにアクセスするだけで複製される
（例）

Material material;

 void Awake()
{
 material = renderer.material; //マテリアルを取得
 material.color = Color.green;//マテリアルの色を変更
}

削除する必要がある

void Awake(){
material = renderer.material;
material.color = Color.green;
}
void OnDestroy()
{
if (material != null)
 {
 Destroy(material)
 } 
}

必要なくなったら削除を忘れないこと

Animation

スキンウェイト数の調整
モーションは内部的にはそれぞれの頂点がどの骨からどれぐらい影響を受けている
かを計算して位置を更新しています。
- 位置計算に加味する骨の数をスキンウェイト数、またはインフルエンス数と呼ぶ
- スキンウェイト数を調整することで負荷削減ができる
- スキンウェイト数を減らすと見た目がおかしくなる可能性がある
- Project Settings -> Quality」の Other から設定が可能です
キーの削減
- アニメーションファイルはキーの数に依存してストレージとランタイム時のメモリを圧迫します
- Anim. Compression という機能があり
- Anim. Compression を有効にするとアセットインポート時に不要なキーが自動で削除
更新頻度の削減
- Animator はデフォルト設定では画面に映っていなくても毎フレーム更新を行います
- Cull Completely を設定する場合、Root モーションを利用している際は注意が必要
  - 画面外からフレームインするようなアニメーションの場合、画面外にいるためアニメーションは即座に停止されます。その結果いつまでたってもフレームインしなくなります。
- Cull Update Transform です。これは Transform の更新がスキップされるだけなので、とても使い勝手のよいオプションのように感じます。
- 揺れものといった Transform に依存した処理がある場合は注意が必要
  - キャラクターがフレームアウトすると、そのタイミングのポーズから更新がされなくなります。そして再びフレームインした際に新たなポーズに更新されるため、その弾みで揺れものが大きく動く可能性があります
- カメラから距離が離れているオブジェクトのアニメーションの更新頻度を半分にするなどの最適化です。その場合は AnimationClipPlayable を利用するか、Animator を非アクティブにしたうえで自身で Animator.Update を呼ぶ必要があります。どちらも自前でスクリプトを書く必要がありますが、前者に比べ後者の方が簡単に導入できる

パーティクルシステム

Audio

以下の設定項目を中心に適切なものに設定していく

Load Type
Compression Format
Force To Mono

Load Type

Decompress On Load
- 非圧縮でメモリにロードします
- CPU 負荷が低いため待機時間が小さく再生されます
- 尺が短くすぐに再生してほしい効果音にオススメ
- SE
Compressed In Memory
- AudioClip を圧縮した状態でメモリにロードします
- 再生するタイミングで展開する
- CPU 負荷が高く、再生遅延が起きやすいです
- ファイルサイズが大きく、メモリにそのまま展開したくないサウンドや、多少の再生遅延に問題ないサウンドが適しています
- ボイス
Streaming
- ロードしながら再生する方式です
- メモリ使用量は少ない代わりに CPU 負荷が高くなります
- 尺の長い BGM での使用がオススメ

Compression Format

PCM
- 非圧縮で、メモリを大量に消費します
- 音質によほどクオリティを求めない限り設定することはありません
ADPCM
- PCM に比べてメモリ使用量は 70% 減ります
- クオリティは低くなります
- CPU負荷が Vorbis と比較して格段に小さいのが特徴
- 展開スピードが速いため、即時再生や大量に再生するサウンドに適しています
- 足音や衝突音、武器などのノイズを多く含む且つ、大量に再生する必要のあるサウンド
Vorbis
- 非可逆圧縮フォーマットのため、PCM よりクオリティは下がります
- ファイルサイズは小さくなります
- 唯一 Quality を設定できるため、微調整も可能です。全サウンド（BGM、効果音、ボイス）でもっとも使われる圧縮形式
Preserve Sample Rate
- デフォルト設定です。元音源のサンプルレートが採用されます。
Optimize Sample Rate
- Unity 側で解析され、最高周波数の成分に基づいて自動で最適化されます
Override Sample Rate
- 元音源のサンプルレートを上書きします。8,000〜192,000Hz まで指定可能で
- 元の音源より高くしても品質は上がりません
- 元音源よりサンプルレートを下げたい場合に使用します

Force To Mono

Force To Mono を有効にすることでモノラル再生になります。モノラル再生を強制することで左右それぞれのデータを持たなくて良くなるため、ファイルサイズとメモリサイズは半分になります

（パフォーマンスチューニングとは話がずれますが音声ファイルは無圧縮のものを
Unity に取り込みましょう。圧縮済みのものをインポートした場合、Unity 側でデ
コード & 再圧縮を行うので品質の低下が発生します。）

Physics

物理演算のオン・オフ
- ゲーム内で物理演算を必要としない場合は、物理エンジンをオフにしておくとよい
- Physics.autoSimulation に値を設定することでオン・オフを切り替えることができます
  - インゲーム中のみ物理演算を用いて、それ以外では利用しない場合は、インゲーム中のみこの値を true に設定しておくとよい
Fixed Timestep と Fixed Update の頻度の最適化
- MonoBehaviour の FixedUpdate は Update とは違い、固定時間で実行されます。
- Fixed Timestep の値が小さいと、より多くの回数 Fixed Update が呼び出され、負荷の原因となります
- Project Settings の Fixed Timestep で設定できます
- Fixed Timestep は一般に、小さいほど物理演算の精度が上がり、コリジョン抜けなどの問題が発生しにくくなります
Maximum Allowed Timestep
Fixed Timestep が 20 ミリ秒で前フレームに 200 ミリ秒かかったとき、Fixed Update は 10 回呼び出されることになります。つまり、あるフレームで処理落ちした場合は次のフレームでの物理演算のコストが高
くなります。
- Project Settings からMaximum Allowed Timestep という、1 フレーム内で物理演算が利用する時間の最大値が設定できます。
コリジョン形状の選定
- 衝突判定の処理コストは、コリジョンの形状やその状況に左右されます
- 判定コストを低い順に並べるとスフィアコライダー、カプセルコライダー、ボックスコライダー、メッシュコライダー
- メッシュコライダーは負荷が高くなる
衝突マトリックスとレイヤーの最適化
- ProjectSettings の Physics > Layer Collision Matrix から変更できます。
  
  (衝突しないレイヤー同士はブロードフェーズと呼ばれるオブジェクトの大雑把な当
  たり判定を取る前計算からも除外されるため、この設定を適切に行うのが、衝突する
  必要がないオブジェクト同士の計算を省くのに最も効率的です。
  パフォーマンスを考慮すると、物理演算には専用のレイヤーを用意し、衝突する必要
  のないレイヤー間のチェックボックスはすべてオフにすることが望ましいです。)
レイキャストの最適化
- レオキャストの種類
  - 、線分との衝突判定を取る Physics.Raycast 以外にも、Physics.SphereCast などの、その他の形状で判定を取るメソッドが用意されています
  - 可能な限り Physics.Raycast の利用のみに留める
- レイキャストのパラメーターの最適化
  - maxDistance はレイキャストの判定を行う最大の長さ,最大値を必要最低限の距離に指定
  - layerMask も、当たりを取る必要のないレイヤーのビットは立てないようにします
  - 、既定値として Physics.DefaultRaycastLayers という、Ignore Raycast 以外のすべてのレイヤーと衝突する値が指定されるため、こちらも必ず指定
- RaycastAll と RaycastNonAlloc
  - Physics.Raycast では、衝突したコライダーのうち 1 つの衝突情報が返却されます
  - Physics.RaycastAll メソッドを利用すると、複数の衝突情報を取得できます。
    (Physics.RaycastAll は衝突情報を、RaycastHit 構造体の配列を動的に確保して返
    却します。そのため、このメソッドを呼び出すたびに GC Alloc が発生し、GC による
    スパイクの原因になります。
    この問題を回避するために、確保済みの配列を引数に渡すと、結果をその配列に書
    き込んで返却する Physics.RaycastNonAlloc というメソッドが存在します。
    パフォーマンスを考慮すると FixedUpdate 内では、可能な限り GC Alloc を発生させないようにすべきです)
コライダーと Rigidbody
- 静的コライダー
  - は常に同じ場所に留まる、動くことのないジオメトリにのみ使用することを前提に最適化
  - ゲーム中に静的コライダーの有効・無効を切り替えたり、移動やスケーリングを行なうべきではありません
  - 内部のデータ構造の変更に伴う再計算が行われ、パフォーマンスを著しく低下させる原因となります
- 動的コライダー
  - 物理エンジンによって他のオブジェクトと衝突できます。また、スクリプトから Rigidbody コンポーネントを操作することによって適用される衝突や力に反応できます
- キネマティックな動的コライダー
  - 物理演算の実行を切り替えたい場合や、ドアなどのたまに動かしたいが大半は動かない障害物などにこのコライダーを利用することで、物理演算を最適化
Rigidbody とスリープ状態
物理エンジンでは最適化の一環として、Rigidbody コンポーネントをアタッチしたオブジェクトが一定時間動かない場合、そのオブジェクトは休止中と判断して、そのオブジェクトの内部状態をスリープ状態に変更します
スリープ状態に移行すると、外力や衝突などのイベントによって動かない限りは、そのオブジェクトにかかる計算コストが最小限に抑えられます。
Rigidbody コンポーネントがアタッチされたオブジェクトのうち動く必要のないものは、可能な限りスリープ状態に遷移させておくことで物理演算の計算コストを抑えることができます。
Project Settings の Physics 内部の Sleep Thresholdで設定できます。また、個別のオブジェクトに対してしきい値を指定したい場合は、Rigidbody.sleepThreshold プロパティから設定できます。

(Sleep Threshold はスリープ状態に移行する際の質量で正規化された運動エネル
ギーを表します。
この値を大きくすると、オブジェクトはより早くスリープ状態へ移行するため、計算
コストを低く抑えられます。しかし、ゆっくり動いている場合にもスリープ状態へ移
行する傾向にあるため、オブジェクトが急停止したように見える場合があります。こ
の値を小さくすると、上記の現象は発生しにくくなりますが、一方でスリープ状態へ
は移行しづらくなるため、計算コストを抑えられにくい傾向になります。)
衝突検出の最適化
- 離散的衝突判定と連続的衝突判定の 2 つに分類されます
  - Discrete は離散的衝突判定で、それ以外は連続的衝突判定に属します
    - 1 シミュレーションごとにオブジェクトが離散的にテレポート移動し、すべてのオブジェクトが移動後に衝突判定を行います。そのため、とくにオブジェクトが高速に移動している場合に、衝突を見逃してすり抜けを起こす可能性があります
  - 連続的衝突判定は、移動前後のオブジェクトの衝突を考慮するために、高速に動くオブジェクトのすり抜けを防ぎます。
    - 計算コストは離散的衝突判定と比べて高くなります。
    - パフォーマンスを最適化するには、可能な限り Discrete を選択できるようにゲームの挙動を作ります。
  - Continuous は動的コライダーと静的コライダーの組み合わせにのみ連続的衝突判定が有効になります
  - ConitnuousDynamic は動的コライダー同士でも連続的衝突判定が有効になります。
  - Continuous Speculative は動的コライダー同士で連続的衝突判定が有効にもかかわらず Continuous Dynamic より計算コストが低いですが、複数のコライダーが密接している箇所で誤衝突してしまうゴースト衝突（Ghost Collision）と呼ばれる現象が発生するため、導入には注意が必要です
Physics.autoSyncTransforms
Unity 2018.3 より前のバージョンでは、Physics.Raycast などの物理演算に関する
API を呼び出すたびに、Transform と物理エンジンの位置が自動的に同期されていま
した。
この処理は比較的重たいので、物理演算の API を呼び出したときにスパイクの原因
になります。
この問題を回避するために、Unity 2018.3 以降、Physics.autoSyncTransforms と
いう設定が追加されています。この値に false を設定すると、上記で説明した、物理
演算の API を呼び出したときの Transform の同期処理が行われなくなります。
Transform の同期は物理演算のシミュレーション時の、FixedUpdate が呼び出され
た後になります。つまり、コライダーを移動してから、そのコライダーの新しい位置
に対してレイキャストを実行しても、レイキャストがコライダーに当たらないことを
意味します。
Physics.reuseCollisionCallbacks
Unity 2018.3 より前のバージョンでは、OnCollisionEnter などの Collider コン
ポーネントの衝突判定を受け取るイベントが呼び出されるたびに、引数の Collision
インスタンスを新たに生成して渡されるため、GC Alloc が発生していました。
この挙動は、イベントの呼び出し頻度によってはゲームのパフォーマンスに悪影響
を及ぼすため、2018.3 以降では新たに Physics.reuseCollisionCallbacks というプ
ロパティが公開されました。この値に true を設定すると、イベント呼び出し時に渡される Collision インスタンスを内部で使い回すため、GC Alloc が抑えられます。
(現在はデフォルトでオンになっている)

Graphics

解像度の調整
- Resolution Scaling Mode を Fixed DPI に設定すると、特定の DPI（dots per inch）をターゲットに解像度を落とすことができます
  
  最終的な描画解像度は、Target DPI の値と Quality Settings に含まれる Resolution
  Scaling DPI Scale Factor の値が乗算されて決定します。
- 複数プラットフォームのある場合は動的に調整するのがよさそう
半透明とオーバードロー
- 半透明マテリアルの使用はオーバードローの増加の大きな原因となります
- とくに Particle System などで大量に半透明のパーティクルを発生させる場合などにオーバードローが大量に発生することが多い
- 軽減方法
  - テクスチャが完全に透明な領域も描画対象になるためなるべく減らす
  - オーバードローが発生する可能性のあるオブジェクトにはなるべく軽量なシェーダーを使用する
  - 不透明マテリアルで擬似的に半透明のような見た目を再現できるディザリングという手法も検討する
    (Built-in Render Pipeline の Editor では Scene ビューのモードを Overdraw に変更
    することでオーバードローを可視化することができ、オーバードローの調整の基準と
    して有用です。)
ドローコールの削減
- 動的バッチング
  - 同じマテリアルを使用している動的なオブジェクトのドローコールを統合して削減できます。
  - (Player Settings から Dynamic Batching の項目を有効にします。
    また、Universal Render Pipeline では Universal Render Pipeline Asset 内の Dynamic Batching の項目を有効にする必要があります。ただ Universal Render Pipeline
    では Dynamic Batching の使用は非推奨となっています。)
- 静的バッチング
  - Player Settings から Static Batching を有効にすることで使用できます。
  - 静的バッチングは動的バッチングとは違いランタイムでの頂点の変換処理を行わないため低負荷で実行できます。しかし、バッチ処理によって結合されたメッシュ情報を保存するためメモリを多く消費することに注意が必要です。
- GPU インスタンシング
  GPU インスタンシングとは同一メッシュ・同一マテリアルのオブジェクトを効率的
  に描画するための機能です。草や木のように同じメッシュを複数回描画する場合のド
  ローコールの削減が期待できます。
- マテリアルの Inspector から Enable Instancing を有効にします。

UI

Raycast Target
できる限りオフにする
TextMeshPro
- ZStringを利用して文字を渡すとより効率の良くなる
  https://github.com/Cysharp/ZString
UIの切り替え
- UI の表示非表示の切り替えの方法として、SetActive による方法以外の選択肢も検討することが重要
- Canvas の enabled を false にするという方法
- CanvasGroup を使った方法です。CanvasGroup には、その配下のオブジェクトの透明度を一括で調整できる機能があります。この機能を利用して、透明度を 0 にしてしまえば、その CanvasGroup 配下のオブジェクトをすべて非表示にできます

Script

からのUnityイベントを発行しない
tag や name のアクセスしない
個人的にタグはインターフェースで置き換えられそう
コンポーネントの取得はあまりしない
transform へのアクセスもできるだけしない
- キャッシュして使うのが良い
明示的な破棄が必要なクラスもあります
- Texture2D、 Sprite、Material、PlayableGraph などです。newや専用の Create 関数で生成した場合、必ず明示的に破棄
Burst を用いたコードの高速化を目指す
アトリビュートを追加してバーストコンパイラーを利用してコンパイルする。

LIstと配列
- Listの方が遅いがさまざまなメソッドが用意してある
- 配列の方が早い
LINQを使うと GC.Allocの原因になる可能性がある
不要な場所で async を避ける

PlayerSettings

IL2CPPを選択することを推奨します。
Debug、Release、Master から選べる
- Debug
  - 最適化が行われないためランタイムでのパフォーマンスは良くありませんが、ビル
    ド時間は他の設定と比較してもっとも短くなります。
- Release
  - 最適化によりランタイムのパフォーマンスが向上し、ビルドしたバイナリのサイズ
    もより小さくなりますが、ビルドに要する時間は伸びます。
- Master
  - そのプラットフォームで利用可能なすべての最適化が有効化されます。
  - たとえばWindows 向けのビルドでは、リンク時コード生成 (LTCG) が使用されるなど、よりアグレッシブな最適化が行われます。
  - その代わりとしてビルド時間は Release 設定よりもさらに伸びますが、それが許容できる場合、製品版のビルドには Master 設定を使用することを Unity は推奨しています。
Strip Engine Code / Managed Stripping Level
Accelerometer Frequency (iOS)
iOS 固有の設定で、加速度センサーのサンプリング周波数を変更できます。初期設
定では 60Hz になっているため、適切な周波数に設定しましょう。とくに加速度セン
サーを利用していない場合は、必ず設定を無効化しましょう。

Third Party

DOTween
DOTween.Sequence() や transform.DOScale(...) など、Tween を生成する処理は
基本的にメモリアロケーションを伴うため、頻繁に再生されるアニメーションはイン
スタンスの再利用を検討しましょう

デフォルトではアニメーション完了時に自動的に Tween が破棄されてしまうので、
SetAutoKill(false) でこれを抑制します。最初の使用例は、次のコードに置き換え
ることができます。

UniRx
購読の解除を忘れずに行う

UniTaskを使おう

このスクラップは2023/05/15にクローズされました