複雑化するassetbundleの配信からロードまでを基盤化した話
講演者
福永 亘 さん（株式会社QualiArts）
石黒 祐輔 さん（株式会社QualiArts）
講演内容
AssetBundleの管理に関して問題があり、それの解決を試みた。
問題点
- 世代管理（バージョン管理）が出来ない
- Asset数が多く管理が大変（数万ファイルに及ぶ）
- クライアントで同一のAssetBundleをロードすることが出来ない
- 端末にキャッシュ済みのものを公式に削除する方法がない
- ＡｓｓｅｔＢｕｎｄｌｅの作成方法が各タイトル毎になっていた
要件定義＆課題
- 運用が楽
- 配信が早い
- 正確である
- 動作が高速
- どんなタイトルでも使える
- 使いやすい
- 膨らむデータ量
- 突発的なトラフィック
- 大量のデータのやり取り
対策
・膨らむデータサイズ
GoogleCloudStorageを使用する
・突発的なトラフィック
GoogleCloudPlatform
docker
GKE（Google Container Engine)
を使用して対応を行った。
・大量のデータのやり取り
CDN（content delivery network）を使用して対応
・AssetBundleの世代管理
リビジョン単位で世代管理を行い、
全体のリビジョン、ファイル単位のリビジョンで管理を行っている
端末のリビジョンとサーバー上のリビジョンが違う場合のみデータを更新する。
SDKの構築
クライアントの課題
- UnityAPIだけでも最低限のことが出来るが、自由度が低い
- AssetBundleの世代管理ができない
- 同一Assetbundleに対しての同時ロードができない
対策
- 汎用的なAPIを提供する
- SDKの導入ハードルを下げる（依存ライブラリを最低限のものにする）
- ローカルDBの管理のためのメモリ使用量を抑えるためにstructを使用する
- ロード管理のためにリクエスト数とアンロード数に応じてリソースを破棄するかの判定を組み込む
- 明示的なロードとは別にGameObject自体の生死でリソースのロード・破棄に対応
通信に関しての対策
通信方法の種類は複数あり、AssetBundleをダウンロードする際の通信をそれぞれ比較を行った。
・HttpWebRequest
自由度は高いが、Https通信が行えないのでセキュリティ的に不採用
・WWW（UnityAPI）
古い、機能拡張に乏しい
・UnityWebRequest（UnityAPI）
ワンソースでマルチプラットフォーム対応可能
自由度もそれなりにある
DownloadhandlerScriptを拡張することで固定長バッファを使いまわすことが出来、メモリ消費も抑えられる
問題として受信イベントがメインスレッドで呼び出されている。
C#のメモリコピーのコストが大きい
・ネイティブプラグイン（内製）
C#のメモリコピーを行わないため、GCの発生を抑制できる。
効率的なパイプライン化が可能
まとめ
AssetBundleの管理方法に関して、一部対応しているものがあったりしますが、
まだまだ無駄な部分が存在していると思い知らされました。
少しずつでも最適化などに手を加えていけたらと思います。