Android向けUnity製ゲーム最適化のためのCI/CDと連携した自動プロファイリングシステム
- 2. 発表者 塙 与志夫 上席執行役員 KLab株式会社 於保 俊 エンジニアリングマネージャー KLab株式会社 細田 翔 Unityエンジニア KLab株式会社
- 4. 課題：モバイルでの実機プロファイリングは大変 ● 端末ごとに性能も特徴もさまざま ● SoCごとに異なるプロファイラー ● 専門知識が必要 充分な量のプロファイリングができずに パフォーマンスの問題を見逃してしまう
- 9. 通常のプロファイリング方法 ● Unity標準のUnity Profilerを利用 ● CPUの詳細な分析が可能（フレーム単位でのタイムライン表示など） Unity Profiler ウィンドウ
- 10. スクリプト経由でのプロファイリング開始と終了 ● Unity Profilerの通常の利用方法 ○ PCと端末をUSBケーブルで接続して、プロファイラからアタッチ ○ 手間がかかる & UI操作の自動化が難しい ● Unity ProfilerのAPIを利用 ○ スクリプト経由でバイナリログを端末内に保存できる ○ スタンドアローンで動作するので、PCとの接続も不要 Profiler.logFile = "mylog";// 保存ファイル名の指定 Profiler.SetAreaEnabled(ProfilerArea.Rendering, true);// プロファイリング項目の指定 Profiler.enableBinaryLog = true;// 詳細なバイナリログ形式で保存 Profiler.enabled = true;// プロファイリングを開始
- 11. プロファイリングデータの集計 ●Profiler Reader ○ バイナリログをCSVに変換・集計するツール ○ Unity Technologies Japanと開発 ○ https://github.com/unity3d-jp/ProfilerReader ○ 明日 9/5 (木) 13:30〜14:30『Unity2018/2019における最適化事情』 Profiler Reader バイナリログ CSV
- 12. Profiler Readerの活用方法 ● メインスレッドのメソッド単位の集計情報 ○ 処理時間 ( avg / sum / min / max ) ○ 呼び出し回数 ○ コールスタック ●フレーム単位の情報 ○ Unityのメインスレッド全体 ms ○ Unityのレンダースレッド全体 ms ○ Unityの各Jobスレッド全体 ms ○ ドローコール数 ○ メモリ使用量 ● CPU負荷の高い メソッドの特定 ● 重たいフレームの特定 ● 原因のだいたいの把握
- 13. 自動プレイ機能の実装 ● アプリを起動したら完全放置でゲームが進行 ○ プロファイリング対象のシーンに順番に遷移 ● プロファイリングシステムへの成功・失敗の通知 ○ 成功：すべての計測シナリオが正常終了 ○ 失敗：例外が発生してアプリが進行不能 ○ 通知用のファイルを生成
- 16. ● メインは Python スクリプトで構成 ● 普通の Windows PC に端末を接続 ● Android 開発ツールなどを活用 ○ aapt (Android Asset Packaging Tool) ■ Bundle ID の apk パッケージからの抽出 ■ メインアクティビティ名の抽出 ○ adb (Android Debug Bridge) ■ apk の実端末へのインストール ■ ゲームアプリケーションの実行 ■ ファイル転送やクリーンアップ ○ Unity (Profiler Reader実行用) プロファイル自動実行システムの構成
- 17. プロファイル自動実行の流れ apk ダウンロード パッケージ名 などの抽出 実機インストール アプリ実行 終了ファイル ある？ 結果抽出 変換 アップロード デバイス クリーンアップ Yes No
- 18. 実機では頻繁に「エラー」が起きる 基本的には adb のエラー終了として起こる ● 「少し待ってリトライ」が一番有効 ○ エラー終了したらn回リトライして、それでだめならその回は失敗 ● 要所で adb サーバーを再起動 ○ 特に apk インストール失敗時に再起動すると「経験上」うまくいく率が高い ○ 逆に再起動しすぎても、うまくいかないこともある ● 機種・OS間の差異が大きく、厄介 ○ 進行ログもエラーメッセージも違う ○ 頑張ろうとせずに適当に あきらめが肝心 実機利用での難しさ(1) エラー処理
- 19. プロファイルをなるべく同じ環境でやりたい ● バックグラウンドプロセスなど ○ adb shell am kill : プロセスの停止 ○ adb shell am kill-all : 全てのアプリケーションプロセスの停止 ● ストレージの管理 ○ adb shell pm clear : 特定パッケージのデータ削除 ● 冷却のために待ち時間をいれる ○ いれないと何もしてないのにどんどん結果が悪化する ○ さらにダメ押しでスマホクーラーを投入！ 端末自体の再起動もやっていたが、 USB接続設定がリセットされたりするので、逆に不安定になる 実機利用での難しさ(2) 端末をクリーンに保つ
- 20. ● 開発者モード ● スリープしない ○ USB接続中はスリープしない設定がある ● ファイル転送モード ○ 結果ファイルを転送できるように ● 音量 ○ すべてミュート ○ 夜中に謎の音が鳴り続けないように ● 画面輝度 ○ 最低に ○ 電力使わないように ○ 焼き付き防止？ 実機利用での難しさ(3) 端末設定
- 21. 21 ダッシュボードシステム
- 23. ダッシュボード画面
- 24. ● マネージドサービスで構成すること ○ 管理者を立てるほどの規模ではないため ● お値段そこそこであること ○ お財布の心配は少ない方がいい →GCPサービスと無料のBIツールの組み合わせで実現 ダッシュボードの要件
- 25. ● Cloud Storage + Cloud Functions ○ ストレージ＋サーバレスサービス ○ CSVをPythonスクリプトで処理、BigQueryに追記 ● BigQuery ○ 分析用途に向いたデータベース、非常に安価 ○ データを蓄積、ダッシュボード向けに整形 ● Googleデータポータル ○ 無料のBIツール（Googleさん太っ腹） ○ プロファイリング結果の可視化・情報共有 ダッシュボードの構成要素
- 27. ● カテゴリ別表示 ○ 実行時間上位 ○ 予算超過率 ● メソッド別表示 ○ 実行時間上位 etc... 詳細画面
- 29. 可視化の例
- 30. ● カテゴリ分類をGoogleスプレッドシートで定義 ○ チームメンバーが自由に編集できる ○ ダッシュボードにすぐ反映される ● スプレッドシートはBigQueryテーブルとして扱える ○ 裏側の仕組みを知らなくても集計結果をカスタマイズできる BigQuery採用の意外なメリット
- 31. ● 意図せずゲームが重くなることがあり、有用だった ○ Unityのマイナーバージョンアップ時 ○ 性能と無関係なつもりの変更が実際は重かった場合 ● プロファイリング結果をメンバー内で共有できて便利 ○ 特に非エンジニアにデータを共有しやすい 運用してみてのエピソード
- 32. ● Android実機による自動プロファイリングシステムを開発 ○ 実機プロファイリングのハードルを大幅に下げられた ○ チームメンバーと結果を共有しやすくなった ● 成果も得られた ○ ゲーム中のボトルネックの発見に役立った ○ 性能改善のイテレーションが速まった 結論
- 33. 33 Thank you