logl・ログル

世界をログしよう!

サムザップテックナイトvol.4 Unity山村氏が語る。~スマホのパフォーマンスチューニング最前線~

サムザップテックナイト
2017.07.12

6月22日(木)に開催されたサムザップテックナイトにて、ユニティ・テクノロジーズ合同会社の山村達彦氏に「サムザップテックナイトvol.4Unity山村氏が語る。~スマホのパフォーマンスチューニング最前線~」をお話しいただきました。

実際にご自身がどう作業されてるかというお話しをもとに、メモリのチューニングをはじめ、ロード、フレームレートと流れを追って展開されました。

ローディングについてはそもそもロードに原因があるかの判断段階から丁寧に解説され、Timelineをどう使うかや複数のAssetBundleを参照する際の事例も交え普段他のエンジニアのやり方が聞けない実務的な内容も話されました。フレームレートも描画とロジックの両側面から考察し、実際に動かす様子も交えながら納得感のある講演となりました。

■まずはプロファイリングの“肝”をおさえる

最初に簡単に自己紹介させていただきます。ユニティ・テクノロジーズジャパンという会社でフィールドエンジニアをしております、山村達彦です。“テラシュールブログ”や“@tsubaki_t1 ”の方が知られているのでもしかしたらご存知のかたもいらっしゃるかもしれませんね。

さっそくですが、今日は“パフォーマンスチューニング”についてお話ししていくので、そもそもパフォーマンスチューニングとは何かというところから初めて行きたいと思います。

パフォーマンスチューニング

アプリ開発をする上で、スクリプトやプロジェクト設定、ゲーム構造を見直してゲームのクオリティを維持したまま、処理負荷やメモリの削減をし、ゲームが快適に動作するように調整することをパフォーマンスチューニングと言いますが、実際の現場では「ロードが長くてテンポが悪い」、「メモリ使用量が多くてアプリが落ちる」、「フレームレートが低くて、テンポが悪い」、「実装したい機能のため空き性能が足りない」、「古い端末でも動作するようにしたい」といった課題が多いかもしれないですね。

逆にターゲットの環境で快適に遊べるなら、無理して調整する必要はないはずです。PCには無限のメモリ、高速のCPUやIOと快適なGPUがあれば大丈夫ですよね?笑 “最適化ボタン”をぽちっと押せば解決…は無理ということで、やはりチューニングの必要があるみたいです。

「パレートの法則」というものがあります。全体の2割が組織の大部分の利益をもたらし、全体の 2割が問題の大部分をやらかすという理論です。つまり20%を直せば、大体の問題が解決することがあるということです。 直すべき20%を把握することがキモになってくるのですが、“ゲームを観測する”→“問題点を見つける”→“直す算段を立てる”→“実際に作業してみる”をぐるぐる回して見極めていく必要があります。

実際にゲームのパフォーマンスを確認するために出てくるのが“プロファイリング”です。

Editorのプロファイラー上でプレイしたときに、さまざまな状況を確認できます。これはEditor上のプレイだけでなく、Android、iPhone上での実行のパフォーマンスも見られるようになっています。実際の画面では、CPU、Rendering、Memory等の情報を確認できるグラフや、どこに負荷がかかっているかを表示する画面がその下に出現します。DevelopビルドしたアプリはProfilerで負荷を確認できますので、ざっくり確認されたければEditorで見るのが楽です。ただ、1点注意がありまして、Editorの動作がプロファイルに乗ってしまうことがあるので気を付けてください。

アプリが落ちる原因として多いのが“メモリ不足”です。

メモリのプロファイラで使用状況が確認できます。実施の画面もお見せしましょう。

Unityメモリ、Monoメモリ両方を見る必要がありますが、単純にメモリ使用量が多いのであれば、UnityメモリならUnloadもしくはUnloadUnusedAssetsで解放し、Destroyで破棄するか、Monoならガベージコレクションで解放することができます。リークしている状態については、Resources.Unloadでも、Resources.UnloadAssetsでもアセットが解放されるというわけではないですので、メモリプロファイルにてアセットを使用しているオブジェクトを確認していくのがいいです。C#のメモリはC#スクリプト側で使用しているメモリでガベレージコレクションし、一度メモリを予約してから使います。予約済みのメモリはアプリ終了まで二度と返ってきません。ここで見ていただきたいのですが、Reserveが広がる場合、どこかで大量にメモリを確保している可能性があります。こちらも見ておくといいですね。

フレームレート

■Unity山村氏が実践しているフレームレート

描画負荷が高くなってしまったときは、オーバードローを取り除くことで負荷を減らします。それでも難しい場合はプラットフォームごとに用意されているGPU Profilerを使用してシェーダーの負荷を観察しましょう。今日ご紹介するのは“Snapdragon Profiler”、“Mali Graphics Debugger”と私が気に入っている“OpenGLES Frame Debugger”です。画面見ていただいた方がわかると思うので、実際に動かしてみます。どのシェーダーがどのくらい思いかもこれでわかりますね。頂点の負荷、ピクセルの負荷、GPUとCPUの負荷が比較できたり、描画にかかった時間、処理時間の割合も確認できるので便利だと思います。

シェーダーが重いときは、描画面積が広く、負荷が高いシェーダーがあると苦しくなってしまうので、cutoutでくり抜くより、ポリゴンで抜いたほうがはやいです。解像度を下げると大抵の負荷は下がっていきます。

Unityの追加機能として、“Scriptable Render Pipeline”がリリースされましたが、レンダリングパイプラインを自分で定義可能になりました。こちらも画面用意していますので、実際に動かしてみます。

おさらい


人気ログランキング

最新ログ

もっと見る
TOPへ戻る