Downloaded 29 times
Uploaded byUnityTechnologiesJapan002
【Unite Tokyo 2019】今すぐ現場で覚えておきたい最適化技法 ~「ゲシュタルト・オーディン」開発における最適化事例~
2019/9/25-6に開催されたUnite Tokyo 2019の講演スライドです。 Kim Minhyuk（株式会社 Aiming） こんな人におすすめ ・アプリケーション最適化の必要性を感じている方 ・低スペック端末でアプリケーションが落ちてしまう方 ・パフォーマンスも重視しながら他人が読みやすいコードを書きたい方 受講者が得られる知見 ・知らない間に増加しているアプリケーションメモリ使用量の改善策 ・ビルドサイズ・ロード時間の改善策 ・読みやすくGCを走らせないC#コードの書き方 Unityのイベント資料はこちらから： https://www.slideshare.net/UnityTechnologiesJapan/clipboards
More Related Content
![[CEDEC2018] UE4で多数のキャラクターを生かすためのテクニック](https://cdn.slidesharecdn.com/ss_thumbnails/cedec2018charcterperdormanceoptimze-180823081028-thumbnail.jpg?width=640&height=640&fit=bounds)
![[4.20版] UE4におけるLoadingとGCのProfilingと最適化手法](https://cdn.slidesharecdn.com/ss_thumbnails/ue4loadgcprofilingoptimization420-180802153630-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to 【Unite Tokyo 2019】今すぐ現場で覚えておきたい最適化技法 ~「ゲシュタルト・オーディン」開発における最適化事例~
【Unite Tokyo 2019】今すぐ現場で覚えておきたい最適化技法 ~「ゲシュタルト・オーディン」開発における最適化事例~
- 1. 株式会社Aiming / AimingInc. 金 敏赫 / Minhyuk Kim 今すぐ現場で覚えておきたい最適化技法 ~「ゲシュタルト・オーディン」開発における最適化事例~
- 2.
- 3. 3 Minhyuk Kim 2014~ AerowhaleStudio 2016~ 株式会社Aiming 味噌カツが大好きです 主にクライアントサイドを担当しています 株式会社Aiming/ソフトウェアエンジニア
- 4. 「ゲシュタルト・オーディン」 (C)Aiming Inc. /SQUAREENIX CO., LTD. All Rights Reserved. 株式会社スクウェア・エニックス/株式会社Aimingの共同プロジェクト 2018年10月18日 サービス開始 2019年09月26日 サービス終了 iOS/Android 向け MMORPG クライアントサイド - Unity 2017 - UniRx - C# 4.0 4
- 5.
- 6. 6 様々な問題が幅広い範囲で起こっている • 低スペック端末ではタイトルからアプリケーションがクラッシュする • 繰り返し戦闘を行うとクラッシュする •アプリケーションビルド時間が長い・ビルドサイズが大きい • アプリケーション全般ローディング時間が長い
- 7. 調査 •調査に使用したツール - UnityProfiler (CPU/GPU) -Xcode Instruments (iOS GPU) - Adreno GPU Profiler (Android GPU) •プロファイラーで大部分の問題が見える - リソースのメモリ使用率が常に高いことが判明した - バトルで激しくGCが発生した(ローディング時間が長い) - ヒープ確保量が多いことが判明した 7
- 8.
- 9. 9 現象 •タイトルから本ゲームに進めない •繰り返しの戦闘・移動でアプリが落ちる • メモリが足りなくクラッシュする問題の8割はリソース問題 - 普通のコードミスでメモリが足りなくなることは少ないと思われる -ヒープメモリ確保を数百個減らすより、テクスチャ―メモリを一枚減らすのが効果的
- 10. 10 AssetBundle •時代はAddressable Asset System(Unity 2018.2 ) •Editor/実機、 ローカル/リモート関係なく同じ仕組みに載せられる •現場の開発の度合上今すぐ入れられない・まだpreviewなどのいくつか懸念点がある •明示できていないアセットが含まれた際の重複に関してはケアする必要がある •今後の開発に関しては強力な考慮対象
- 11.
- 12.
- 13. 13 •明示的に含まれてないアセットは重複してメモリに載ってしまう • プレハブ・シーンなどから暗黙的に参照されてしまったアセットはそれぞれコピーされてしまい、 同時にロードされると重複する(別インスタンス) • 頻繁に参照されるものはバンドルに明示的にパッキングする必要がある (特に別インスタンスになると問題になるシェーダー・テクスチャー・マテリアル周りは注意) •全部別バンドルにしてしまうと、ファイルIO等によりロードに時間がかかるため対策が必要となる -> テクスチャーは用途に応じてアトラス化し、アトラスごとにバンドルにする -> シェーダーは一個のバンドルにまとめる AssetBundle
- 14.
- 15.
- 16. Built-in Resources •AssetBundleとの相性が悪い •AssetBundleからロードしたアセットとは別インスタンス扱いになるので重複する •Built-inシーンに参照されたアセット +Resourcesフォルダーアセット = OK •Resourcesフォルダーアセット + AssetBundleアセット = 重複 •Built-inシーンに参照されたアセット + AssetBundleアセット = 重複 16
- 17. Built-in Resources •ビルドに含めないといけないアセットがあるなら •シーンとリソースを最低限にし、AssetBundleに載せてStreamingAssetsを使う •ダウンロードシーン ->タイトルシーン順になっている事例もある •一部の外部アセットはResourcesの仕組みに依存するものが存在する(TextMeshPro) 17
- 18. 18 その他のリソース管理 •RenderTexture • 自前で生成せず、常にRenderTexture.GetTemporary->ReleaseTemporaryを使う • 同じ解像度・フォーマットであれば同じフレームでも内部ObjectPoolにより何度も使い回せる •メンバー変数に保存せず、使い終えたら即時返却し同一フレームの他の処理で使えるようにする • 何フレームか使われなかったら自動でメモリから外れる • 複数枚使う可能性があるならフォーマットと解像度を共通化すると一枚分しかメモリを確保しない • MonoBehaviour.OnRenderImageはRenderTextureを確保するので注意 • 用途に応じてTextureのサイズ・フォーマットを調整する • ただ機種により動かないフォーマットがあるのでSupportsRenderTextureFormatで チェックし、Fallback処理を入れる
- 19. 19 まとめ • Assetbundle • AddressableAsset Systemが安定化されたら考慮する • 明示できてないAssetは別バンドルになると重複することに注意 (特にShader・Texture・Material) • Unloadを呼んだあと再びLoadしたアセットバンドルでのアセットは別アセット扱いになることに注意 • Built-in Resources • Resourcesフォルダーだけではなく、Build settingsのシーンに含まれた明示できてないアセットも 含まれることに注意 • Built-in Resourcesに含めたものの上にAssetbundleをロードすると重複することに注意 • RenderTexture • 自前で管理よりGetTemporaryを使った方がメモリに優しくなることが多い • フォーマットや解像度によりサイズを減らす・ただし、複数使う想定だったら共通化できるものは共通化する
- 20.
- 21.
- 22. 22 とにかくVariantが多すぎる • #pragma multi_compile-> shader_feature + skip_variants ビルドに含まない ビルドに含まない • shader_featureを使う際、AssetBundleには明示的にShaderVariantCollectionとして 含まないと該当Variantが効かない
- 23. 23 ShaderVariantCollection • WarmUp() • WarmUp関数を呼ぶことで、事前にシェーダーのコンパイルを走らせることが出来る •事前に準備したShaderVariantCollectionを初期起動時のローディング画面でロードしておく • 常に使われるShaderのVariantCollectionは数が限られていたため、全部メモリに保持して Parseが走らないようにした •複数のシェーダーが含まれたCollectionのWarmUp時に画面が固まってしまった • ShaderVariantCollection一つに全ての組み合わせを登録したことで、 同期関数のWarmUpを呼ぶと画面が固まったまま時間がかかってしまった • ShaderVariantCollectionを適切に分割し、少しずつWarmUpを呼ぶことで解決
- 24. 24 ShaderVariantCollectionの •更新の自動化 • バンドルに含まれる予定のシーンのマテリアル情報を参照し、 material.shaderKeywordsからキーワード獲得 • Editor内部関数のGetShaderVariantEntriesをReflectionで 呼び出し、含まれているPassType/Keyword組み合わせを獲得 •material.shaderKeywordsから獲得したKeywordと組み合わ せマップを基に実際使われる想定のShaderVariantCollection 作成
- 25. 25 まとめ • multi_compileよりはshader_featureを使う • shader_featureを使った際にアセットバンドルに含めないといけないものは ShaderVariantCollectionにまとめる、自動化で解決 •WarmUp()は同期関数なので数をばらしてShaderVariantCollectionに登録し、 固まらないようにする
- 26.
- 27.
- 28.
- 29. 29 何が問題だったのか // 遅延関数でIOにアクセス等重たい処理を行い、そのまま下流に流してしまう private IEnumerable<Player>LoadPlayers(IEnumerable<long> playerIds) { return playerIds.Select(x => LoadPlayers(x)); } // LoadしたプレイヤーからヒーラーだけをFilterする private IEnumerable<Player> GetHealerDefeatedPlayers(IEnumerable<Player> players) { var healerIds = players .Where(x => x.Job == JobType.Healer) .Select(x => x.Id); return players.Where(x => x.DefeatedPlayerIds.Any(id => healerIds.Contains(id))); } // 報酬を配る private void GiveReward(IEnumerable<Player> players) { foreach (var healerDefeatedPlayer in healerDefeatedPlayers) { healerDefeatedPlayer.GiveReward(); } }
- 30. 30 繰り返して実行関数が呼ばれてしまっている // LoadしたプレイヤーからヒーラーだけをFilterする private IEnumerable<Player>GetHealerDefeatedPlayers(IEnumerable<Player> players) { var healerIds = players .Where(x => x.Job == JobType.Healer) .Select(x => x.Id); return players.Where(x => x.DefeatedPlayerIds.Any(id => healerIds.Contains(id))); } •実行関数が呼ばれるたびに遅延関数が実行される •LoadPlayerの作者はplayer id数分だけLoadが走ることを期待したが、 IEnumerableを回す瞬間 player id数 * ヒーラー数 * プレイヤーが倒したプレイヤー数の 合計分Loadが走ってしまう
- 31. 31 即時評価(実行関数) •今まで遅延していた処理を含めて即時実行する •新しくICollection<T>を返す拡張メソッド群(即時評価) • ToArray • ToDictionary •ToLookup • … • メソッドの名前にToが付いているメソッドは即時評価 • 別のCollectionを作ることでヒープアロケーションが発生する •その他の即時評価拡張メソッド群 • Count • Min(By)/Max(By) • Any/All • … • 戻り値がIEnumerable<T>でないメソッドは即時評価
- 32. 32 遅延評価 •遅延評価する拡張メソッド群 • Where • Select •GroupBy • … • 戻り値がIEnumerable<T>(IGrouping<T>等の継承関係も含む)であるメソッドは遅延評価
- 33. 33 •IEnumerable引数に対して同じ層で実行関数を何度も使う必要がある場合 • 使う用途に応じてまず一回ICollection化して使う • ICollectionにしたものはそのままICollectionとして返した方が使う側で選択肢が多くなる •大きく流れる可能性がある情報をずっとIEnumerableのまま渡さない •色んな層で実行関数を呼ぶたびに重なった遅延処理が走る • どれぐらいの重たい遅延処理がいくつ重なるのか予測できない • ある関数の実行に関係ない遅延処理のコストが足されるため問題になった際に探しにくい 遅延関数を溜めすぎない 33
- 34.
- 35.
- 36. 36 コードに必要な最低限の情報を正しく伝える public class Misokatsu { //実は外でSetしてなかった (private set) public int Price { get; set; } // 実は外で使われてなかった (private) public void Cook() { … } } •公開範囲
- 37. 37 public class Monster { privatereadonly int code; private string Name { get; } private readonly IReadOnlyList<int> defeatedMonsterCodes; private readonly IImmutableList<int> affectedPassiveCodes; } public readonly struct MonsterPosition { } •不変性 (Immutable) •readonly struct(C# 7.2) 不変ということをコンパイラーにも伝えることで、 structに対してのDefensive Copyが発生しない
- 38. 38 public class Hoge { privateint a; private int b; public int Sum() => a + b; } •副作用・状態変化 public (static) class Hoge { public (static) int Sum(int a, int b) => a + b; }
- 39. 39 public class Shop { privateMenu menu; public void Open() => menu = new Menu(); public void Close() => menu = null; public async Task WaitUntilDayPassesAsync() { await Task.Wait (TimeSpan.FromDays(1)) menu?.Prepare(); … } public void Order() => menu?.Order(); } •副作用・状態変化 • ここでのmenuのOrderは正常に処理されるのだろうか? • 該当関数がOpenとCloseに依存している
- 40. •関数の副作用はできるだけ除く (関数型思考) • あるクラスに対してメンバー変数が多用され、非同期・マルチスレッドと混ぜて 頻繁に状態を変化させると非常に流れを追いづらい •ある機能を持つ関数に対して引数・戻り値を明確にし、副作用を除くことで コードの流れが直観的になる • クラス生成時に使いたくない処理なら使う際に渡す、もしくはLazy<T>を使う •メモリにも優しくなる • static function (静的関数)・副作用がないラムダ式 -> 関数内の副作用を取り除くことで、ラムダ式のキャプチャーが発生しない 40
- 41. まとめ •Linq to objects •実行関数(即時評価)を呼ぶと今まで溜めた遅延関数の処理が全て走る • 戻り値がIEnumerable<T>なら遅延処理、そうではないなら即時処理 • IEnumerable引数に対して同じ層で実行関数を何度も使う必要がある場合、Collection化する • 大きく流れる可能性がある情報をずっとIEnumerableのまま渡さない •読み易いコード • 公開範囲、不変性等伝えられる情報はできるだけ多く正しく伝える • 副作用・状態はできるだけ除く •関数型思考を意識したコードを書く(同じ入力に対して同じ出力をする流れを作る) • readonly struct・静的関数等を使うことで自然にメモリにも優しくなる 41
- 42.