Unity のパフォーマンスに関する推奨事項Performance recommendations for Unity

今回は説明に記載されている複合現実のパフォーマンスに関する推奨事項が、Unity エンジンの環境に固有の教訓について説明します。This article builds on the discussion outlined in performance recommendations for mixed reality but focuses on learnings specific to the Unity engine environment.

開発者が確認すること強くお勧めしますも、 Unity 資料の環境の設定をお勧めしますします。It is also highly advisable that developers review the recommended environment settings for Unity article. この記事では、パフォーマンスの高い Mixed Reality アプリの構築においていくつかの最も重要なシーン構成内容を持っています。This article has content with some of the most important scene configurations in regards to building performant Mixed Reality apps. これらの推奨設定の一部が強調表示の下にもします。Some of these recommended settings are highlighted below as well.

Unity でプロファイルする方法How to profile with Unity

Unity は、 Unity Profiler 組み込み優れたリソースが、特定のアプリのパフォーマンスの貴重な洞察を収集します。Unity provides the Unity Profiler built-in which is a great resource to gather valuable performance insights for your particular app. エディターでプロファイラーを実行する 1 つは、これらのメトリックは、true のランタイム環境を表していないと、これからの結果があるため注意が必要です。Although one can run the profiler in-editor, these metrics do not represent the true runtime environment and thus, results from this should be used cautiously. 最も正確な実用的な情報をデバイスで実行中にアプリケーションをリモートでプロファイルに勧めします。It is recommended to remotely profile your application while running on device for most accurate and actionable insights. さらに、Unity のフレーム デバッガーも非常に強力なと分析情報ツールを利用します。Further, Unity's Frame Debugger is also a very powerful and insight tool to utilize.

Unity では、優れたドキュメントを提供します。Unity provides great documentation for:

  1. 接続する方法、 Unity profiler UWP アプリケーションをリモートでHow to connect the Unity profiler to UWP applications remotely
  2. 方法を効果的にUnity Profiler でパフォーマンスの問題の診断How to effectively diagnose performance problems with the Unity Profiler


接続されている Unity Profiler とは、GPU プロファイラーを追加した後 (を参照してください追加 Profiler右上隅で)、どの程度時間を要している CPU および GPU ではそれぞれ、プロファイラーの途中でいずれかを確認できます。With the Unity Profiler connected and after adding the GPU profiler (see Add Profiler in top right corner), one can see how much time is being spent on the CPU & GPU respectively in the middle of the profiler. これにより、開発者は、アプリケーションが CPU または GPU の境界付けられた場合にクイック近似を取得できます。This allows the developer to get a quick approximation if their application is CPU or GPU bounded.

Unity CPU と GPU

CPU のパフォーマンスに関する推奨事項CPU performance recommendations

以下のコンテンツより詳細なパフォーマンス手法、Unity の特に対象となる &C#開発します。The content below covers more in-depth performance practices, especially targeted for Unity & C# development.

キャッシュの参照Cache references

ベスト プラクティスの初期化時のすべての関連するコンポーネントおよび Gameobject に参照をキャッシュすることをお勧めします。It is best practice to cache references to all relevant components and GameObjects at initialization. これなどの関数呼び出しを繰り返すため*GetComponent<T > ()* は相対メモリのポインターを格納するためにコストが大幅に高価です。This is because repeating function calls such as GetComponent<T>() are significantly more expensive relative to the memory cost to store a pointer. これにも当てはまりますに、非常に、定期的に使用するCamera.mainします。This also applies to to the very, regularly used Camera.main. Camera.mainに実際にしか使用*FindGameObjectsWithTag()* 低いコスト カメラはシーン グラフを検索する下、 "MainCamera" タグ。Camera.main actually just uses FindGameObjectsWithTag() underneath which expensively searches your scene graph for a camera object with the "MainCamera" tag.

using UnityEngine;
using System.Collections;

