All content in this course uses:

Unity UI の基礎概念やアルゴリズム、コードを学び、UI 最適化でよくある問題とその解決方法を理解します。

Unity UI の最適化

Unity UI によって駆動されるユーザーインターフェースを最適化することは、芸術的なことです。このチュートリアルでは、Unity UI の基盤となる基本的なコンセプト、アルゴリズム、コードについて説明するとともに、よくある問題とその解決策についても触れています。

Unity UI によって実装されたユーザーインターフェースの最適化はもはや芸術です。厳しいルールは殆どないですが、代わりにシステムの挙動を念頭に置いて、各状況を慎重に判断する必要があります。 Unity UI を最適化する際に最も重要なのは、ドローコールとバッチングコストのバランスをとることです。 一方または両方を減らす為には一般的なテクニックを活用する事が出来ますが、複雑な UI の場合はトレードオフを行わなければなりません。 

ただし、他のトピックでのベストプラクティスと同様に、Unity UI を最適化する際もプロファイリングから始めるべきです。Unity UI システムを最適化しようとする際は、まず、現在発生している問題の正確な原因を突き止めることが必要です。Unity UI のユーザーが遭遇する問題には、共通する以下の４つがあります：  

過大な GPU フラグメントシェーダの利用率 (フィルレート制限超えなど）

過大な Canvas バッチのリビルドに費やされたCPU時間

過大な Canvas バッチのリビルド数 (頻繁なキャッシュ更新、over-dirtying)

過大な 頂点生成に費やされた CPU 時間 (ほとんど原因はテキスト)

原則として、GPUへのドローコール数によってパフォーマンスが低下しても、Unity UI を生成する事は可能です。ただし、実際にはドローコールが増え GPU に過負荷が掛かるプロジェクトの場合、フィルレートの制限を超えてしまう可能性が高くなります。

このガイドでは、Unity UI の根底にある基本的な概念・アルゴリズム・コードについて触れ、またよくある問題や解決策について、５ つのチャプターに分けて説明します。

のチャプター：Unity UI 固有の用語を定義し、バッチジオメトリの構築など、UI をレンダリングするために実行される多くの基本的なプロセスの詳細について説明します。

このチャプターから読み始めることを強くおススメします。

Unity UI のプロファイリングツール

のチャプター：開発者が利用できる様々なツールを使ってプロファイリングデータを収集する方法について説明します。

フィルレート (Fill Rate)、キャンバス (Cavas)、入力 (input) 

のチャプター：Unity UI の Canvas と Input コンポーネントのパフォーマンスを向上させる方法について説明します。

のチャプター：UI Text、Scroll Views、その他のコンポーネント固有の最適化について説明し、これまでの項目で紹介できなかったテクニックも紹介しています。

その他の UI 最適化のテクニックとヒント

のチャプター：UI システムでの「落とし穴」に関する基本的なヒントと回避策など、これまでのチャプターでは説明出来なかった問題について説明しています。

Unity UI の Graphic コンポーネントと Layout コンポーネントは完全にオープンソースであることを常に忘れないでください。これらのソースコードは、 

Unity UI の最適化ガイド

Unity UI システムを構成するさまざまなパーツを理解することは重要です。いくつかの基本的なクラスとコンポーネントがあり、それらが組み合わさりシステムを構成しています。このチャプターでは、まずこのシリーズを通して使用される用語を定義し、次に Unity UI のキーとなるシステムについて、低レベル層での動作について説明します。

ネイティブコードの Unity コンポーネントで、Unity のレンダリングシステムで階層化されたジオメトリを提供する為に使用されます。そしてゲームのワールド空間の中、又は前面に描画されます。

Canvases は、それらの構成ジオメトリをバッチにまとめ、適切なレンダリングコマンドを生成し、Unity の Graphics システムに送信する役割を担っています。これらの作業はすべて C++ で書かれたネイティブコードで行われ、リバッチ (

またはバッチ (batch) ビルドと呼ばれます。Canvas に再配置が必要なジオメトリが含まれているとマークされているとき、その Canvas はダーティ (

ジオメトリは Canvas Renderer コンポーネントによって Canvas に提供されます。

Sub-canvas：単純に Canvas コンポーネント内にネストされた別の Canvas コンポーネントの事をいいます。Sub-canvas は 親 Canvas とは分離されているため、ダーティな Sub-canvas は親 Canvas にジオメトリを再構築させることはありません。逆もまた同様です。ただし、親 Canvas を変更すると Sub-canvas のサイズが変更されるなど、これが当てはまらないケースもあります。

Unity UI C＃ライブラリによって提供されるクラスであり、Canvas システムに描画可能なジオメトリを提供する全ての Unity UI C# クラスの基底クラスになっています。ビルトインの Unity UI Graphics の殆どは、 

 のサブクラスを介して実装されています。このサブクラスを使用すると、

 インターフェイスを介してマスクすることができます。

 があり、それぞれ同名のコンポーネントを提供します。 

Layout コンポーネント：RectTransform

 のサイズと位置の制御を担っており、相対的なサイズ変更や位置変更を必要とする複雑なレイアウトを作成する為に使用されます。Layout コンポーネントは、RectTransform にのみ依存し、関連する RectTransform プロパティにのみ影響を与えます。それらは Graphic クラスには依存せず、Unity UI の Graphic コンポーネントとは独立して使用できます。 

コンポーネントと Layout コンポーネント：このクラスは Unity エディターのインターフェースでは公開されていない 

クラスに依存しています。このクラスは更新が必要な Layout コンポーネントと Graphic コンポーネントのセットを追跡し、関連付けられた Canvas が 

イベントを呼び出すときに、必要に応じて更新をトリガーします。

Layout コンポーネントと Graphic コンポーネントの更新は、リビルド と呼ばれます。リビルドプロセスについては、このドキュメントの後半でさらに詳しく説明します。

Unity UI でユーザーインターフェースを作成する際には、Canvas で描画されたジオメトリはすべて Transparent キューに描画されることに留意してください。つまり、Unity UI によって生成されたジオメトリは、常に Alpha Blending （アルファブレンディング）が行われ奥から手前に順番に描画されます。パフォーマンスの観点から覚えておくべき重要なことは、ポリゴンからラスタライズされた各ピクセルが、たとえそれが他の不透明なポリゴンで完全に覆われていてもサンプリングされるということです。モバイルデバイスでは、このような高レベルのオーバードローは、GPU のフィルレート容量を急速に上回る可能性があります。

バッチビルドプロセス (Batch building process) とは、Canvas が UI 要素を表すメッシュを結合し、Unity のグラフィックスパイプラインに送る適切なレンダリングコマンドを生成するプロセスです。この処理の結果はキャッシュされ、Canvas がダーティであるとマークされるまで再利用されます。これは、キャンバスを構成するメッシュの１つにでも変更がある度に発生します。

Canvas で使用されるメッシュは、Canvas にアタッチされた Canvas Renderer コンポーネントのセットから取得されますが、Sub-canvas は含まれません。

バッチを計算するにはメッシュを深さ (depth) でソートし、重なりや共有されているマテリアルなどを調べる必要があります。この処理はマルチスレッドで行われるため、CPU アーキテクチャによってパフォーマンスが大きく異なります。特に、CPU コア数の少ないモバイル SoC と 4 コア以上の最新のデスクトップ CPU との間には大きな違いがあります。

リビルドプロセスでは、Unity UI の C# Graphic コンポーネントの Layout とメッシュが再計算されます。これは 

 クラスで実行されます。これは C# のクラスであり、そのソースは 

具体的には CanvasUpdateRegistry クラスの PerformUpdate メソッドが担っており、このメソッドは Canvas コンポーネントが 

 イベントを発生させるたびに呼び出されます。このイベントは１フレームにつき１回呼び出されます。

  メソッドは３つのプロセスを実行します：

ダーティな Layout コンポーネントは、レイアウトのリビルドを 

 メソッドを通して要求されます。

登録された Clipping コンポーネント (Mask など) は、クリップされたコンポーネントをカリングするよう要求されます。これは、ClippingRegistry.Cull メソッドによって行われます。

ダーティな Graphic コンポーネントは、グラフィカル要素のリビルドを要求されます。

Layout と Graphic のリビルドの場合、プロセスは複数のパートに分かれています。Layout のリビルドは 3 つ（PreLayout、Layout、PostLayout）で実行され、Graphic のリビルドは 2 つ（PreRender、LatePreRender）で実行されます。

1 つまたは複数の Layout コンポーネントに含まれるコンポーネントの適切な位置（および潜在的なサイズ）を再計算するには、適切な階層順に Layout を適用する必要があります。ゲームオブジェクト階層のルートに近い Layout は、自身が含んでいる Layout の位置とサイズを変更する場合がある為最初に計算する必要があります。

これを行うために、Unity UI はダーティな Layout コンポーネントのリストを、階層の深さでソートします。階層の上位アイテム (つまり、親の Transform コンポーネントが少ない)は、リストの先頭に移動されます。

ソートされた Layout コンポーネントリストは、次に　Layout をリビルドするよう要求されます。ここは、Layoutコンポーネントによって制御されている UI 要素の位置とサイズが実際に変更される場所です。個々の要素の位置がLayout によってどの様に影響を受けているかについては 

Graphic コンポーネントがリビルドされると、Unity UI は 

 メソッドに制御を渡します。Graphic クラスはこれを実装し、リビルドプロセスの PreRender ステージで 2 つの異なるリビルド ステップを実行します。

頂点データがダーティとマークされていた場合（例：コンポーネントの RectTransform のサイズが変更されたとき）は、メッシュがリビルドされます。

マテリアルデータがダーティとマークされていた場合（コンポーネントのマテリアルやテクスチャが変更された場合など）、アタッチされた Canvas Renderer のマテリアルが更新されます。

Graphic のリビルドは、Graphic コンポーネントのリストを特定の順序で処理しないため、ソート操作を必要としません。

Unity UI の基礎

 のパフォーマンスを分析するために使用できる便利なプロファイリングツールがいくつかあります。主なツールは次のとおりです：

Xcode のフレームデバッガーまたは Intel GPA

外部ツールは、ミリ秒（またはそれ以上）の解像度のメソッドレベルの CPU プロファイリング、および詳細なドローコールやシェーダーの詳細なプロファイリングも可能です。上記のツールを設定して使用する手順は、このガイドの範囲を超えています。Xcode フレームワークデバッガーとツールは Apple プラットフォームでの IL2CPP ビルドにのみ使用できるため、現時点では IOS ビルドのプロファイリングにのみ使用できることに注意してください。

Unity プロファイラー (Profiler) の主な目的は、比較プロファイリングを実行することです。Unity プロファイラーの実行中に UI 要素を有効にしたり無効にしたりすることで、パフォーマンスの問題に最も関与する UI 階層の部分を素早く絞り込むことができます。 

これを分析するには、 アナライザー出力の 

前述のように、Canvas.BuildBatch は、Canvas バッチビルドプロセスを実行するネイティブコード計算です。

Canvas.SendWillRenderCanvases には、サブスクライブされた Canvas コンポーネントの willRenderCanvases イベントを呼び出す C# スクリプトが含まれています。

クラスはこのイベントを受け取り、前述のようにそれを使ってリビルドプロセスを実行します。ダーティな UI コンポーネントは、この時点で Canvas Renderers を更新することが予想されます。

注：UI パフォーマンスの違いをより簡単に確認するには、通常、「レンダリング」、「スクリプト」、「UI」を除くすべてのトラッキングカテゴリーを無効にすることをお勧めします。

これは、CPU Usage プロファイラーの左側にある追跡カテゴリー名の横にある色付きのボックスをクリックすることで実行できます。また、カテゴリー名をクリックして上下にドラッグすることで、CPU プロファイラー内でカテゴリーの順序を変更することができます。

UI カテゴリーは、Unity 2017.1 以降で新しくなりました。残念ながら、UI の更新プロセスの一部は適切に分類されていないため、UI 曲線を見るときは注意してください。これには、UI 関連の呼び出しがすべて含まれているとは限りません。たとえば、

は「その他」と「レンダリング」に分類されます。

も登場しています。デフォルトでは、このプロファイラーは Profiler ウィンドウの最後に表示されます。これは、2 つのタイムラインとバッチビューアで構成されています：

最初のタイムラインは、計算レイアウトとレンダリングという 2 つのカテゴリーに使用される CPU 時間を示しています。前述と同じような問題が発生し、一部の UI 機能が考慮されていない可能性があることに注意してください。

2 番目のタイムラインには、バッチ、頂点、およびイベントマーカーの総数が表示されます。前のスクリーンショットでは、いくつかのボタンクリックイベントを見ることができます。これらのマーカーは、CPU 使用率の急上昇の原因を特定するのに役立ちます。

最後に、UI プロファイラーの最も便利な機能は、下部にある Batch ビューアです。左側にはすべての Canvas のツリービューがあり、各 Canvas の下には、それらが生成した Batch (バッチ) のリストが表示されています。これらの列には、各 Canvas や Batch に関する興味深い詳細を提供しますが、中でも UI の最適化方法をよりよく理解するために欠かせないものがあります。それが 

この列には、選択したバッチが前のバッチにマージできなかった理由が表示されます。バッチの数を減らすことは、UI のパフォーマンスを向上させる最も効果的な方法の 1 つであるため、バッチ処理ができない原因を理解することが重要です。

スクリーンショットに示されているように、最も頻繁に起こる理由の一つは、さまざまなテクスチャまたはマテリアルを持つ UI 要素の使用です。多くの場合、これは

を使用することで簡単に修正することができます。最後の列には、そのバッチに関連付けられているゲームオブジェクトの名前が表示されます。名前をダブルクリックすると、そのゲームオブジェクトをエディターで選択することができます（同じ名前のオブジェクトが複数ある場合には特に便利です）。

バッチビューアーはエディターでしか使えません

。バッチ処理は通常、デバイス上で同じであるべきなので、これは今でもとても便利です。もし、デバイス上でバッチが違うのではないかという疑問がある場合は、次に説明するフレームデバッガー (Frame Debugger) を使うことができます。

Unity フレームデバッガー (Frame Debugger) は、Unity の UI によって生成されるドローコールの数を減らすための便利なツールです。この組み込みツールは、Unity エディター内の Window メニューからアクセスできます。有効にすると、Unity UI で生成されたものを含め、Unity で生成されたすべてのドローコールが表示されます。

また、フレームデバッガーは、Unity エディターの Game ビューを表示するために生成されたドローコールで更新されるので、Play モードに入らなくても、様々な UI 設定を試すことができます。

Unity UI のドローコールの位置は、描画される Canvas コンポーネントで選択されている Render モードによって異なります：

Screen Space – Overlay は Canvas.RenderOverlays グループに表示されます。

Screen Space – Camera は、選択した Render Camera の Camera.Render グループ内に、Render.TransparentGeometry のサブグループとして表示されます。

World Spaceは、Canvas が表示されている World Space カメラごとに、Render.TransparentGeometry のサブグループとして表示されます。

すべての UI は、グループまたはドローコールの詳細にある「Shader: UI/Default」の行で識別できます（UI シェーダーがカスタムシェーダーに置き換えられていないことが前提です）。下のスクリーンショットでは、強調表示されている赤いボックスをご覧ください。

この一連の行を見ながら UI を微調整すると、比較的簡単に Canvas の能力を最大限に発揮して UI 要素をバッチにまとめることができます。バッチが壊れてしまう設計上の最も一般的な原因は、意図せずに重なってしまうことです。

Unity のすべての UI コンポーネントは、そのジオメトリを一連の 

 (クアッド)  として生成します。ただし、多くの UI スプライトや UI テキストグリフは、それらを表現するために使用されるクアッドのごく一部しか占めておらず、残りは空のスペースとなっています。その結果、UI デザイナーが誤ってテクスチャの素材が異なる複数のクアッドを重ねてしまい、バッチ処理ができなくなってしまうことがよくあります。

Unity UI は完全に透過キューで動作するため、その上にオーバーレイされた不安定なクアッドは、壊れないクアッドの前に描画する必要があります。したがって壊れないクアッドに配置された他のクアッドとバッチ処理することはできません。

A、B、C の 3 つのクアッドの場合を考えてみましょう。これらの 3 つのクアッドが互いに重なり合っていると仮定し、クアッド A と C が同じマテリアルを使用し、クアッド B が別のマテリアルを使用していると仮定します。そのため、クアッド B はA や C とバッチ処理することはできません。

階層の順番が上から順に A、B、Cとなっている場合、Bは A の上、C の下に描画する必要があるため、A と C をバッチ処理することはできません。ただし、B がバッチ可能なクアッドの前または後に配置されている場合、バッチ可能なクアッドは実際にバッチ処理できます。B はバッチ可能なクアッドの前か後に描画するだけでよく、挿入する必要はありません。

この問題については、Canvas の章、Child order セクションを参照してください。

Xcode の Instruments と Intel の VTune により、それぞれ Apple や Intel CPU で Unity UI のリビルドや Canvas のバッチ計算を極めて詳細にプロファイリングすることができます。このメソッド名は、前述の Unity Profiler セクションで説明したプロファイラーのラベルとほぼ同じです：

Canvas::SendWillRenderCanvases は、Canvas.SendWillRenderCanvases C# メソッドを呼び出し、Unity プロファイラーでその行を管理する C ++ の親です。

このコードには、前のステップで説明した Rebuild プロセスを実行するためのコードが含まれています。

Canvas::UpdateBatches は Canvas.BuildBatch と同じですが、Unity プロファイラーラベルではカバーされていない追加の定型コードが含まれています。これは、上記の実際の Canvas Batch Building プロセスを実行します。

IL2CPP を介してビルドされた Unity アプリと組み合わせて使用すると、これらのツールを使って、Canvas::SendWillRenderCanvases のトランスパイルされた C# コードをより深く掘り下げることができます。主な関心事は、以下の方法のコストです。（注：トランスパイルされたメソッド名は概算です。）

IndexedSet_Sort および CanvasUpdateRegistry_SortLayoutList は、レイアウトが再計算される前に、ダーティな Layout コンポーネントのリストをソートするために使用されます。

上記のように、これには各 Layout コンポーネントの上にある親トランスフォームの数を計算します。

ClipperRegistry_Cull は、IClipRegion インターフェースの登録済み実装者すべてを呼び出します。組み込みの Implementers には，IClippable インターフェースを使用する RectMask2D が含まれます。ClipperRegistry.Cull の呼び出し中、RectMask2D 

コンポーネントは、その階層内に含まれるすべてのクリッ可能な要素をループし、それらのカリング情報を更新するように要求します。

Graphic_Rebuild には、Image、Text、その他の Graphic から派生したコンポーネントを表現するために必要なメッシュを実際に計算するコストが含まれます。

など、いくつかのメソッドがあります。

Text_OnPopulateMesh は、通常 Best Fit モードが有効な場合、ホットスポットになります。これについては、このガイドの後半で詳しく説明します。

Shadow_ModifyMesh や Outline_ModifyMesh 

などのメッシュ修飾子もここで実行されます。コンポーネントのドロップシャドウ、アウトライン、その他の特殊効果を計算するコストは、これらの方法で確認できます。

低レベルのフレームデバッグツールは、バッチ処理された UI の個々の部分のコストをプロファイリングしたり、UI のオーバードローのコストを監視したりするために不可欠です。UI のオーバードローについては、このガイドの後半で詳しく説明します。

特定の UI が GPU に過度の負担をかけているかどうかをテストするには、Xcode の組み込み GPU 診断ツールを使用することができます。まず、対象となるプロジェクトを Metal または OpenGLES3 を使用するように設定し、ビルドを作成してできた Xcode プロジェクトを開きます。

Xcode のバージョンやデバイスの組み合わせによっては、OpenGLES 2 のフレームキャプチャーをサポートしている場合がありますが、それが動作するという保証はありません。

注：Xcode の一部のバージョンでは、Graphics プロファイラーを動作させるために、Build Scheme で適切なグラフィックス API を選択する必要があります。これを行うには、Xcode の Product メニューで Scheme メニュー項目を展開し、Edit Scheme....  を選択します。Run ターゲットを選択し、Options タブに移動します。

GPU Frame Capture オプションを、プロジェクトで使用されている API に合わせて変更します。Unity プロジェクトがグラフィックス API を自動的に選択するように設定されている場合、ほとんどの最新の iPad ではデフォルトで Metal が使用されます。疑わしい場合は、プロジェクトを起動して、Xcode のデバッグログを確認してください。初期の行の 1 つに、どのレンダリングパス（Metal、GLES3、GLES2）が初期化されているかが示されているはずです。

iOS デバイスでプロジェクトをビルドして実行します。GPUプロファイラーは、Xcode の Navigator サイドバーにある Debug ペインを表示し、FPS の Entry をクリックすることで確認できます。

GPU プロファイラーの最初の注目点は、画面中央にある「Tiler」、「Renderer」、「Device」と書かれた 3 本のバーのセットです。このうちの2つは：

「Tiler」は通常、ジオメトリを処理する際の GPU の負荷を示す指標で、頂点シェーダーにかかる時間も含まれます。一般的に、「Tiler」の使用率が高いということは、頂点シェーダーの処理速度が極端に遅いか、描画される頂点の数が多すぎることを示しています。

「Renderer」は通常、GPU のピクセルパイプラインにかかる負荷を示す指標です。一般に、「Renderer」の使用率が高い場合、アプリケーションが GPU の最大フィルレートを超えているか、フラグメントシェーダが非効率的であることを示しています。

「Device 」は、「Tiler」と「Renderer」の両方のパフォーマンスを含む、GPU 全体の使用量の複合尺度です。通常は、「Tiler」と「Renderer」のどちらか測定値の高い方を大まかに追跡するため、無視しても構いません。

Xcode の GPU プロファイラーの詳細については、

Xcode のフレームデバッガー (Frame Debugger) は、GPU プロファイラーの下部に隠れている小さな「Camera」アイコンをクリックすることでトリガーできます。次のスクリーンショットでは、矢印と赤いボックスで強調表示されています。

少し間を置くと、フレームデバッガーの概要ビューが以下のように表示されます：

デフォルトの UI シェーダーを使用する場合、Unity UI システムで生成されたジオメトリのレンダリングコストは、デフォルトの UI シェーダーがカスタムシェーダーで置き換えられていないことを前提に、「UI/Default」シェーダーパスの下に表示されます。上のスクリーンショットでは、Render Pipeline "UI/Default"として、このデフォルトの UI シェーダーを見ることができます。

Unity UI はクアッドのみを生成するため、頂点シェーダーが GPU の Tiler パイプラインに負荷を与えることはありません。このシェーダーパスで問題が発生した場合は、フィルレートの問題が原因と考えられます。

プロファイリングデータを収集した後、いくつかの結論を導き出すことができます。もし、

Canvas.BuildBatch や Canvas::UpdateBatches が

過剰に CPU 時間を消費しているようであれば、単一の Canvas 上にある Canvas Renderer コンポーネントの数が多すぎることが問題であると考えられます。Canvas の章の「the Splitting Canvases」セクションを参照してください。

GPU で UI を描画するのに過度の時間が費やされ、フレームデバッガーでフラグメントシェーダーパイプラインがボトルネックであることを示している場合、UI は GPU が可能なピクセルフィルレートを超えている可能性があります。最も考えられる原因は、過剰な UI のオーバードローです。フィルレート、キャンバス、入力の章の「the Remediating fill-rate issues」セクションを参照してください。

Canvas.SendWillRenderCanvases または Canvas :: SendWillRenderCanvases

 に行く CPU 時間の大部分に見られるように、Graphic Rebuilds が過剰なCPUを使用している場合は、より詳細な分析が必要です。Graphic Rebuilds プロセスの一部が原因である可能性があります。

WillRenderCanvas の大部分が IndexedSet_Sort や CanvasUpdateRegistry_SortLayoutList 

の中で使われている場合、ダーティな Layout コンポーネントのリストのソートに時間が費やされています。 Canvas 上の Layout コンポーネントの数を減らすことを検討してください。可能な修正方法については、「Replacing layouts with RectTransforms and Splitting Canvases」と「Splitting Canvases 」セクションを参照してください。

 に過剰な時間がかかっているようであれば、原因は単純にテキストメッシュの生成にあると考えられます。考えられる修正方法については、「Best Fit 」および「Disabling Canvases」セクションを参照してください。また、リビルドされるテキストの多くが実際にはその基礎となる文字列データを変更していない場合は、「Splitting Canvases」のアドバイスを検討してください。

Shadow_ModifyMesh や Outline_ModifyMesh（または ModifyMesh 

の他の実装）内で時間が費やされている場合、問題はメッシュモディファイアの計算に過剰な時間がかかっていることです。これらのコンポーネントを削除して、静止画像で視覚効果を得ることを検討してください。

内に特定のホットスポットがない場合や、毎フレーム実行されているように見える場合は、動的要素が静的要素と一緒にグループ化され、Canvas 全体を頻繁にリビルドさせていることが問題であると考えられます。「Splitting Canvases」のセクションを参照してください。

Unity UI プロファイリングツール

この章では、Unity UI を構築する上での幅広い問題について説明します。

フィルレートに関する問題の解決

GPUのフラグメント処理のパイプラインにかかる負荷を軽減するには、2 つの方法があります：

フラグメントシェーダーの複雑さを軽減します。詳細は「UI shaders and low-spec devices」のセクションを参照してください。

サンプリングする必要のあるピクセルの数を減らします。

UI シェーダーは一般的に標準化されているので、最も一般的な問題は、単純にフィルレートの過度の使用です。これの最も一般的な理由は、画面の重要な部分を占める多数の重複する UI 要素、または複数の UI 要素です。これらの問題は、どちらも非常に高いレベルのオーバードローにつながります。

フィルレートの過度の利用を緩和し、オーバードローを減らすために、以下のような改善策を検討してください。

既存の UI 要素の再設計が最も少ない方法は、プレイヤーに見えない要素を単純に無効化することです。 これが適用される最も一般的なケースは、背景が不透明なフルスクリーン UI を開く場合です。この場合、フルスクリーン UI の下に配置された UI 要素を無効にすることができます。

これの最も簡単な方法は、非表示の UI 要素を含むルートゲームオブジェクトか、ゲームオブジェクトを無効にすることです。代替ソリューションについては、「

」セクションを参照してください。

最後に、UI 要素の alpha を 0 に設定して、UI 要素が非表示になっていないことを確認します。要素は引き続き GPU に送信され、貴重なレンダリング時間がかかる可能性があるためです。UI 要素が Graphic コンポーネントを必要としない場合は、単にそれを削除してもレイキャスティングは機能します。

UI のリビルドとレンダリングにかかる時間を短縮するためには、UI オブジェクトの数をできるだけ少なくすることが重要です。なるべくベイクするようにしましょう。例えば、要素の色相を変更するためだけにブレンドされたゲームオブジェクトを使用しないで、代わりにマテリアルのプロパティを使ってください。また、フォルダーのようなゲームオブジェクトを作成して、シーンを整理する以外の目的を持たないようにしましょう。

背景が不透明なフルスクリーンの UI を開いた場合でも、ワールドスペースカメラは UI の背後にある標準的な 3D シーンをレンダリングします。レンダラーは、フルスクリーンの Unity UI が 3D シーン全体を覆い隠してしまうことを認識していません。

そのため、完全にフルスクリーンの UI が開かれている場合は、隠されたワールド空間のカメラをすべて無効にすることで、3D ワールドのレンダリングという無駄な作業がなくなり、GPU への負荷が軽減されます。

UI が 3D シーン全体をカバーしていない場合は、連続してレンダリングするのではなく、一度シーンをテクスチャにレンダリングしてそれを使用するとよいでしょう。3D シーン内のアニメーションコンテンツを見ることができなくなりますが、ほとんどの場合はこれで問題ないでしょう。

注：Canvas が「Screen Space – Overlay」に設定されている場合、シーン内でアクティブなカメラの数に関わらず描画されます。

多くの「フルスクリーン」UI は、実際には 3D ワールド全体が見えなくなるわけではなく、ワールドのごく一部が見えるようになっています。このような場合には、見えている部分だけをレンダリングテクスチャにキャプチャする方が最適な場合があります。ワールドの表示部分がレンダリングテクスチャに「キャッシュ」されていれば、実際のワールド空間のカメラを無効にして、キャッシュされたレンダリングテクスチャを UI 画面の背後に描画することで、3D ワールドの実例となるバージョンを提供することができます。

デザイナーは、標準的な背景や要素を組み合わせたり、重ねたりして、最終的な UI を作成するコンポジションを用いて UI を作成することがよくあります。この方法は比較的簡単で、反復作業には非常に適していますが、Unity UI では透過レンダリングキューを使用しているため、パフォーマンスが低下します。

背景、ボタン、ボタン上のテキストというシンプルな UI を考えてみましょう。透過キュー内のオブジェクトは後ろから前に向かってソートされるため、ピクセルがテキストグリフ内にある場合、GPU　は背景のテクスチャ、ボタンのテクスチャ、最後にテキストアトラスのテクスチャをサンプリングする必要があります。UI が複雑になり、背景に重ねる装飾要素が増えてくると、サンプル数が急激に増えてしまいます。

大きな UI がフィルレートの制限を受けていることが判明した場合、最良の手段は、UI の装飾的/不変的な要素の多くを背景テクスチャに統合する、特殊な UI スプライトを作成することです。これにより、目的のデザインを実現するために重ねなければならない要素の数を減らすことができますが、手間がかかり、プロジェクトのテクスチャアトラスのサイズも大きくなります。

ある UI を作るために必要なレイヤー要素の数を、専用の UI スプライトに凝縮するというこの原理は、サブ要素にも使えます。製品のスクロールペインを持つストアの UI について考えてみましょう。各製品の UI 要素には、境界、背景、そして価格や名前などの情報を示すアイコンがあります。

ストア UI には背景が必要ですが、製品が背景を横切るようにスクロールするため、製品要素をストア UI の背景テクスチャにマージすることはできません。ただし、製品の UI 要素の境界、価格、名前などの要素は、製品の背景にマージすることができます。アイコンのサイズや数にもよりますが、フィルレートの削減効果はかなり大きいです。

レイヤー要素を組み合わせるには、いくつかの欠点があります。特殊な要素は再利用できなくなり、作成にはアーティストの追加リソースが必要になります。特に UI テクスチャがオンデマンドでロード/アンロードされない場合、大きな新しいテクスチャを追加すると、UI テクスチャを保持するために必要なメモリ量が大幅に増加する可能性があります。

シェーダーとロースペックデバイス

Unity UI で使用されているビルトインのシェーダーは、マスキング、クリッピング、その他多くの複雑な操作をサポートしています。この複雑さのために、iPhone 4 などのローエンドデバイスでは、UI シェーダーは、よりシンプルな Unity 2D シェーダーに比べてパフォーマンスが低下します。

ローエンドデバイスを対象としたアプリケーションで、マスキングやクリッピングなどの「派手な」機能が不要な場合は、下記のような最小限の UI シェーダのように、不要な処理を省いたカスタムシェーダを作成することも可能です：

<pre> Shader "UI/Fast-Default" { Properties { [PerRendererData] _MainTex ("Sprite Texture", 2D) = "white" {} _Color ("Tint", Color) = (1,1,1,1) }

任意の UI を表示するために、UI システムは、画面上に表現される各 UI コンポーネントのジオメトリを構築する必要があります。これには、動的レイアウトコードの実行、UI テキスト文字列内の文字を表現するポリゴンの生成、ドローコールを最小限にするために可能な限り多くのジオメトリを単一のメッシュへのマージなどが含まれます。これは複数のステップで構成されており、本ガイドの冒頭にある 

セクションで詳しく説明しています。

Canvas のリビルドがパフォーマンスの問題になるのは、主に 2つの理由があります：

Canvas 上の描画可能な UI 要素の数が多い場合、バッチの計算自体が非常に高価になります。これは、要素をソートして分析するコストが、Canvas 上の描画可能な UI 要素の数に比べて線形的に大きくなるためです。

Canvas が頻繁にダーティとしてマークされると、比較的変更の少ない Canvas のリフレッシュに過剰な時間がかかってしまうことがあります。

いずれの問題も、Canvas上の要素数が増えれば増えるほど顕著になる傾向があります。 

重要な注意：キャンバス上の描画可能な UI 要素が変更された場合、そのキャンバスはバッチビルドプロセスを再実行する必要があります。このプロセスでは、Canvas 上のすべての描画可能な UI 要素が変更されたかどうかにかかわらず、再分析されます。

スプライトレンダラーに割り当てられたスプライト、トランスフォームの位置やスケール、テキストメッシュに含まれるテキストなど、UI オブジェクトの外観に影響を与えるあらゆる変更を「変更」と呼ぶことに注意してください。

Unity UI は後ろから前に描画され、ヒエラルキーでの表示順と同じ順に描画されます。ヒエラルキーの前にあるオブジェクトは、オブジェクトの背面にあるオブジェクトと考えられます。2 つの UI 要素が重なっている場合、後から描画した UI 要素は先に描画した UI 要素の上に表示されます。バッチは、ヒエラルキーを上から下に向かって移動し、同じマテリアル、同じテクスチャを使用し、中間レイヤーを持たないすべてのオブジェクトを収集することで構築されます。「中間レイヤー」とは、異なるマテリアルを持つグラフィックオブジェクトで、そのバウンディングボックスは他の 2 つのバッチ可能なオブジェクトと重なり、2 つのバッチ可能なオブジェクトの間のヒエラルキーに配置されます。中間レイヤーがあると、バッチを強制的に中断します。

Unity UI Profiling Tools のステップで説明したように、UI プロファイラーとフレームデバッガを使って、UI の中間レイヤーを検査することができます。これは、ある描画可能なオブジェクトが、他のバッチ可能な 2 つの描画可能なオブジェクトの間に介在する状況です。

この問題は、テキストとスプライトが近くに配置されている場合によく発生します。テキストグリフのポリゴンの多くは透明であるため、テキストのバウンディングボックスが近くのスプライトに見えないように重なってしまうのです。この問題は 2つの方法で解決できます：

バッチ可能なオブジェクトがバッチ不可能なオブジェクトに邪魔されないように、つまり、バッチ不可能なオブジェクトをバッチ可能なオブジェクトの上または下に移動させるように、描画可能なオブジェクトを並べ替えます。

目に見えない重なり合う空間をなくすために、オブジェクトの位置を調整します。

これらの操作はいずれも、Unity フレームデバッガーを開いて有効にした状態で、Unity エディターで行うことができます。Unity フレームデバッガーで見えるドローコールの数を観察するだけで、UI 要素が重なることで無駄になるドローコールの数を最小限に抑えることができる順番や位置を見つけることができます。

非常に些細なケースを除いて、一般的には Canvas (キャンバス) を分割して、要素を Sub-canvas (サブキャンバス) や兄弟 Canvas に移動させるのが良い方法です。

兄弟 Canvas は、UI の特定の部分の描画の深さを他の部分とは別に制御し、常に他のレイヤーの上または下に配置する必要がある場合に最適です（チュートリアルの矢印など）。

それ以外のほとんどの場合、Sub-canvas は親 Canvas の表示設定を継承するため、より便利です。

一見すると、UI を多くの Sub-canvas に分割することがベストプラクティスのように思えますが、Canvas システムでは、別々の Canvas でバッチを結合することはできないことを覚えておいてください。パフォーマンスの高い UI 設計には、リビルドのコストを最小限に抑えることと、無駄なドローコールを最小限に抑えることのバランスが必要です。

キャンバス (Canvas) は、その構成要素である Drawable コンポーネントが変更されるたびにリバッチされるので、一般的には、重要なキャンバスは少なくとも 2つの部分に分割するのがベストです。また、要素が同時に変更されることが予想される場合は、同じキャンバス上に要素を配置することをお勧めします。例えば、プログレスバーとカウントダウンタイマーがあります。これらはどちらも同じ基礎データに依存しており、同時に更新が必要となるため、同じキャンバスに配置する必要があります。

1 つ目のキャンバスに、背景やラベルなど、静的で不変の要素をすべて配置します。これらの要素は、Canvas が最初に表示されたときに一度バッチ処理され、その後はリバッチ処理の必要がなくなります。

2 つ目のキャンバスには、頻繁に変化する「動的」な要素をすべて配置します。これにより、このキャンバスでは主にダーティな要素がリバッチされることになります。動的要素の数が非常に多くなった場合は、動的要素を、常に変化する要素（プログレスバー、タイマーの表示、アニメーションなど）と、時々しか変化しない要素にさらに細分化する必要があるかもしれません。

これは実際にはかなり難しいことで、特に UI コントロールをプレハブにカプセル化している場合はなおさらです。多くの UI では、コストのかかるコントロールをサブキャンバスに分割してキャンバスを細分化しています。

Unity 5.2では、バッチコードが大幅に書き直され、Unity 4.6、5.0、5.1 に比べてかなりパフォーマンスが向上しています。さらに、1つ以上のコアを持つデバイスでは、Unity UI システムは処理のほとんどをワーカースレッドに移します。一般的に、Unity 5.2 は、UI を多数のサブキャンバスに積極的に分割する必要性を減らします。モバイルデバイス上の多くの UI は、2つまたは 3つのキャンバスだけでパフォーマンスを発揮できるようになりました。

Unity 5.2 の最適化に関する詳細は、

Unity UI での入力とレイキャスティング

 コンポーネントを使用して、タッチイベントやポインターイベント (ホバー) などの入力イベントを処理します。これは通常、Standalone Input Manager コンポーネントによって処理されます。Standalone Input Manager は、その名前に反して、「ユニバーサル」な入力マネージャーシステムであり、ポインターとタッチの両方を扱うことができます。

モバイルでの誤ったマウス入力検知 (5.3)

Unity 5.4 以前では、Graphic Raycaster がアタッチされた各アクティブな Canvas は、現在利用可能なタッチ入力がない限り、フレームごとに 1 回レイキャストを実行してポインターの位置を確認していました。これは、プラットフォームに関係なく発生します。マウスを持たない iOS および Android デバイスは、マウスの位置を query し、その位置の下にある UI 要素を検出してホバーイベントを送信する必要があるかどうかを判断します。

これは CPU 時間の浪費であり、Unity アプリケーションの CPU フレーム時間の 5 %以上を消費していることが確認されています。

この問題は、Unity 5.4 で解決されています。

5.4 以降、マウスを搭載していないデバイスでは、マウスの位置を query したり、不要なレイキャストを実行しないようになりました。

5.4 以前のバージョンの Unity を使用している場合、モバイル開発者は独自の Input Manager クラスを作成することを強く推奨されます。これは、Unity UI ソースから Unity の Standard Input Manager をコピーして、ProcessMouseEvent メソッドとそのメソッドへのすべての呼び出しをコメントアウトするのと同じくらい簡単に出来ます。

Graphic Raycaster は比較的簡単な実装で、「Raycast Target」設定が true に設定されているすべての Graphic コンポーネントについて繰り返し処理を行います。各 Raycast ターゲットに対して、Raycaster は一連のテストを実行します。Raycast ターゲットがすべてのテストに合格すると、ヒットリストに追加されます。

Raycast ターゲットがアクティブな（つまりジオメトリがある）場合は有効にして描画します

入力ポイントが Raycast ターゲットにアタッチされている RectTransform 内にある場合

Unity 버전 2017.3