Unityでパフォーマンスの良いUIを作る為のTips

Unityでパフォーマンスの良いUIを作る為のTips

• 1.
  Unityでパフォーマンスの 良いUIを作るためのTips Tatsuhiko Yamamura @Unity ver 1.1
• 2.
  お品書き • UnityのUIシステムおさらい • パフォーマンスの良いUIの為に注意すべきこと •バッチング • フィルレート • リビルド • その他
• 3.
  Unity UI
• 4.
  Unity UI • UnityUI、通称UGUI • Unity 4.6のタイミングで追加 • オープンソースで開発
 https://bitbucket.org/Unity-Technologies/ui/ • 当時はNGUIというアセット（有料）を殆どの人が使用していた • NGUI開発者が中の人になって一緒に開発
• 5.
  uGUIの機能 • Text • Image •Raw Image • Button • Toggle • Slider • etc • Basic Layout • Layout Group • etc ビジュアル表現 インタラクション レイアウト uGUIには結構いろいろな機能がある
• 6.
  UGUIの機能 • 基本的なレイアウト • 自動レイアウト •ビジュアル表現 • インタラクション
• 7.
  UGUIの機能 • 基本的なレイアウト • 自動レイアウト •ビジュアル表現 • インタラクション
• 8.
  UGUIの機能 • 基本的なレイアウト • 自動レイアウト •ビジュアル表現 • インタラクション https://github.com/mob-sakai/UIEffect
• 9.
  UGUIの機能 • 基本的なレイアウト • 自動レイアウト •ビジュアル表現 • インタラクション
• 10.
  全自動
 UI最適化ボタン 結構、なんとなくで作れてしまうUIシステム、 ただしパフォーマンスも担保してくれるかというと、微妙にしてくれない。 全自動最適化ボタンは無い。
• 11.
  パフォーマンス柔軟性 柔軟性とパフォーマンスはトレードオフ 実際に標準の機能を使用せず、自作する必要も出てくる
• 12.
  バッチング
• 13.
  描画処理 サンプル　キャラクター サンプル　キャラクター サンプル　キャラクター 描画は奥から順にスタンプのように貼り付けていくイメージ
• 14.
  描画する流れ Texture Material (+Shader) Polygon 描画 描画は基本のポリゴンと同じく、マテリアルでポリゴンを塗る方式
• 15.
  複数繰り返す 描画処理をたくさん繰り返すのは効率が悪い
• 16.
  Canvasに一旦まとめる Canvas マテリアル テクスチャ UIのレイアウト 結合したポリゴン 平面上の要素なので、多少楽をしている（らしい）　※まとめるのはHierarchyではなく実際の描画ベース
• 17.
  まとめて一回で描画（バッチング） まとめたポリゴンを一気に描画すれば、大量に描画しても負荷はソコソコ
• 18.
  一括描画できるのは
 同じテクスチャのみ 異なるマテリアルの場合、異なるポリゴンを用意して描画（バッチが解ける）
• 19.
  入れ子のせいで
 バッチングできない スプライトが入れ子になるとバッチング出来なくなる　※Hierarchyではなく描画ベースの入れ子
• 20.
  入れ子のせいで
 バッチングできない テクスチャが同じでもマテリアルが異なるとバッチング出来ない
• 21.
  バッチが可能な条件 • 同じCanvasに所属している • 同じMaterialを使用している •同じTextureを参照している • 座標のZ値が同じ位置にあること • 同じマスクでクリップされていること（RectMask2Dの場合） バッチングの為には全ての条件を満たす必要がある
• 22.
  UI Profilerで観察 確認 方法バッチングが解けてるかどうかはUI Profilerで確認　（Unity2017.1から）
• 23.
  バッチ一覧 バッチで
 まとめた
 UI 描画一覧と、バッチでまとめたUIの一覧を確認できる
• 24.
  バッチ出来ない理由 テクスチャが違う バッチが解ける理由も表示される
• 25.
  Sprite Atlas 対策 バッチをまとめたい場合はSpriteAtlasにまとめる
• 26.
  参照するテクスチャが
 同じなので、バッチングが出来る Sprite Atlasで
 一つのテクスチャにまとめる UVの異なる矩形ポリゴン 一枚のテクスチャにまとめれば、同じマテリアルで複数のUIを表示出来る
• 27.
  違うタイプのキャラクターが
 混ざっても１回で描画できている 実際の描画の様子
• 28.
  元画像 なにか違う… 右はオリジナル、左はSpriteAtlasで取得したスプライト。妙な模様が追加されている
• 29.
  スプライトをミッチリと詰めた為に発生。UIは基本的に矩形なので、ミッチリ詰めると発生
• 30.
  余裕を持って
 配置する 対策 対策１：Tight Packingを止めて、余裕を持って配置
• 31.
  Imageを矩形ではなく
 ポリゴンで描画する
 （Unity 2018.3から） 対策 対策２：矩形ではなくポリゴンを使用して描画
• 32.
  バッチング対策 • バッチの条件を満たす • テクスチャをパックする •マスクの使用は抑える 対策
• 33.
  フィルレート