public class ExampleClass : MonoBehaviour
    private Camera cam;
    private CustomComponent comp;

    void Start() 
        cam = Camera.main;
        comp = GetComponent<CustomComponent>();

    void Update()
        // Good
        this.transform.position = cam.transform.position + cam.transform.forward * 10.0f;

        // Bad
        this.transform.position = Camera.main.transform.position + Camera.main.transform.forward * 10.0f;

        // Good

        // Bad

[!NOTE] Avoid GetComponent(string)Avoid GetComponent(string)
使用する場合 GetComponent()、さまざまなオーバー ロードが多数があります。When using GetComponent(), there are a handful of different overloads. このデータベースが、ベース型の実装としない文字列に基づく検索オーバー ロードを常に使用する重要です。It is important to always use the Type based implementations and never the string-based searching overload. シーン内の文字列で検索することは、型を検索するよりも大幅に高額です。Searching by string in your scene is significantly more costly than searching by Type.
(良好)コンポーネント GetComponent (型)(Good) Component GetComponent(Type type)
(良好)T GetComponent<T >)(Good) T GetComponent<T>()
(不良)コンポーネント GetComponent(string) >(Bad) Component GetComponent(string)>

負荷の高い操作を回避します。Avoid expensive operations

  1. 使用を防ぐLINQAvoid use of LINQ

    LINQ は、非常にクリーンで読み取りし、書き込みを簡単にできますが、さらに多くの計算と特に多くのメモリ割り当て手動でアルゴリズムを記述するよりもが一般に必要です。Although LINQ can be very clean and easy to read and write, it generally requires much more computation and particularly more memory allocation than writing the algorithm out manually.

    // Example Code
    using System.Linq;
    List<int> data = new List<int>();
    data.Any(x => x > 10);
    var result = from x in data
                 where x > 10
                 select x;
  2. 一般的な Unity ApiCommon Unity APIs

    特定の Unity Api 機能は便利を実行する非常にコストことがあります。Certain Unity APIs, although useful, can be very expensive to execute. これらのほとんどは、Gameobject の一致するいくつか一覧については、シーン全体のグラフの検索に関連します。Most of these involve searching your entire scene graph for some matching list of GameObjects. これらの操作は、参照をキャッシュまたは実行時に参照を追跡するには、対象の Gameobject の manager コンポーネントの実装によって一般的に回避できます。These operations can generally be avoided by caching references or implementing a manager component for the GameObjects in question to track the references at runtime.



SendMessage() と*BroadcastMessage()* 代価除去する必要があります。SendMessage() and BroadcastMessage() should be eliminated at all costs. これらの関数は、1000 x 関数を直接呼び出すよりも低速の順序指定できます。These functions can be on the order of 1000x slower than direct function calls.

  1. ボックス化に注意してください。Beware of boxing

    ボックス化はのコア概念であり、C#言語とランタイム。Boxing is a core concept of the C# language and runtime. 参照型の変数に char、int、bool などの値に型指定された変数の折り返しのプロセスです。It is the process of wrapping value-typed variables such as char, int, bool, etc. into reference-typed variables. 値に型指定された変数が"boxed"では、マネージ ヒープに格納されている System.Object 内部でラップされます。When a value-typed variable is "boxed", it is wrapped inside of a System.Object which is stored on the managed heap. したがって、メモリが割り当てられていると、最終的に破棄されたときに、ガベージ コレクターによって処理する必要があります。Thus, memory is allocated and eventually when disposed must be processed by the garbage collector. これらの割り当てと解放、パフォーマンス コストが発生し、多くのシナリオでは必要ありませんまたは安価な代替手段によって簡単に置き換えることができます。These allocations and deallocations incur a performance cost and in many scenarios are unnecessary or can be easily replaced by a less expensive alternative.

繰り返しのコード パスRepeating code paths

