Unityの動作が重いときは、設定をまとめて下げる前にProfilerで時間のかかっている処理を確認します。
CPU、描画、メモリなどを分けて調べると、効果のある修正を選びやすくなります。
最初の目標は、グラフの数字をすべて理解することではありません。
「どの操作で重くなるか」「そのフレームのどの処理が長いか」を記録し、1つ変更した後で同じ場面を測り直すことです。
Unity 6.0の公式資料を2026年10月26日に照合しています。
今回、対象端末への接続や計測、画面確認は実施していません。
計測前に再現する場面を決める
たとえば「敵を50体出した瞬間」「インベントリを開いたとき」「同じ場所を移動している間」のように、重くなる条件を具体化します。
起動直後と通常プレイを混ぜると、ロードや初期化の負荷を、毎フレーム発生する問題と取り違えやすくなります。
| 記録する条件 | 記入例 |
|---|---|
| 対象 | Windowsの開発用ビルド |
| 画面設定 | 解像度、品質設定、VSync |
| 再現操作 | 同じセーブデータでメニューを開く |
| 見る区間 | 開く直前から表示後まで |
例の環境が必須という意味ではありません。
自分の製品で想定している端末と条件を記録し、変更前後を比較できる状態にすることが大切です。
Profilerで記録し、問題のフレームを選ぶ
- Window → Analysis → Profilerを開きます。
- 計測対象のプレイヤーを確認し、記録を有効にします。
- Playモードや対象ビルドで、重くなる操作を再現します。
- 必要な区間を取れたら記録を止めます。
- CPU Usageなどのグラフで時間が伸びたフレームを選びます。
まずEditor上で原因の候補を探す方法でも構いません。
ただし、Editor自身の処理や開いているウィンドウの影響があるため、最終的な判断は対象端末のビルドでも確認します。
ウィンドウの各表示はUnity公式のProfilerウィンドウ解説を参照できます。
TimelineとHierarchyを使い分ける
Timelineでは、処理がどのスレッドでどの順番に実行されたかを見ます。
長い区間が、実際の計算なのか、ほかの処理を待っている時間なのかを考える入口になります。
Hierarchyでは、処理を階層で追い、時間がかかる項目を探します。
親の時間には子の処理が含まれるため、上位の大きな値だけを見て「この関数だけが遅い」と結論づけないようにします。
展開して、どの子処理が時間を使っているかを確認します。
待機を示す項目が長い場合、その項目名を見つけて消せば速くなるとは限りません。
VSync、GPU側の処理、別スレッドとの同期などを合わせて調べ、待っている理由を切り分けます。
HierarchyのTime msは子の処理を含む時間、Self msは子を除いた時間です。
TotalとSelfは、フレーム時間に対する割合を示します。
呼び出し回数はCallsで確認し、1回が重いのか、多数の呼び出しが積み重なっているのかを分けて見ます。
Hierarchyは選択中のスレッドの値なので、全スレッドを見渡すにはTimelineも併用してください。
各列の意味はCPU Usageの公式リファレンスで確認できます。
フレーム時間で目標を考える
60fpsを目指すなら1フレームは約16.7ms、30fpsなら約33.3msです。
平均が収まっていても、ときどき長いフレームがあると引っかかって見えます。
平均だけでなく、再現するスパイクにも注目します。
CPU時間とGPU時間は単純に足してフレーム時間になるとは限りません。
処理の並列実行や待機があるため、まずどちらがボトルネックになっているかを確認します。
GPU計測の対応状況は環境によって異なるので、表示されない場合は対象プラットフォームの対応も確認してください。
GC Allocは毎フレーム発生するかを見る
CPU UsageでGC Allocが繰り返し出ている場合は、一時的なオブジェクト生成などを調べるきっかけになります。
ただし、割り当てがあることと、そのフレームでガベージコレクションが発生したことは別です。
ログの組み立て、文字列の連結、頻繁な配列生成などが疑わしい場合でも、先に計測して発生箇所を確認します。
ロード時に一度だけ行う処理と、Update内で毎フレーム行う処理では、修正の優先度が変わります。
割り当ての呼び出し元を知りたい場合は、記録前にツールバーのCall StacksでGC.Allocを選び、同じ操作を再記録します。
これにより、Deep Profileを有効にしなくても、選んだ割り当てサンプルの呼び出し履歴を収集できます。
Deep Profileは必要な場面で絞って使う
Deep Profileは詳しく追える反面、計測の負荷も増えます。
最初から常用して、その数値を通常プレイの性能として扱わないようにします。
通常の計測で問題の範囲を絞り、詳細が必要な箇所を調べるために使います。
同様に、Profilerを接続した開発用ビルドと、リリース用ビルドでは条件が異なります。
実機への接続や開発用ビルドの設定はUnity公式のアプリケーション計測ガイドで確認できます。
修正は1つずつ行い、同じ条件で測り直す
描画設定、スクリプト、テクスチャを同時に変更すると、どれが効いたのか分からなくなります。
原因の仮説を1つ決め、変更前後で同じ操作を繰り返します。
- 問題のフレーム時間が短くなったか。
- 通常時の負荷が悪化していないか。
- メモリ使用量や画質との交換条件がないか。
- 対象端末でも改善が再現するか。
計測結果と変更内容をセットで残すと、次に重くなったときも比較できます。
Profilerは数字を眺めるための画面ではなく、どの修正を選ぶか判断するために使うと効果的です。
変更前の記録は、次の計測を始める前にProfiler上部のSaveで.dataファイルとして保存します。
ClearやClear on Playでデータが消える前に、対象端末と再現条件も併せて控えてください。
変更後は別名で保存し、Loadで各記録を読み込んで同じ操作の区間を比較します。
この保存・比較手順は公式仕様に基づく案内で、今回の性能改善を実測した結果ではありません。
ほかの症状はUnityのエラー一覧で、症状別に先に確かめることをまとめています。
