【Unity道場スペシャル 2017京都】最適化をする前に覚えておきたい技術
•
13 gostaram•17,038 visualizações
2017/11/18に開催されたUnity道場スペシャル 2017京都の講演スライドです。 講師：黒河 優介（ユニティ・テクノロジーズ・ジャパン合同会社） 「効果的な最適化のために事前に何をしたらよいか？」「どういう考えで最適化を行っていけばよいか？」などの基本的な考え方から、具体的なProfilerの使い方までお伝えしていきたいと思います。この講演で紹介する考え方は、日本のエンタープライズチームを通して得た知見になります。最適化のテクニックそのものは紹介しませんが、考え方を身につける事で、最適化のために役立つでしょう。 こんな人におすすめ ・最適化したいが、何をしてよいかわからず困っている人 ・効率的に最適化を行いたい人 受講者が得られる知見 ・Unity Profilerに関するノウハウ ・最適化の目算、見積もりをする技術 Unityのイベント資料はこちらから： https://www.slideshare.net/UnityTechnologiesJapan/clipboards
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (20)
Semelhante a 【Unity道場スペシャル 2017京都】最適化をする前に覚えておきたい技術
Semelhante a 【Unity道場スペシャル 2017京都】最適化をする前に覚えておきたい技術 (20)
Mais de Unity Technologies Japan K.K.
Mais de Unity Technologies Japan K.K. (20)
Último
【Unity道場スペシャル 2017京都】最適化をする前に覚えておきたい技術
- 1. 最適化をする前に覚えておきたい技術 - Unity道場 京都スペシャル2 Edition - ユニティ・テクノロジーズ・ジャパン合同会社 エンタープライズサポート 黒河 優介
- 2. 自己紹介 • 役職 • ユニティ・テクノロジーズ・ジャパン合同会 エンタープライズコンサルティングデベロッパー リレーションマネージャー／エンジニア • 仕事内容 • 大規模プロジェクトのサポート業務 • プロジェクトに合う形で、パフォーマンスに関す る提案等を行っている
- 4. 本日の講演内容 • 「最適化」とは何なのか？ • 「プロファイリング」について • 実際のケーススタディ • ステップアップのためのTIPS
- 5. 本日の講演 • 講演資料のキーとなる箇所には ユニティちゃんが出現 大事なポイント やってはダメなパターン 覚えておくと役立つ知識
- 7. なぜ最適化を行うのか？ • ターゲットにしている端末で、想定している処理速度が出ない • これによりユーザー体験が落ちてしまう • ユーザー体験が落ちたことによる低評価を避けたい ターゲットにしている端末で十分快適に遊べているなら、無理して最適化 を行う必要はない
- 9. 最適化を行いたいシチュエーション • メモリ使用量が多くて、ゲームが不正終了してしまう • ロード時間が長くて、ゲームのテンポが悪くなってしまう • ゲームプレイ中に急に画面が一瞬固まり、プレイミスが起きてしまう。 • 低いフレームレートでゲーム体験が劣化してしまう
- 10. 最適化の前に覚えておきたい法則 • 「パレートの法則」 • 通称：80:20の法則。全体の数字の大部分は、全体を構成するごく一部 によるものである • 処理負荷となっている部分は、プロジェクトのごく一部分によって起 きている
- 18. プロファイリングについて • 処理毎に掛った時間、メモリの使用状況を確認する作業 • Unity標準機能で Profiler が用意されているので、こちらを使って 計測可能 • より詳細な事は各プラットフォームが提供しているネイティブの Profilerがあるが、大まかな問題把握では UnityのProfilerで十分
- 20. Unity Profilerについて • Editor上でプレイした時に、CPU / GPU / Rendering / Memory / Audio / Physics / uNet / Video Player / UI / GIなどの状況を確認できる • Editor上でのプレイだけでなく、Android/iPhone上での実行のパフォーマ ンスも見られる ※Video Playerは Unity 5.6から利用可能 UIは Unity 2017.1から利用可能 GI(Global Illumination)は Unity 2017.2から利用可能
- 21. Profiler使い方 デモ
- 22. Unity Profilerの使い方 Menuから Window -> Profiler を選択すると、このウィン ドウが出てくる
- 31. ケーススタディ • 最適化を行いたいシチュエーションによって、見るべき場所も変わって くる • メモリ使用量が多くて、ゲームが不正終了してしまう • ロード時間が長い • ゲームプレイ中にカクツキが頻発してしまいストレスフル • 低いフレームレートでゲーム体験が劣化してしまう
- 33. メモリ使用量が多い時に考える事 • 単純にメモリ使用量が多いのか？それともリークしているのか？ • C#メモリが多いのか？ Unityメモリが多いのか？ ※リークとは未使用のものがメモリに残り続けてしまい、 必要以上にメモリを消費してしまう現象
- 34. メモリがリークしているかチェックする メモリの詳細項目に読み込んでいる Texture・Mesh等の数がある。 繰り返しプレイしていて、右肩上が りに数字が増えていたらリークして いる可能性大
- 36. C#メモリが大きいのか、 Unityメモリが大きいのか • Unityが使用するメモリは大きく分けて二つある • C#メモリ(Mono Memory) • Unityメモリ →どちらが大きいかによって取るアクションは大きく変わってくる
- 38. C#メモリとUnityメモリについて • C# メモリ • C# スクリプト側で使用しているメモリで、Garbage Collectionされる • 一度メモリをReserve(予約)してから使う。C#用に予約済みとなったメ モリはアプリ終了まで二度と返されない • Unityメモリ • Texture, Mesh, Animation などのアセットのデータで主に占められるメ モリ
- 40. C#のメモリでの着目点 • Used（現在使用中)よりも、Reserved(予約)の方に着目 • Editor上での実行の場合はEditorが使ったメモリも換算されてしまうの で、実機でのチェックが望ましい • Reserved(予約) が大きすぎる場合、どこかで一時的にC#メモリが膨らん でいる可能性がある • ファイル読み込みや、通信のために一時的に大量のC#メモリを使用し ていないか？
- 41. Unityメモリでの着目点 • メモリ上にある各Asset毎のメモリ内の容量をチェック • Memory Profilerを、Detailed (詳細) ビューに切り替えて確認 • 別途 Unity Technologies製のEditor拡張ツールもあり • 出来ることは殆ど同じだが、ちょっとグラフィカルで見やすい
- 44. Memory Profiler の使い方 Take Sampleボタンを押すと、メモ リの詳細を調べられる
- 47. メモリが多かった時の対策 • C#メモリ • C#スクリプトの見直しを行う • 特にファイル読み込みや通信時等にメモリを多く消費していないか？ • Unityメモリ • 余計なアセットが読み込まれないようにする • 必要であれば、読み込みのタイミングをずらす等も視野に • 必要以上に大きいアセットは圧縮等を行うようにする
- 51. ロードが重かった時のデモ
- 56. プロファイリングする時の注意 プロファイリングをするとき は Debug.LogをOFFに！ Debug.logger.logEnabled = false; でログ書き出し処理を無効に出来る。 ※理想は全部のDebug.Log呼び出しを#ifdefなどで 事前に括って置いて呼び出しそのものをしない事
- 65. 一瞬だけ画面が固まる場合 • 裏でロード処理を行っている等の心当たりがない場合は、ほとんどの場 合 GC(Garbage Collection)が走っている • GCとは、C#メモリが足りなくなった時に整理して未使用のメモリを再 び使えるようにする処理 • GCは膨大な処理時間を取られる • まずはGCが起きていないかProfilerでチェック
- 66. GCが起きていないか 確認デモ
- 68. GCが頻繁に起きていた時の対策 • まずは、どのC#スクリプトで多く消費しているか特定する • C#のメモリ使用を可能な限り抑えるように書き換える • 文字列操作はメモリを都度使用するので、扱いには注意！ • StringBuilderクラスを使うようにしましょう • 特に毎フレームUpdate処理でのメモリ確保は控える
- 69. GCの発生箇所特定デモ
- 75. string処理の扱いについて このプログラムを元にC#メモリがどう確保されるかを図解します string name = “player”; dialogTitle.text = “名前は” + name + “ですか？” + “¥n”;
- 76. string name = “player”; dialogTitle.text = “名前は” + name + “ですか？” + “¥n”; string処理の扱いについて 一時的に生成されるstring 名前はplayer “名前は”とnameを結合し、 一時的に結果を保存するた め、stringを生成
- 77. string処理の扱いについて 一時的に生成されるstring 名前はplayer 名前はplayerですか？ 一時的に生成したstring ”名前はplayer”と”ですか？” を結合した結果を別途生成 string name = “player”; dialogTitle.text = “名前は” + name + “ですか？” + “¥n”;
- 78. string処理の扱いについて string name = “player”; dialogTitle.text = “名前は” + name + “ですか？” + “¥n”; 一時的に生成されるstring 名前はplayer 名前はplayerですか？ 最後に改行文字を足した文字列を dialogTitle.textに追加して処理が完 了
- 79. string処理の扱いについて string name = “player”; dialogTitle.text = “名前は” + name + “ですか？” + “¥n”; 一時的に生成されるstring 名前はplayer 名前はplayerですか？ 一時的に生成されたが ゴミとしてメモリ内に溜まる (GCのタイミングで完全に処理され る)
- 81. 正しい string処理 上記のように StringBuilderを利用することで、一時 的なstringの生成を防げる StringBuilder sb = new StringBuilder(32); string name = “player”; dialogTitle.text = sb.Append(“名前は” ) .Append( name ) .Append( “ですか？” ) .Append( “¥n” ).ToString();
- 82. 正しい string処理 string用のBuffer(32文字分確保) StringBuilder sb = new StringBuilder(32); string name = “player”; dialogTitle.text = sb.Append(“名前は” ) .Append( name ) .Append( “ですか？” ) .Append( “¥n” ).ToString(); string用に 32文字分の バッファーを確保
- 83. StringBuilder sb = new StringBuilder(32); string name = “player”; dialogTitle.text = sb.Append(“名前は” ) .Append( name ) .Append( “ですか？” ) .Append( “¥n” ).ToString(); 正しい string処理 string用のBuffer(32文字分確保) 名前は バッファーに ”名前は”を追加
- 84. 正しい string処理 string用のBuffer(32文字分確保) 名前はplayer バッファーに nameの値を追加 StringBuilder sb = new StringBuilder(32); string name = “player”; dialogTitle.text = sb.Append(“名前は” ) .Append( name ) .Append( “ですか？” ) .Append( “¥n” ).ToString();
- 85. 正しい string処理 string用のBuffer(32文字分確保) 名前はplayerですか？ バッファーに ”ですか？”を追加 StringBuilder sb = new StringBuilder(32); string name = “player”; dialogTitle.text = sb.Append(“名前は” ) .Append( name ) .Append( “ですか？” ) .Append( “¥n” ).ToString();
- 86. 正しい string処理 string用のBuffer(32文字分確保) 名前はplayerですか？¥n バッファーに ”¥n”を追加 StringBuilder sb = new StringBuilder(32); string name = “player”; dialogTitle.text = sb.Append(“名前は” ) .Append( name ) .Append( “ですか？” ) .Append( “¥n” ).ToString();
- 87. 正しい string処理 string用のBuffer(32文字分確保) 名前はplayerですか？¥n バッファーの中身を stringにして dialogTitle.textに入れ る StringBuilder sb = new StringBuilder(32); string name = “player”; dialogTitle.text = sb.Append(“名前は” ) .Append( name ) .Append( “ですか？” ) .Append( “¥n” ).ToString();
- 90. 楽な直し方 まず、下記のgithubのソフトを導入 https://github.com/wotakuro/StringBuilderTemporary 導入後… string name = “player”; dialogTitle.text = StrOpe.i + “名前は” + name + “ですか？” + “¥n”; 文字列の足し算の前に “StrOpe.i +”を 追加するだけの簡単なお仕事！
- 91. 少しだけ解説 • C#の暗黙的型のcastとoperatorのoverrideを少し応用したテクニック • StrOpe.i + “文字列” をしたときに、別の型を返すようにしていて、その 型とstringでの演算を別途定義することで無理くり動かすテクニック • 内部的には StringBuilderのAppendが呼ばれるようになっている
- 94. 低いフレームレートとは？ • 60FPS(秒間60フレーム)にしたいなら、1フレーム辺りの処理を 16.6ミリ秒に抑える必要がある • 30FPS(秒間30フレーム)にしたいなら、1フレーム辺りの処理を 33.3ミリ秒に抑える必要がある -> これを超えてしまうとフレームレートが低くなる
- 95. 低いフレームレート時に考える事 • ゲームロジック側による負荷なのか？それとも描画負荷なのか？ • 直すべきはゲームのロジックそのものなのか、描画処理に関する事な のか？ • 描画処理の方が修正した事によるバグ発生は少ない
- 96. ゲームロジックの負荷？描画負荷？ 「Rendering」が描 画の負荷具合、そ れ以外がゲームロ ジック。 CPUのグラフで、Renderingとその他(Vsync除く)の どちらが重いかでジャッジ
- 99. ゲームロジックの負荷の場合 • 負荷となっているのは、C#スクリプトの処理か？それともUnity側での処 理か？ • Unity側の処理の場合、物理処理、UI処理あたりがよくある負荷原因 • GameObject数が多すぎて、全体的に重くなってしまう事も時々ある • モバイルでは、3000程度には抑えておきたい
- 100. Physicsが重いデモ
- 102. Physicsが重いデモ Physicsが重い場合、Edit → Project Settings → Time のFixedTimestep設定を 見直す。 Physicsは、通常のゲームループとは違う周期(フレームレート)で動い ている。デフォルトでは 50FPS( 0.02 )となっているので、30FPSで動 いているゲームの場合、Physicsも30FPSになるように「0.03333」を指 定すると良い
- 103. Physicsが重いデモ それでもPhysicsが重い場合… Edit → Project Settings → Physicsにて、 衝突判定を行うLayerの設定を見直す
- 109. ざっくりと原因と対策 • C#スクリプト • 原因＆対策：ゲームによって色々 • 物理処理 • 原因：余計な衝突判定を行っている • 対策： Layer Collision Matrix を見直す • 原因：複雑な衝突判定を行っている • 対策：MeshColliderは重いので、BoxCollider等で置き換える • 原因：1フレームに複数回Physics処理が回っている • 対策：TimeのFixedTimeStep設定を見直す
- 110. ざっくりと原因と対策 • UI処理 • 原因：重い頂点計算が走っている • 対策：uGUIはAnimationしているものは別Canvasに分けないと重い
- 111. 描画の負荷で考える事 • 余計な描画が入っていないか？ • Batch数、Set Pass数が多くないか？ • 頂点数が多すぎないか？ • 描画面積が広くないか？(Overdrawをしすぎていないか？) • Shaderが重くないか？
- 116. FrameDebuggerデモ
- 117. FrameDebuggerデモ メニューのWindow -> Frame Debugger にて呼び出し可能
- 120. Batch数、SetPass数について • Batch数はドローコールとも呼ばれ、実際に描画の命令を何回呼んだか？ • SetPass数はマテリアル切り替えの処理を何回呼んだか？ • 単純に呼ぶ回数が多ければ多いほど処理負荷になる。モバイルゲームで は200を超えた辺りから見直しが必要
- 122. Batch数、SetPass数への対策 • 出来るだけ同じマテリアルで描画する事でDynamic Batchingが効くよう にする • 同じマテリアルで描画するべく、Textureをパッキングする • 動かない背景モデルなどをStaticにして、Static Batchingが効くようにす る
- 123. 頂点数が多すぎないか？ • 実はあまり問題になったことがない • モバイルでも数万ポリゴンは余裕で出る • 頂点数はわかりやすいので、作成時に最初から気を使っている様子
- 124. 描画面積が多すぎないか？ • 塗るピクセル数が多ければ多いほど、描画の負荷が大きくなる • 透明な色で塗っていても、描画負荷は同様に掛かる • 特にUI/半透明オブジェクトでの描画面積には注意が必要 • 透明色で大きな面積を塗りつぶしている可能性がある • ImageEffectは一つ付ける毎に画面を塗りなおしている
- 125. Shaderが重くないか？ • Shader内での計算が複雑になればなるほど、1ピクセルを描画するのにか かる時間が増えていく • 描画面積×Shaderの重さ が負荷になる • 描画面積の大きい「地面・空」などで重いShaderを使っていると、大き な描画負荷になる
- 127. Shaderが重くないかチェックする • Unity Profilerよりも、各プラットフォーム別に用意されているGPU Profilerで測った方が早く出来る • 大抵の場合、描画毎にどれだけの時間がかかったか測れる • もう一つの手段としては、描画面積が大きい部分を、軽いShaderに置き 換えてみて、Profilerで差分を見てみる • 「Mobile/Unlit/Texture 」 「Mobile/VertexLit」辺り
- 131. まとめ • 最適化はゲーム体験をよくするためにする作業 • 最適化を行う前にプロファイルをして、直すべき箇所を探し出す • Unityにはプロファイルのための機能があるので、それらをうまく活用し よう
- 132. Thank you!
- 134. ステップアップテクニック • Profilerの結果保存について • スクリプトのある部分だけ処理負荷を測りたい • 各プラットフォーム毎のGPU Profilerも使う
- 137. 結果保存のためのツール・手順紹介 • Unity 5.6以降で有効なエディター拡張 • 300フレーム毎に、SaveをするためのEditor拡張を作成 • https://github.com/wotakuro/UnityProfilerIntervalSave • Unity5.5以前でも有効な方法 • Android/iOS端末上でログファイルを書き出すようにして、実行後にPC へ転送、解析を行う手法 • https://github.com/wotakuro/ProfilerBinarylogSplit
- 140. スクリプトのある部分だけ 処理負荷を測りたい • Profiler.BeginSample(“Profilerに出したい名前”); Profiler.EndSample(); で囲った区間の処理を測ることが可能！ ※Unity 5.5からは「using UnityEngine.Profiling;」が 必要なので注意
- 141. BeginSampleのサンプルコード void Update(){ // 移動処理等が書いてある …. Profiler.BeginSample(“アニメ切り替え”); // Profilerで測りたいアニメ切替の処理 …… Profiler.EndSample(); // 残りの処理等 …. }
- 142. スクリプトのある部分だけ 処理負荷を測りたい Profiler.BeginSample ～ EndSample の処理時間 が確認できる
- 143. こんな使い方も… void LoadAssetBunlde( string name){ Profiler.BeginSample(“AssetBundle読み込み ” + name); // nameで指定されたAssetBundleを読み込む処理 …… Profiler.EndSample(); } 好きな名前を指定できるので、読み込もうとしている AssetBundle名を入れることで、AssetBundle毎の 読み込み時間がわかる
- 145. 各プラットフォーム毎に用意された GPU Profilerを使う • 各プラットフォーム別のGPU Profilerを使う主な理由 • 描画で、GPUに関する情報はUnityのProfilerでは不足 • 描画毎に何ミリ秒取られたかが細かく確認できる
- 146. 各プラットフォーム毎に用意された GPU Profilerを使う • iOS • XcodeのOpenGLES Frame Debugger • Android • チップメーカー毎に違う • Mali -> Mali Graphics Debugger • Snapdragon -> Snapdragon Profiler • Tegra -> Tegra Graphics Debugger • Windows上のEditor • Render Doc
- 149. Snapdragon Profiler
- 150. Render Doc