• 34.
  ポリゴンに色を塗る際は
 １ピクセルずつ塗っていく ポリゴンを表示し、色を画面（スクリーン）の１ピクセルずつ塗っていく。これをマテリアル単位でGPUで一括で行う
• 35.
  沢山のUIがある場合 重なって表示している場合に問題になる。
• 36.
  沢山のUIがある場合 複数回塗られている 透明は「描画しない」ではなく「透明を塗る」なので、重なっている部分が複数回塗られる（オーバードロー）
• 37.
  UI Profiler
 （Composite Overdraw) 確認 方法UIProfilerのCompsiteOverdrawで確認できる。色が赤に濃いほど負荷が高い
• 38.
  UI Profilerで確認しているの図
• 39.
  オーバードロー対策 • 不要なUIを排除 • 重なる部分を出来るだけ削る •Sprite Meshを使用 • Fill Centerを外して、中央をくり抜く • オーバードローしても問題ないシェーダーを使う sprite mesh使用 通常のquad 対策
• 40.
  • シェーダーの負荷は
 各デバイスのプロファイラーで 確認する • XCodeはいいぞ
• 41.
  UIのリビルド
 （ジオメトリ）
• 42.
  Canvasに一旦まとめる Canvas マテリアル テクスチャ UIのレイアウト バッファ 前述の通り、Canvasは一旦描画するUIのポリゴンをまとめて、バッファを生成。　バッファは基本使い回される
• 43.
  2300個のImage 殆ど負荷がかからない 単一描画になるので効率よく描画できる。バッチング出来ているなら殆どCPUに負荷がかからない（iPadPro1stで検証）
• 44.
  変化があれば再構築が必要 Canvas マテリアル テクスチャ UIのレイアウト バッファバッファ 更新 更新 更新 UIを動かすと以前のバッファを使い回せなくなるので、バッファを作り直す必要がある
• 45.
  バッファの再構築は即時ではない Update LateUpdate PostRate Update SendWillRenderCanvasesSetDirty 変化した内容に応じて Dirtyフラグを付ける UIを再構築 Canvas バッファは即時反映ではなく、変化した物にDirtyフラグをセット、溜めて一括処理する
• 46.
  再構築の条件 • UIをenable/disable • マテリアルが変化 •RectTransformのサイズが変化 • Transformの親が変化 UI再構築の条件は結構緩く、簡単に再構築が走る
• 47.
  一つ変わると、同じCanvasの全ての UIを再構築する Set Dirty 同じCanvasが全て
 更新対象に ジオメトリはCanvas単位で管理しているので、一つでも変更があれば同Canvas全てに影響する
• 48.
  このUIのどれかが動けば、背景のUIにリビルドが走る
• 49.
  メインスレッドの
 処理は少ない Canvas内のサイズによってジオメトリの再構築に時間がかかる 配置により
 ソートに時間がかかる ジオメトリの再構築はメインスレッドではない為、即座にフレームが落ちる訳ではない（テキスト…フォントの取得は除く）。ただし
 ジオメトリ生成完了までレンダースレッドが遅延するので、量によっては固まる。また、他のジョブ進行にも影響する。
• 50.
  確認 方法 UI Profilerが動いている 動いていなければ静か 確認方法 UI Profilerで確認出来る
• 51.
  Profilerでも分かりやすい 確認 方法 通常のプロファイラーでもUGUIRenderingが伸びるので確認できる
• 52.
  CPU Profiler（Hierarchy）で OnDidApplyAnimationPropertiesや OnRectTransformDimensionsChangeで検索 追加表示項目を変更
 ShowRelated Objects（関連オブジェクトを表示） UI再構築してそうなの一覧が表示される 確認 方法 UIのEventSystemでUIが動いている場合、誰がUIを動かしたのかを確認できる
• 53.
  Canvasを分割 対策 対策１：SubCanvasを作りジオメトリを分割する
• 54.
  Set Dirty Static Canvas DynamicCanvas 違うCanvasなのでリビルド対象外 Canvasを分割 Canvasを分割することで、UIを動かしてもジオメトリの再構築範囲を限定できる
• 55.
  （Canvasのジョブ完了待ちが
 消えた効果もある） Canvas分割の効果。UIのソートやジオメトリの生成コストが殆ど無くなる
• 56.
  動くUIはImageのSprite Meshを避ける use spritemesh : enable 3.22ｍｓ use sprite mesh : disable 0.4ｍｓ対策 SpriteMeshはポリゴンが多く、ジオメトリ生成のコストが上がる。動かすUIには使わない方が無難
• 57.
  親UIを動かす element element element element element element element root 親Transformを動かした場合もUIの再構築が走る。　ScreenSpaceCameraを使用している場合、よく起こる
• 58.
  動かしたタイミングで負荷 確認 方法 UIProfilerでRenderの山ができている場合はコレ
• 59.
  • 要素数を減らす • 要素をプーリングして
 最小限のUIでどうにかする 対策 コレといった対策は無い。　動くCanvasには要素はあまり突っ込まないのが良い
• 60.
  UIのリビルド
 （Layout Group）