繰り返しの Unity コールバック関数 (つまり、Any repeating Unity callback functions (i.e 更新プログラム) 1 秒あたり何度も実行されている、またはフレームを非常に慎重に記述する必要があります。Update) that are executed many times per second and/or frame should be written very carefully. ここで負荷の高い操作には、パフォーマンスに大きく、一貫性のある可能性があります。Any expensive operations here will have huge and consistent impact on performance.

  1. 空のコールバック関数Empty callback functions

    次のコードをすべて Unity スクリプト自動初期化を次のコード ブロックで以降は特に、アプリケーションをそのまま無害に見える可能性がありますこれら空のコールバックに非常に不経済実際になります。Although the code below may seem innocent to leave in your application, especially since every Unity script auto-initializes with this code block, these empty callbacks can actually become very expensive. Unity は、UnityEngine コードと、アプリケーション コードの間、コードのアンマネージ/マネージの境界を越えた双方向とは動作します。Unity operates back and forth over an unmanaged/managed code boundary, between UnityEngine code and your application code. 実行するものがない場合でも、コンテキストのこのブリッジ経由での切り替えはかなり安価です。Context switching over this bridge is fairly expensive even if there is nothing to execute. これは、アプリがある空の繰り返し Unity コールバックのコンポーネントを持つ Gameobject の何百場合に特に問題になります。This becomes especially problematic if your app has 100's of GameObjects with components that have empty repeating Unity callbacks.

    void Update()


