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