Anúncio
![Unity 2018-2019を見据えたDeNAのUnity開発のこれから [DeNA TechCon 2019]](https://cdn.slidesharecdn.com/ss_thumbnails/techcon2019harutootake-190218063853-thumbnail.jpg?width=600&height=600&fit=bounds)
Unityでパフォーマンスの良いUIを作る為のTips
22 de Jan de 2019•0 gostou•79,295 visualizações
36 gostaram
Seja o primeiro a gostar disto
mostrar mais
visualizações
Vistos totais
0
No Slideshare
0
De incorporações
0
Número de incorporações
0
Baixar para ler offline
Denunciar
Tecnologia
UnityのUIとはどういったシステムなのか、そして最適化する上で確認すべきポイントとTipsを紹介します。 --- このスライドは、「TECHxGAME COLLEGE#10 Unityでパフォーマンスの良いUIを作る為のTips」で紹介したスライドを少し手直ししたものとなります。 https://techxgamecollege.connpass.com/event/99824/
Unity Technologies Japan K.K.
Anúncio
Unityでパフォーマンスの良いUIを作る為のTips
- Unityでパフォーマンスの 良いUIを作るためのTips Tatsuhiko Yamamura @ Unity ver 1.1
- お品書き • UnityのUIシステムおさらい • パフォーマンスの良いUIの為に注意すべきこと • バッチング • フィルレート • リビルド • その他
- Unity UI
- Unity UI • Unity UI、通称UGUI • Unity 4.6のタイミングで追加 • オープンソースで開発 https://bitbucket.org/Unity-Technologies/ui/ • 当時はNGUIというアセット（有料）を殆どの人が使用していた • NGUI開発者が中の人になって一緒に開発
- uGUIの機能 • Text • Image • Raw Image • Button • Toggle • Slider • etc • Basic Layout • Layout Group • etc ビジュアル表現 インタラクション レイアウト uGUIには結構いろいろな機能がある
- UGUIの機能 • 基本的なレイアウト • 自動レイアウト • ビジュアル表現 • インタラクション
- UGUIの機能 • 基本的なレイアウト • 自動レイアウト • ビジュアル表現 • インタラクション
- UGUIの機能 • 基本的なレイアウト • 自動レイアウト • ビジュアル表現 • インタラクション https://github.com/mob-sakai/UIEffect
- UGUIの機能 • 基本的なレイアウト • 自動レイアウト • ビジュアル表現 • インタラクション
- 全自動 UI最適化ボタン 結構、なんとなくで作れてしまうUIシステム、 ただしパフォーマンスも担保してくれるかというと、微妙にしてくれない。 全自動最適化ボタンは無い。
- パフォーマンス柔軟性 柔軟性とパフォーマンスはトレードオフ 実際に標準の機能を使用せず、自作する必要も出てくる
- バッチング
- 描画処理 サンプル キャラクター サンプル キャラクター サンプル キャラクター 描画は奥から順にスタンプのように貼り付けていくイメージ
- 描画する流れ Texture Material (+Shader) Polygon 描画 描画は基本のポリゴンと同じく、マテリアルでポリゴンを塗る方式
- 複数繰り返す 描画処理をたくさん繰り返すのは効率が悪い
- Canvasに一旦まとめる Canvas マテリアル テクスチャ UIのレイアウト 結合したポリゴン 平面上の要素なので、多少楽をしている（らしい） ※まとめるのはHierarchyではなく実際の描画ベース
- まとめて一回で描画（バッチング） まとめたポリゴンを一気に描画すれば、大量に描画しても負荷はソコソコ
- 一括描画できるのは 同じテクスチャのみ 異なるマテリアルの場合、異なるポリゴンを用意して描画（バッチが解ける）
- 入れ子のせいで バッチングできない スプライトが入れ子になるとバッチング出来なくなる ※Hierarchyではなく描画ベースの入れ子
- 入れ子のせいで バッチングできない テクスチャが同じでもマテリアルが異なるとバッチング出来ない
- バッチが可能な条件 • 同じCanvasに所属している • 同じMaterialを使用している • 同じTextureを参照している • 座標のZ値が同じ位置にあること • 同じマスクでクリップされていること（RectMask2Dの場合） バッチングの為には全ての条件を満たす必要がある
- UI Profilerで観察 確認 方法バッチングが解けてるかどうかはUI Profilerで確認 （Unity 2017.1から）
- バッチ一覧 バッチで まとめた UI 描画一覧と、バッチでまとめたUIの一覧を確認できる
- バッチ出来ない理由 テクスチャが違う バッチが解ける理由も表示される
- Sprite Atlas 対策 バッチをまとめたい場合はSpriteAtlasにまとめる
- 参照するテクスチャが 同じなので、バッチングが出来る Sprite Atlasで 一つのテクスチャにまとめる UVの異なる矩形ポリゴン 一枚のテクスチャにまとめれば、同じマテリアルで複数のUIを表示出来る
- 違うタイプのキャラクターが 混ざっても１回で描画できている 実際の描画の様子
- 元画像 なにか違う… 右はオリジナル、左はSpriteAtlasで取得したスプライト。妙な模様が追加されている
- スプライトをミッチリと詰めた為に発生。UIは基本的に矩形なので、ミッチリ詰めると発生
- 余裕を持って 配置する 対策 対策１：Tight Packingを止めて、余裕を持って配置
- Imageを矩形ではなく ポリゴンで描画する （Unity 2018.3から） 対策 対策２：矩形ではなくポリゴンを使用して描画
- バッチング対策 • バッチの条件を満たす • テクスチャをパックする • マスクの使用は抑える 対策
- フィルレート
- ポリゴンに色を塗る際は １ピクセルずつ塗っていく ポリゴンを表示し、色を画面（スクリーン）の１ピクセルずつ塗っていく。これをマテリアル単位でGPUで一括で行う
- 沢山のUIがある場合 重なって表示している場合に問題になる。
- 沢山のUIがある場合 複数回塗られている 透明は「描画しない」ではなく「透明を塗る」なので、重なっている部分が複数回塗られる（オーバードロー）
- UI Profiler （Composite Overdraw) 確認 方法UI ProfilerのCompsiteOverdrawで確認できる。色が赤に濃いほど負荷が高い
- UI Profilerで確認しているの図
- オーバードロー対策 • 不要なUIを排除 • 重なる部分を出来るだけ削る • Sprite Meshを使用 • Fill Centerを外して、中央をくり抜く • オーバードローしても問題ないシェーダーを使う sprite mesh使用 通常のquad 対策
- • シェーダーの負荷は 各デバイスのプロファイラーで 確認する • XCodeはいいぞ
- UIのリビルド （ジオメトリ）
- Canvasに一旦まとめる Canvas マテリアル テクスチャ UIのレイアウト バッファ 前述の通り、Canvasは一旦描画するUIのポリゴンをまとめて、バッファを生成。 バッファは基本使い回される
- 2300個のImage 殆ど負荷がかからない 単一描画になるので効率よく描画できる。バッチング出来ているなら殆どCPUに負荷がかからない（iPadPro1stで検証）
- 変化があれば再構築が必要 Canvas マテリアル テクスチャ UIのレイアウト バッファバッファ 更新 更新 更新 UIを動かすと以前のバッファを使い回せなくなるので、バッファを作り直す必要がある
- バッファの再構築は即時ではない Update LateUpdate Post Rate Update SendWillRenderCanvasesSetDirty 変化した内容に応じて Dirtyフラグを付ける UIを再構築 Canvas バッファは即時反映ではなく、変化した物にDirtyフラグをセット、溜めて一括処理する
- 再構築の条件 • UIをenable/disable • マテリアルが変化 • RectTransformのサイズが変化 • Transformの親が変化 UI再構築の条件は結構緩く、簡単に再構築が走る
- 一つ変わると、同じCanvasの全ての UIを再構築する Set Dirty 同じCanvasが全て 更新対象に ジオメトリはCanvas単位で管理しているので、一つでも変更があれば同Canvas全てに影響する
- このUIのどれかが動けば、背景のUIにリビルドが走る
- メインスレッドの 処理は少ない Canvas内のサイズによってジオメトリの再構築に時間がかかる 配置により ソートに時間がかかる ジオメトリの再構築はメインスレッドではない為、即座にフレームが落ちる訳ではない（テキスト…フォントの取得は除く）。ただし ジオメトリ生成完了までレンダースレッドが遅延するので、量によっては固まる。また、他のジョブ進行にも影響する。
- 確認 方法 UI Profilerが動いている 動いていなければ静か 確認方法 UI Profilerで確認出来る
- Profilerでも分かりやすい 確認 方法 通常のプロファイラーでもUGUIRenderingが伸びるので確認できる
- CPU Profiler（Hierarchy）で OnDidApplyAnimationPropertiesや OnRectTransformDimensionsChangeで検索 追加表示項目を変更 Show Related Objects（関連オブジェクトを表示） UI再構築してそうなの一覧が表示される 確認 方法 UIのEventSystemでUIが動いている場合、誰がUIを動かしたのかを確認できる
- Canvasを分割 対策 対策１：SubCanvasを作りジオメトリを分割する
- Set Dirty Static Canvas Dynamic Canvas 違うCanvasなのでリビルド対象外 Canvasを分割 Canvasを分割することで、UIを動かしてもジオメトリの再構築範囲を限定できる
- （Canvasのジョブ完了待ちが 消えた効果もある） Canvas分割の効果。UIのソートやジオメトリの生成コストが殆ど無くなる
- 動くUIはImageのSprite Meshを避ける use sprite mesh : enable 3.22ｍｓ use sprite mesh : disable 0.4ｍｓ対策 SpriteMeshはポリゴンが多く、ジオメトリ生成のコストが上がる。動かすUIには使わない方が無難
- 親UIを動かす element element element element element element element root 親Transformを動かした場合もUIの再構築が走る。 ScreenSpaceCameraを使用している場合、よく起こる
- 動かしたタイミングで負荷 確認 方法 UIProfilerでRenderの山ができている場合はコレ
- • 要素数を減らす • 要素をプーリングして 最小限のUIでどうにかする 対策 コレといった対策は無い。 動くCanvasには要素はあまり突っ込まないのが良い
- UIのリビルド （Layout Group）
- RectTransform 子の RectTransform 子のRectTransform 子 の RectTransform 子の RectTransform LayoutGroupは、例えばRectTransformの中に大量のUIがある時、
- RectTransform ILayoutGroup 子のRectTransform 子のRectTransform 子のRectTransform 子のRectTransform ILayoutGroupで 子RectTransformの情報を収集し 子オブジェクトを自動的に並べてくれる（レイアウトする）機能
- RectTransform ILayoutGroup ILayoutSelfController 子のRectTransform 子のRectTransform 子のRectTransform 子のRectTransform ILayoutSelfControllerで 子RectTransformの情報を元に 自分のオブジェクトのサイズを変更する 子オブジェクトの情報を元に、親（自身）のサイズを調整することも可能
- RectTransform ILayoutGroup ILayoutSelfController 子のRectTransform 子のRectTransform 子のRectTransform 子のRectTransform 要素が増えても 自動的に対応子のRectTransform 子のRectTransform 要素が増えたりサイズが変わっても対応できる、柔軟性を持つ
- うまく組み合わせれば、横に伸びて縦に要素を加算するUI…みたいなものも作れる
- 特にScroll Viewとかでよく使われる機能
- Dirty System Layout Group Element Element Element Element UI LayoutもDirtySystemを使用して実現している
- Dirty System Layout Group Element Element Child Child DirtyElement UIの変更があればDirty （この例では緑のElementのサイズを変更）
- Child Dirty System Layout Group Element Element Element リビルド申請 DirtyしたUIから親LayoutGroupへ、レイアウトの再構築を申請
- Element Dirty System Layout Group Element Element Element 再レイアウト あとで一斉にUIを再レイアウトする
- Dirty System Layout Group Element Element Element Layout Group Layout Group Element Element Element リビルド申請 Element 複数のLayoutGroupがある場合は
- Dirty System Layout Group Element Element Element Layout Group Layout Group Element Element ElementElement LayoutGroupの親まで到達して、そこから再レイアウト （なので、途中で自身のサイズを変えるContentSizeFitterはLayoutGroupの間に挟むと具合が悪い）
- Groupの更新 Layout Group Element Element Element Layout Group Layout Group Element Element ElementElement parent.GetComponents() parent.GetComponents() rect.GetComponents() この親LayoutGroupへの通知は、毎回GetComponentを使用。子のレイアウト変更にもGetComponentを使用。 地味に負荷になる
- DirtyするUIが紛れ込むだけで 毎フレーム、UIのリビルドが走る 一つでもDirtyするUIが含まれると、毎回Layoutの再構築。 これはメインスレッドで実行され、妙に高い負荷になる
- UI Profilerが動いている 動いていなければ静か 確認方法 確認 方法 再レイアウトが起こっている場合、UI ProfilerのLayoutが大きく変化する
- メインスレッドで処理されるため、大きな負荷と認識される事が多いです。 再レイアウト処理
- • RectTransformに関連するものを操作しない （結果は変化しなくとも、セットするだけでリビルドが走る） • Layout Propertyに関連するものを操作しない • UI Element関連を操作しない • Mecanimのステートマシンに、上記の要素にアクセスする AnimationClipを入れない （Simple Animationなら多分OK） 対策
- 対策 もしUIのインタラクティブな機能（ScrollViewとかButtonとか）から呼び出している場合、ProfilerのUI Detailで 誰が呼び出しているのか確認できる
- LayoutGroupを 可能な限り使わない 対策
- その他
- TextコンポーネントのTextを変更する際にメインスレッドでフォント取得処理が発生 （※変更しなければ発生しない） Textコンポーネント１つなら問題無いが、大量にあると負荷になる 500個のUI.Textコンポーネントのtextを変更 その他 Font.CacheFontForText
- その他 • Raycast Targetは可能な限り外す • World Space CameraのEvent Cameraにはカメラを登録する （無い場合はFindTag(“MainCamera”)を呼ばれる • Pixel Perfect設定は動かないカメラのみ設定する • テクスチャは画面解像度に合ったものを使う、 可能な限り圧縮する
- その他 • UI Profilerはエディターのみ動作 • ＸＣｏｄｅ等のデバイス専用プロファイラーは 詳しい情報を収集できて便利 • 負荷を見るならビルドする Windows向けでも、多くのノイズを取り除いてくれる （実機で確認するのがベターではある）
- まとめ
- ポイント • 動かさなければ負荷は低い • 動かすなら最低限の影響に抑える • ドローコールとフィルレート、バッチング。 良いバランスを取る •気を抜くな！誰も信用するな！ プロファイラーを手放すな！
- UI Element(Runtime) Coming Soon
- おしまい
Anúncio