Update() はこのパフォーマンスの問題の最も一般的な形が、次などの他の繰り返し Unity コールバックは均等に悪くない最悪の場合。FixedUpdate()、LateUpdate()、OnPostRender"、OnPreRender()、OnRenderImage() など。Update() is the most common manifestation of this performance issue but other repeating Unity callbacks such as the following can be equally as bad if not worse: FixedUpdate(), LateUpdate(), OnPostRender", OnPreRender(), OnRenderImage(), etc.

  1. 操作 1 回実行しているどちらを優先するフレームごとOperations to favor running once per frame

    次の Unity Api は、Holographic アプリの多くの一般的な操作です。The following Unity APIs are common operations for many Holographic Apps. 常に可能ではない、ですが、これらの関数から結果を 1 回計算する非常によくし、結果は、特定のフレームのアプリケーション全体にわたって再利用します。Although not always possible, the results from these functions can very commonly be computed once and the results re-utilized across the application for a given frame.

    専用シングルトン クラスまたはサービスを視線入力 Raycast をシーンに処理し、その他のシーン、すべてのコンポーネントごとに繰り返されると、実質的に同じ Raycast 操作を行う代わりにこの結果を再利用することをお勧めは通常、a)コンポーネント。a) Generally it is good practice to have a dedicated Singleton class or service to handle your gaze Raycast into the scene and then re-use this result in all other scene components, instead of making repeated and essentially identical Raycast operations by each component. もちろん、一部のアプリケーションが raycasts またはに対して異なるさまざまな配信元からを必要がありますLayerMasksします。Of course, some applications may require raycasts from different origins or against different LayerMasks.


    b) で Update() のような繰り返しの Unity コールバックで GetComponent() 操作を回避するの参照をキャッシュStart() または Awake()b) Avoid GetComponent() operations in repeated Unity callbacks like Update() by caching references in Start() or Awake()


    c) は初期化で使用可能であれば、すべてのオブジェクトをインスタンス化することをお勧めオブジェクト プーリングリサイクルし、アプリケーションのランタイム全体にわたって Gameobject を再利用するにはc) It is good practice to instantiate all objects, if possible, at initialization and use object pooling to recycle and re-use GameObjects throughout runtime of your application

  2. インターフェイスと仮想の構成要素を回避します。Avoid interfaces and virtual constructs

    Vs ダイレクト オブジェクトのインターフェイスを通じて関数呼び出しを起動または仮想関数を呼び出すことがよくありますできます直接コンストラクトまたは関数の直接呼び出しを使用するよりもはるかに高くなります。Invoking function calls through interfaces vs direct objects or calling virtual functions can often times be much more expensive than utilizing direct constructs or direct function calls. 仮想関数またはインターフェイスが必要な場合は、削除する必要があります。If the virtual function or interface is unnecessary, then it should be removed. ただし、パフォーマンスへのこれらの方法に影響は、通常のトレードオフの価値が開発のコラボレーション、コードの読みやすさ、およびコードの保守性を簡略化に利用する場合。However, the performance hit for these approaches are generally worth the trade-off if utilizing them simplifies development collaboration, code readability, and code maintainability.

  3. 値構造体の受け渡しを避けるAvoid passing structs by value

    クラスと異なり、構造体は、値型と関数に直接渡されると、新しく作成されたインスタンスにその内容がコピーされます。Unlike classes, structs are value-types and when passed directly to a function, their contents are copied into a newly created instance. このコピーは、コスト、スタックに追加のメモリと CPU を追加します。This copy adds CPU cost as well as additional memory on the stack. 小さな構造体は、効果は、通常は最小限にし、許容されるためです。For small structs, the effect is usually very minimal and thus acceptable. ただし、関数は、すべてのフレームを繰り返し呼び出すのと同様に大規模な構造体を取得する関数は可能であれば、参照渡しの関数定義を変更します。However, for functions repeatedly invoked every frame as well as functions taking large structs, if possible modify the function definition to pass by reference. 詳細はこちらLearn more here


  1. 物理学Physics

    a) 一般的には、物理運動を向上させるために簡単では、物理運動または 1 秒あたりのイテレーションの数に費やされた時間の量を制限します。a) Generally, easiest way to improve physics is to limit the amount of time spent on Physics or the number of iterations per second. もちろん、これにより、シミュレーションの正確性が減少します。Of course, this will reduce simulation accuracy. 参照してくださいTimeManager Unity でSee TimeManager in Unity

    b) Unity でコライダーの種類では、大きく異なるパフォーマンス特性があります。b) The type of colliders in Unity have widely different performance characteristics. 以下の順番は、最低のパフォーマンスの高いコライダーを左から右へのほとんどのパフォーマンスの高いコライダーを一覧表示します。The order below lists the most performant colliders to least performant colliders from left to right. プリミティブのコライダーよりも大幅に高価であるメッシュ コライダーを回避するために最も重要です。It is most important to avoid Mesh Colliders which are substantially more expensive than the primitive colliders.

     Sphere < Capsule < Box <<< Mesh (Convex) < Mesh (non-Convex)

    参照してくださいUnity 物理学のベスト プラクティスの詳細See Unity Physics Best Practices for more info

  2. アニメーションAnimations

    Animator コンポーネントを無効にしてアイドル状態のアニメーションを無効にする (ゲーム オブジェクトを無効にすると同じ効果が)。Disable idle animations by disabling the Animator component (disabling the game object won't have the same effect). アニメーターが同じものを値を設定、ループ内に存在する設計パターンを回避します。Avoid design patterns where an animator sits in a loop setting a value to the same thing. この手法でアプリケーションに影響をかなりのオーバーヘッドがあります。There is considerable overhead for this technique, with no effect on the application. 詳細について説明します。Learn more here.

  3. 複雑なアルゴリズムComplex algorithms

    簡単な方法を見つけたり、パフォーマンスに関連する設定を調整する場合は、アプリケーションは、複雑なアルゴリズム (インバース キネマティクス、パスの検索など) を使用して、なりますIf your application is using complex algorithms such as inverse kinematics, path finding, etc, look to find a simpler approach or adjust relevant settings for their performance

CPU、GPU にパフォーマンスに関する推奨事項CPU-to-GPU performance recommendations

一般に、CPU、GPU にパフォーマンスが得られる下に、描画呼び出しグラフィックス カードに送信します。Generally, CPU-to-GPU performance comes down to the draw calls submitted to the graphics card. 描画呼び出しをパフォーマンスを向上させるのには、戦略的にする必要がある ) 削減またはb) 再編成最善の結果。To improve performance, draw calls need to be strategically a) reduced or b) restructured for optimal results. 描画呼び出し自体は、リソース集中型であるためそれらを減らすために必要な作業は全体を削減できます。Since draw calls themselves are resource-intensive, reducing them will reduce overall work required. 描画呼び出し間の変更はコストのかかる検証を必要とし、グラフィックス ドライバーの変換のステップをさらに、状態にあり、したがって、制限の状態の変更 (つまり、アプリケーションの描画呼び出しの再構築Further, state changes between draw calls requires costly validation and translation steps in the graphics driver and thus, restructuring of your application's draw calls to limit state changes(i.e さまざまな資料など) は、パフォーマンスを向上させることができます。different materials, etc) can boost performance.

Unity では、概要を説明し、そのプラットフォームの描画呼び出しをバッチ処理に踏み込みます優れた記事には。Unity has a great article that gives an overview and dives into batching draw calls for their platform.

1 回インスタンス化されたレンダリングSingle pass instanced rendering

Unity での単一パス Instanced レンダリングで描画呼び出しをインスタンス化された 1 つの描画呼び出しに短縮する目ごとにできます。Single Pass Instanced Rendering in Unity allows for draw calls for each eye to be reduced down to one instanced draw call. 2 つの描画呼び出し間のキャッシュの一貫性のためのパフォーマンスの向上も GPU 上でもあります。Due to cache coherency between two draw calls, there is also some performance improvement on the GPU as well.

Unity プロジェクトでこの機能を有効にするにはTo enable this feature in your Unity Project

  1. 開いているPlayer XR 設定(に移動編集 > プロジェクト設定 > Player > XR 設定)Open Player XR Settings (go to Edit > Project Settings > Player > XR Settings)
  2. 選択1 つ渡すインスタンス化から、ステレオのレンダリング方法ドロップダウン メニュー (仮想現実サポートチェック ボックスを選択する必要があります)Select Single Pass Instanced from the Stereo Rendering Method drop-down menu (Virtual Reality Supported checkbox must be checked)

詳細についてはこのレンダリング アプローチで、Unity から、次の記事を読み取ります。Read the following articles from Unity for details with this rendering approach.


1 つ渡すレンダリングをインスタンス化で 1 つの一般的な問題は、開発者が既に既存のカスタム シェーダーに書かれていない場合に発生します。 インスタンス化します。One common issue with Single Pass Instanced Rendering occurs if developers already have existing custom shaders not written for instancing. この機能を有効にした後は、開発者は 1 つ目のいくつかの Gameobject のみレンダリングをことがあります。After enabling this feature, developers may notice some GameObjects only render in one eye. これは、関連付けられているカスタムのシェーダーの適切なプロパティがあるないためにインスタンス化します。This is because the associated custom shaders do not have the appropriate properties for instancing.

参照してください1 つ渡すステレオのレンダリング HoloLensから Unity のこの問題に対処する方法See Single Pass Stereo Rendering for HoloLens from Unity for how to address this problem

静的なバッチ処理Static batching

Unity は、GPU の描画呼び出しを減らすために多くの静的オブジェクトをバッチ処理することです。Unity is able to batch many static objects to reduce draw calls to the GPU. 静的なバッチ処理のほとんどの動作レンダラー Unity 内のオブジェクトを1) 同じ素材を共有するは 2) としてマークされているすべて*静的* (Unity でオブジェクトを選択し、上にあるチェック ボックスをオン、インスペクターの右)。Static Batching works for most Renderer objects in Unity that 1) share the same material and 2) are all marked as Static (Select an object in Unity and click the checkbox in the top right of the inspector). としてマークされている GameObjects静的アプリケーションのランタイム全体で移動することはできません。GameObjects marked as Static cannot be moved throughout your application's runtime. したがって、静的なバッチ処理はほとんどすべてのオブジェクトが移動された、スケーリングなど、配置する必要がある HoloLens の活用の困難さできます。イマーシブ ヘッドセットの静的バッチ処理できます描画呼び出しを大幅に削減し、パフォーマンスが向上します。Thus, static batching can be difficult to leverage on HoloLens where virtually every object needs to be placed, moved, scaled, etc. For immersive headsets, static batching can dramatically reduce draw calls and thus improve performance.

