#複雑化する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の管理方法に関して、一部対応しているものがあったりしますが、
まだまだ無駄な部分が存在していると思い知らされました。
少しずつでも最適化などに手を加えていけたらと思います。