Android向けUnity製ゲーム最適化のための

CI/CDと連携した

自動プロファイリングシステム

KLab株式会社

発表者

塙 与志夫
上席執行役員
KLab株式会社
於保 俊
エンジニアリングマネージャー
KLab株式会社
細田 翔
Unityエンジニア
KLab株式会社
実機のプロファイリング
面倒じゃないですか?
課題:モバイルでの実機プロファイリングは大変
● 端末ごとに性能も特徴もさまざま
● SoCごとに異なるプロファイラー
● 専門知識が必要
充分な量のプロファイリングができずに
パフォーマンスの問題を見逃してしまう
解決策:継続的な自動プロファイリング
● CI/CDと連携した全自動の実機プロファイリング
● 非エンジニアでもダッシュボードから結果を見れる
パフォーマンスの劣化を見逃さない!
すぐにチューニングに着手できる!
本日のアジェンダ
1. 自動プロファイリングのための

Unityアプリケーション側の実装



2. プロファイリングのAndroid実機での

自動実行システム



3. ダッシュボードシステム

8
自動プロファイリングのための

Unityアプリケーション側の実装

通常のプロファイリング方法
● Unity標準のUnity Profilerを利用

● CPUの詳細な分析が可能(フレーム単位でのタイムライン表示など)

Unity Profiler ウィンドウ
スクリプト経由でのプロファイリング開始と終了
● Unity Profilerの通常の利用方法

○ PCと端末をUSBケーブルで接続して、プロファイラからアタッチ

○ 手間がかかる & UI操作の自動化が難しい

● Unity ProfilerのAPIを利用

○ スクリプト経由でバイナリログを端末内に保存できる

○ スタンドアローンで動作するので、PCとの接続も不要

Profiler.logFile = "mylog";// 保存ファイル名の指定
Profiler.SetAreaEnabled(ProfilerArea.Rendering, true);// プロファイリング項目の指定
Profiler.enableBinaryLog = true;// 詳細なバイナリログ形式で保存
Profiler.enabled = true;// プロファイリングを開始
プロファイリングデータの集計
●Profiler Reader

○ バイナリログをCSVに変換・集計するツール

○ Unity Technologies Japanと開発

○ https://github.com/unity3d-jp/ProfilerReader
○ 明日 9/5 (木) 13:30〜14:30『Unity2018/2019における最適化事情』
Profiler Reader
バイナリログ CSV
Profiler Readerの活用方法
● メインスレッドのメソッド単位の集計情報
○ 処理時間 ( avg / sum / min / max )
○ 呼び出し回数
○ コールスタック
●フレーム単位の情報
○ Unityのメインスレッド全体 ms
○ Unityのレンダースレッド全体 ms
○ Unityの各Jobスレッド全体 ms
○ ドローコール数
○ メモリ使用量
● CPU負荷の高い
メソッドの特定
● 重たいフレームの特定
● 原因のだいたいの把握
自動プレイ機能の実装
● アプリを起動したら完全放置でゲームが進行

○ プロファイリング対象のシーンに順番に遷移



● プロファイリングシステムへの成功・失敗の通知

○ 成功:すべての計測シナリオが正常終了

○ 失敗:例外が発生してアプリが進行不能

○ 通知用のファイルを生成

14
プロファイリングの

Android 実機での自動実行システム