• 61.
  RectTransform 子の RectTransform 子のRectTransform 子 の RectTransform 子の RectTransform LayoutGroupは、例えばRectTransformの中に大量のUIがある時、
• 62.
  RectTransform
 ILayoutGroup 子のRectTransform 子のRectTransform 子のRectTransform 子のRectTransform ILayoutGroupで
 子RectTransformの情報を収集し 子オブジェクトを自動的に並べてくれる（レイアウトする）機能
• 63.
  RectTransform
 ILayoutGroup ILayoutSelfController 子のRectTransform 子のRectTransform 子のRectTransform 子のRectTransform ILayoutSelfControllerで
 子RectTransformの情報を元に
 自分のオブジェクトのサイズを変更する 子オブジェクトの情報を元に、親（自身）のサイズを調整することも可能
• 64.
  RectTransform
 ILayoutGroup ILayoutSelfController 子のRectTransform 子のRectTransform 子のRectTransform 子のRectTransform 要素が増えても
 自動的に対応子のRectTransform 子のRectTransform 要素が増えたりサイズが変わっても対応できる、柔軟性を持つ
• 65.
  うまく組み合わせれば、横に伸びて縦に要素を加算するUI…みたいなものも作れる
• 66.
  特にScroll Viewとかでよく使われる機能
• 67.
  Dirty System Layout 
 Group Element Element Element Element UILayoutもDirtySystemを使用して実現している
• 68.
  Dirty System Layout
 Group Element Element Child Child DirtyElement UIの変更があればDirty　（この例では緑のElementのサイズを変更）
• 69.
  Child Dirty System Layout
 Group Element Element Element リビルド申請 DirtyしたUIから親LayoutGroupへ、レイアウトの再構築を申請
• 70.
  Element Dirty System Layout
 Group Element Element Element 再レイアウト あとで一斉にUIを再レイアウトする
• 71.
  Dirty System Layout
 Group Element Element Element Layout
 Group Layout
 Group Element Element Element リビルド申請 Element 複数のLayoutGroupがある場合は
• 72.
  Dirty System Layout
 Group Element Element Element Layout
 Group Layout
 Group Element Element ElementElement LayoutGroupの親まで到達して、そこから再レイアウト （なので、途中で自身のサイズを変えるContentSizeFitterはLayoutGroupの間に挟むと具合が悪い）
• 73.
  Groupの更新 Layout
 Group Element Element Element Layout
 Group Layout
 Group Element Element ElementElement parent.GetComponents() parent.GetComponents() rect.GetComponents() この親LayoutGroupへの通知は、毎回GetComponentを使用。子のレイアウト変更にもGetComponentを使用。
 地味に負荷になる
• 74.
  DirtyするUIが紛れ込むだけで
 毎フレーム、UIのリビルドが走る 一つでもDirtyするUIが含まれると、毎回Layoutの再構築。　これはメインスレッドで実行され、妙に高い負荷になる
• 75.
  UI Profilerが動いている 動いていなければ静か 確認方法 確認 方法 再レイアウトが起こっている場合、UI ProfilerのLayoutが大きく変化する
• 76.
  メインスレッドで処理されるため、大きな負荷と認識される事が多いです。 再レイアウト処理
• 77.
  • RectTransformに関連するものを操作しない
 （結果は変化しなくとも、セットするだけでリビルドが走る） • LayoutPropertyに関連するものを操作しない • UI Element関連を操作しない • Mecanimのステートマシンに、上記の要素にアクセスする
 AnimationClipを入れない
 （Simple Animationなら多分OK） 対策
• 78.
  対策 もしUIのインタラクティブな機能（ScrollViewとかButtonとか）から呼び出している場合、ProfilerのUI Detailで
 誰が呼び出しているのか確認できる
• 79.
  LayoutGroupを
 可能な限り使わない 対策
• 80.
  その他
• 81.
  TextコンポーネントのTextを変更する際にメインスレッドでフォント取得処理が発生　（※変更しなければ発生しない）
 Textコンポーネント１つなら問題無いが、大量にあると負荷になる 500個のUI.Textコンポーネントのtextを変更 その他 Font.CacheFontForText
• 82.
  その他 • Raycast Targetは可能な限り外す •World Space CameraのEvent Cameraにはカメラを登録する
 （無い場合はFindTag(“MainCamera”)を呼ばれる • Pixel Perfect設定は動かないカメラのみ設定する • テクスチャは画面解像度に合ったものを使う、
 可能な限り圧縮する
• 83.
  その他 • UI Profilerはエディターのみ動作 •ＸＣｏｄｅ等のデバイス専用プロファイラーは
 詳しい情報を収集できて便利 • 負荷を見るならビルドする
 Windows向けでも、多くのノイズを取り除いてくれる
 （実機で確認するのがベターではある）
• 84.
  まとめ
• 85.
  ポイント • 動かさなければ負荷は低い • 動かすなら最低限の影響に抑える •ドローコールとフィルレート、バッチング。　良いバランスを取る •気を抜くな！誰も信用するな！ プロファイラーを手放すな！
• 86.
  UI Element(Runtime) Coming Soon
• 87.
  おしまい