CEDEC2017

[CEDEC2017]複雑化するassetbundleの配信からロードまでを基盤化した話

複雑化するassetbundleの配信からロードまでを基盤化した話

講演者

福永 亘 さん(株式会社QualiArts)
石黒 祐輔 さん(株式会社QualiArts)

講演内容

AssetBundleの管理に関して問題があり、それの解決を試みた。

問題点

  • 世代管理(バージョン管理)が出来ない
  • Asset数が多く管理が大変(数万ファイルに及ぶ)
  • クライアントで同一のAssetBundleをロードすることが出来ない
  • 端末にキャッシュ済みのものを公式に削除する方法がない
  • 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の管理方法に関して、一部対応しているものがあったりしますが、
まだまだ無駄な部分が存在していると思い知らされました。
少しずつでも最適化などに手を加えていけたらと思います。