読み取り静的バッチ処理 Unity でバッチ処理を呼び出す描画の詳細。Read Static Batching under Draw Call Batching in Unity for more details.

動的なバッチ処理Dynamic batching

オブジェクトとしてマークする問題であるため静的HoloLens の開発、動的なバッチ処理できるでこれを補正する優れたツール機能が不足しています。Since it is problematic to mark objects as Static for HoloLens development, dynamic batching can be a great tool to compensate for this lacking feature. もちろん、イマーシブ ヘッドセットもで役に立ちます。Of course, it is can also be useful on immersive headsets as well. Unity でバッチ処理を動的なは難しいが Gameobject にする必要がありますので、有効にする ) 共有は同じ素材b) 多数の他の条件を満たすします。Dynamic batching in Unity can be difficult though to enable because GameObjects must a) share the same Material and b) meet a long list of other criteria.

読み取り動的バッチ処理 Unity でバッチ処理を呼び出す描画完全な一覧についてはします。Read Dynamic Batching under Draw Call Batching in Unity for the full list. ほとんどの場合、GameObjects は、バッチ処理する動的に関連付けられているメッシュ データとして使用できるは、300 個の頂点ので無効になります。Most commonly, GameObjects become invalid to be batched dynamically because the associated mesh data can be no more than 300 vertices.