● メインは Python スクリプトで構成
● 普通の Windows PC に端末を接続
● Android 開発ツールなどを活用
○ aapt (Android Asset Packaging Tool)
■ Bundle ID の apk パッケージからの抽出
■ メインアクティビティ名の抽出
○ adb (Android Debug Bridge)
■ apk の実端末へのインストール
■ ゲームアプリケーションの実行
■ ファイル転送やクリーンアップ
○ Unity (Profiler Reader実行用)
プロファイル自動実行システムの構成
プロファイル自動実行の流れ
apk ダウンロード
パッケージ名
などの抽出
実機インストール
アプリ実行 終了ファイル
ある?
結果抽出
変換
アップロード
デバイス
クリーンアップ
Yes
No
実機では頻繁に「エラー」が起きる
基本的には adb のエラー終了として起こる
● 「少し待ってリトライ」が一番有効
○ エラー終了したらn回リトライして、それでだめならその回は失敗
● 要所で adb サーバーを再起動
○ 特に apk インストール失敗時に再起動すると「経験上」うまくいく率が高い
○ 逆に再起動しすぎても、うまくいかないこともある
● 機種・OS間の差異が大きく、厄介
○ 進行ログもエラーメッセージも違う
○ 頑張ろうとせずに適当に
あきらめが肝心
実機利用での難しさ(1) エラー処理
プロファイルをなるべく同じ環境でやりたい
● バックグラウンドプロセスなど
○ adb shell am kill : プロセスの停止
○ adb shell am kill-all : 全てのアプリケーションプロセスの停止
● ストレージの管理
○ adb shell pm clear : 特定パッケージのデータ削除
● 冷却のために待ち時間をいれる
○ いれないと何もしてないのにどんどん結果が悪化する
○ さらにダメ押しでスマホクーラーを投入!
端末自体の再起動もやっていたが、 USB接続設定がリセットされたりするので、逆に不安定になる
実機利用での難しさ(2) 端末をクリーンに保つ
● 開発者モード
● スリープしない
○ USB接続中はスリープしない設定がある
● ファイル転送モード
○ 結果ファイルを転送できるように
● 音量
○ すべてミュート
○ 夜中に謎の音が鳴り続けないように
● 画面輝度
○ 最低に
○ 電力使わないように
○ 焼き付き防止?
実機利用での難しさ(3) 端末設定
21
ダッシュボードシステム

ダッシュボード画面
● マネージドサービスで構成すること
○ 管理者を立てるほどの規模ではないため
● お値段そこそこであること
○ お財布の心配は少ない方がいい
→GCPサービスと無料のBIツールの組み合わせで実現
ダッシュボードの要件
● Cloud Storage + Cloud Functions
○ ストレージ+サーバレスサービス
○ CSVをPythonスクリプトで処理、BigQueryに追記
● BigQuery
○ 分析用途に向いたデータベース、非常に安価
○ データを蓄積、ダッシュボード向けに整形
● Googleデータポータル
○ 無料のBIツール(Googleさん太っ腹)
○ プロファイリング結果の可視化・情報共有
ダッシュボードの構成要素
● 直近のプロファイリン
グ結果を表示
● ドリルダウンリンクで
詳細ページに遷移
ダッシュボード画面
● カテゴリ別表示
○ 実行時間上位
○ 予算超過率
● メソッド別表示
○ 実行時間上位
etc...
詳細画面
● 高負荷になるタイミングを可視化
○ 性能改善の材料として
時系列グラフ
可視化の例
● カテゴリ分類をGoogleスプレッドシートで定義
○ チームメンバーが自由に編集できる
○ ダッシュボードにすぐ反映される
● スプレッドシートはBigQueryテーブルとして扱える
○ 裏側の仕組みを知らなくても集計結果をカスタマイズできる
BigQuery採用の意外なメリット
● 意図せずゲームが重くなることがあり、有用だった
○ Unityのマイナーバージョンアップ時
○ 性能と無関係なつもりの変更が実際は重かった場合
● プロファイリング結果をメンバー内で共有できて便利
○ 特に非エンジニアにデータを共有しやすい
運用してみてのエピソード
● Android実機による自動プロファイリングシステムを開発
○ 実機プロファイリングのハードルを大幅に下げられた
○ チームメンバーと結果を共有しやすくなった
● 成果も得られた
○ ゲーム中のボトルネックの発見に役立った
○ 性能改善のイテレーションが速まった
結論
33
Thank you


Android向けUnity製ゲーム最適化のためのCI/CDと連携した自動プロファイリングシステム