その他の手法Other techniques

バッチ処理と複数 GameObjects は同じ素材を共有することがある場合のみ実行できます。Batching can only occur if multiple GameObjects are able to share the same material. 通常、それぞれの素材に対する一意のテクスチャを持つ Gameobject のですが、ブロックされます。Typically this will be blocked by the need for GameObjects to have a unique texture for their respective Material. 1 つの大きなテクスチャと呼ばれるメソッドにテクスチャを結合するが一般的テクスチャ Atlasingします。It is common to combine Textures into one big Texture, a method known as Texture Atlasing.

さらに、可能であり、適切な場所に 1 つの GameObject にメッシュを結合することをお勧めです。Further, it is generally preferable to combine meshes into one GameObject where possible and reasonable. Unity では、各レンダラーが、描画呼び出しの 1 つのレンダラーで結合されたメッシュの送信とが関連付けられています。Each Renderer in Unity will have it's associated draw call(s) versus submitting a combined mesh under one Renderer.


Renderer.material の実行時のプロパティの変更とをマテリアルのコピーを作成し、したがってできなくなる可能性のバッチ処理します。Modifying properties of Renderer.material at runtime will create a copy of the Material and thus potentially break batching. Renderer.sharedMaterial を使用すると、Gameobject の間で共有の素材プロパティを変更できます。Use Renderer.sharedMaterial to modify shared material properties across GameObjects.

GPU のパフォーマンスに関する推奨事項GPU performance recommendations

詳細についてはUnity でのグラフィックス レンダリングの最適化Learn more about optimizing graphics rendering in Unity

ポリゴンの数を削減します。Reduce poly count

いずれかで多角形の数が減少通常Polygon count is usually reduced by either

  1. シーンからオブジェクトを削除します。Removing objects from a scene
  2. 指定したメッシュの多角形の数が減少する資産デシメーションAsset decimation which reduces the number of polygons for a given mesh
  3. 実装する、詳細レベル (LOD) のシステムを離れた同じジオメトリの多角形の下のバージョンを持つオブジェクトを描画するアプリケーションにImplementing a Level of Detail (LOD) System into your application which renders far away objects with lower-polygon version of the same geometry

制限を範囲します。Limit overdraw

Unity では、1 つを表示できますを切り替えることにより、そのシーンを描画できます、 モード メニューを描画の左上隅にある、シーン ビュー選択アルファブレンディング.In Unity, one can display overdraw for their scene, by toggling the draw mode menu in the top left corner of the Scene view and selecting Overdraw.

一般に、範囲を事前に、GPU に送信される前にオブジェクトをカリング軽減できます。Generally, overdraw can be mitigated by culling objects ahead of time before they are sent to the GPU. Unity を実装する方法の詳細を提供するオクルー ジョン カリングのエンジン。Unity provides details on implementing Occlusion Culling for their engine.

Unity でシェーダーを理解します。Understanding shaders in Unity

パフォーマンスでシェーダーを比較する簡単な近似は、各操作の平均数を識別するために実行時に実行します。An easy approximation to compare shaders in performance is to identify the average number of operations each executes at runtime. これは、Unity で非常に簡単に行うことができます。This can be done fairly easily in Unity.

  1. シェーダー資産を選択または素材を選択し、続いてインスペクター ウィンドウの上部右隅にある、歯車アイコンを選択し、 「シェーダーの選択」Select your shader asset or select a material, then in top right corner of the inspector window, select the gear icon and then "Select Shader"

    Unity でシェーダーを選択します。

  2. 選択したシェーダー アセット、クリックして、 「コンパイルし、コードの表示」 インスペクター ウィンドウの下のボタンWith the shader asset selected, click the "Compile and show code" button under the inspector window

    Unity でシェーダー コードをコンパイルします。

  3. コンパイルの後、結果に統計情報 セクションを検索、頂点とピクセル シェーダーのさまざまな操作の数 (注: ピクセル シェーダーでは、フラグメント シェーダーも多くの場合と呼ばれます)After compiling, look for the statistics section in the results with the number of different operations for both the vertex and pixel shader (Note: pixel shaders are often also called fragment shaders)

    Unity シェーダーの標準的な操作

Unity シェーダーの標準的な代替手段Unity Standard shader alternatives

効率的に利用して物理的にベースのレンダリング (PBR) やその他の高品質なシェーダーを使用せずに確認し、安価なシェーダー。Instead of using a physically based rendering (PBR) or other high-quality shader, look at utilizing a more performant and cheaper shader. 実際にはツールキットを混在を提供します、標準シェーダー複合現実プロジェクト向けに最適化されたをします。Mixed Reality Toolkit provides a standard shader that has been optimized for mixed reality projects.

Unity では、光源、なし、頂点が点灯している、高速比較が大幅に簡略化されたシェーダーの拡散、およびその他のオプションも、標準の Unity シェーダーに提供します。Unity also provides an unlit, vertex lit, diffuse, and other simplified shader options that are significantly faster compared to the Unity Standard shader. 参照してください使用状況と組み込みのシェーダーのパフォーマンスを詳細な情報。See Usage and Performance of Built-in Shaders for more detailed information.

メモリの推奨事項Memory recommendations

過剰なメモリの割り当てと割り当て解除の操作、holographic アプリケーションを一貫性のないパフォーマンス、固定されたフレーム、およびその他の好ましくない動作に影響を受けることができます。Excessive memory allocation & deallocation operations can have adverse effects on your holographic application resulting in inconsistent performance, frozen frames, and other detrimental behavior. これは、方法は、メモリ管理は、ガベージ コレクターによって制御されるため、Unity で開発するときは、メモリに関する考慮事項を理解するのには特に重要です。It is especially important to understand memory considerations when developing in Unity since memory management is controlled by the garbage collector.

ガベージ コレクションGarbage collection

Holographic アプリ、不要になったスコープの実行中にオブジェクトを分析する、GC がアクティブになるし、メモリにできる再利用できるようにリリースする必要があるガベージ コレクター (GC) の処理コンピューティング時間が失われます。Holographic apps will loose processing compute time to the garbage collector (GC) when the GC is activated to analyze objects that are no longer in scope during execution and their memory needs to be released so it can be made available for re-use. 定数の割り当てと割り当て解除したがって傷つけるパフォーマンスとユーザー エクスペリエンスをより頻繁に実行するガベージ コレクターが一般に必要です。Constant allocations and de-allocations will generally require the garbage collector to run more frequently thus hurting performance and user experience.

Unity は、ガベージ コレクターのしくみを詳しく説明する優れたページとメモリ管理においてより効率的なコードを記述するためのヒントを提供しています。Unity has provided an excellent page that explains in detail how the garbage collector works and tips to write more efficient code in regards to memory management.

過度なガベージ コレクションにつながる最も一般的なプラクティスの 1 つがコンポーネントおよび Unity 開発におけるクラスへの参照をキャッシュできません。One of the most common practices that leads to excessive garbage collection is not caching references to components and classes in Unity development. すべての参照は Start() または Awake() 中にキャプチャし、Update() LateUpdate() などの以降の関数で再利用する必要があります。Any references should be captured during Start() or Awake() and re-used in later functions such as Update() or LateUpdate().

その他のクイック ヒント:Other quick tips:

  • 使用して、 StringBuilder C#クラスで動的に実行時に複雑な文字列をビルドするにはUse the StringBuilder C# class to dynamically build complex strings at runtime
  • Debug.Log() アプリのすべてのビルド バージョンで引き続き実行時に不要になったときに呼び出しを削除しますRemove calls to Debug.Log() when no longer needed as they still execute in all build versions of an app
  • Holographic アプリは、一般に、大量のメモリを必要とする場合は、呼び出すことを検討してください System.GC.Collect() などのフェーズを読み込み中に、読み込みを提示するとき、または画面の切り替えIf your holographic app generally requires lots of memory, consider calling System.GC.Collect() during loading phases such as when presenting a loading or transition screen

オブジェクト プールObject pooling

オブジェクト プールは、オブジェクトの割り当て解除 (&)、継続的な割り当てのコストを削減する、一般的な手法です。Object pooling is a popular technique to reduce the cost of continuous allocations & deallocations of objects. これは、同一のオブジェクトの大きなプールを割り当てると、常に生成し、時間の経過と共にオブジェクトを破棄するのではなく、このプールから再アクティブでない、利用可能なインスタンスを使用して実行します。This is done by allocating a large pool of identical objects and re-using inactive, available instances from this pool instead of constantly spawning and destroying objects over time. オブジェクト プールは、アプリの中に変数の有効期間を持つ再利用可能なコンポーネントに適しています。Object pools are great for re-useable components that have variable lifetime during an app.

起動時のパフォーマンスStartup performance

小規模のシーンをアプリを起動しを使用する必要があります*SceneManager.LoadSceneAsync* を残りのシーンを読み込みます。You should consider starting your app with a smaller scene, then using SceneManager.LoadSceneAsync to load the rest of the scene. これにより、アプリをできる限り早く対話状態を取得できます。This allows your app to get to an interactive state as fast as possible. 対応をある可能性があります、大きな CPU スパイク新しいシーンがアクティブ化中に、レンダリングされたコンテンツが途切れこと」または「問題。Be aware that there may be a large CPU spike while the new scene is being activated and that any rendered content might stutter or hitch. これを回避する方法の 1 つは、読み込まれているシーンで AsyncOperation.allowSceneActivation プロパティを false に設定、読み込み、黒に画面のクリア、および、戻るシーンのアクティブ化が完了する場合は true に設定してシーンの待機です。One way to work around this is to set the AsyncOperation.allowSceneActivation property to false on the scene being loaded, wait for the scene to load, clear the screen to black, and then set back to true to complete the scene activation.

スタートアップ シーンの読み込み中に、holographic のスプラッシュ スクリーンは、ユーザーに表示されることに注意してください。Remember that while the startup scene is loading the holographic splash screen will be displayed to the user.

関連項目See also