機構の状態設定についてAB関連の機構には独立した状態設定がある。端末内に最低一つのAssetBundleListを保持すると、自動的に取得済み状態に変化する。ABList取得済み状態では、ABからAssetを取り出したりABをPreloadすることができる。メソッドを実行すると、Appに必要なリストを自動的に取得してくる。どちらにせよ、取得するリストについて、リストの設定がなされている必要がある。関数では、図の様なフローを通過する。複数のOverridePointsを経由するため、取得したデータの扱いを変更したい場合はOverridePointsの各関数を編集するとよい。メソッドで確認することが可能になっている。メソッドを実行する)タイミングで、もしリストが端末内になければ所得しに行く。関数で生成する、という形になっている。};}現状のAutoyaでは、事前にRuntimeManifestにリストのIdentityなどの情報が入っていないと、そのリストを取得したりアップデートしたりといったことができない。これは今後のバージョンで改善される可能性がある。AssetBundleからAssetのロード/使用Asset名とそのAssetの型をもとに、ABからAssetを取得する。});どのAssetBundleにどのAssetが含まれているかなどの情報はAssetBundleListが保持しているため、それらの情報を気にする必要がない。download特定のABに含まれるAssetをリクエストした際、そのABがダウンロード前であれば、ABをDLした後でAssetを展開する。あるAssetを使う際、Assetを含むABがDL済みでなければ、DL後に展開される。一度DLされたABは端末にキャッシュされる。Assetを含んでいるABがすでにキャッシュ済みな場合、DL処理なしで展開される。Asset展開AssetBundleはどこからダウンロードされるのか使用したいAssetを含んだABがまだキャッシュされていない場合、この機構は特定のパスを使ってAssetBundleのDLを開始、完了次第Assetの取り出しを行う。url;}デフォルトではこのメソッド内で、AssetBundleをDownloadする際のurlを決定している。そのAssetBundleが含まれているAssetBundleListのidentityをキーに、RuntimeManifestからAssetBundleListの情報を取得listDownloadUrlをbasePathとして扱い、listIdentityを追加platform文字列を追加リストのバージョン値を追加し、urlは完成となる。最終的にここで生成されたURLは次のようなものになる。"そのABが所属しているAssetBundleListのダウンロード用basePath/プラットフォーム文字列/リストバージョン値/";リストとそのリストに含まれるAssetBundleファイルを同じフォルダに入れた状態でCDNへとアップする、というのをサンプル版の前提としているため、変更するためにはこの関数で返すパス情報を変えればよい。(この部分はちょっと切り分けがうまくいっていないので、AssetBundleのファイル名までを足させる方向に変わるかもしれない。)AssetBundleの状態について各ABは、機構の内部で3段階の状態を持っている。ABキャッシュがメモリに展開済みAssetを取得する際、含有するABの状態が変化し、OnMemoryになったABからAssetが生成される。機構内部のABの状態を気にする必要はないが、知っておくとメモリ状態を把握することが可能。APIで手動で解放する。リストの内容とその生成についてリスト(AssetBundleList)はjson形式のファイルで、AutoyaではAssetBundleList型として実装されている。type内容は次の通り。AssetBundle.Autoyaでは、このリストをApp内に保持、必要に応じて更新することで、AssetBundleとそれに含まれるAssetを簡単に扱うことができるようになっている。リストのアップデートサーバ主導でAppが使うべきリストを更新することができる。リストとリソースの生成については、リソースの生成を参照。ABを複数のリストに分けるAutoyaでは複数のリストに分けてのAssetBundleの生成と管理、更新をサポートしている。AssetBundle複数のABを一括でDL、キャッシュする機構。この機構でDLしたABはメモリに展開されず、キャッシュされるのみになる。demandでAssetをDLさせたくない、Asset使用前に部分的にDLを済ませたい、という場合に便利。並列DLが可能になっており、複数のABをできるだけ高速にDLすることができる。含まれているABにも更新有り]という状態のABを最新版へと更新する効果もある。キャッシュ済みかつ更新がないABは当然変化しない。preload機能では、DLしたいABの情報をPreloadList型のインスタンスで渡してロードを実行する。次のようなPreloadList型のデータから複数のABを纏めてDLする機能を提供する。name.この型をパラメータ入りでnewして、App内でPreload機構を使用する。次のようなコードを書くと叶う。Listを取得、適宜必要なABをpreloadさせる運用も可能。「その画面以降で使うAssetとしてどんなものをDLしておくべきか」を常にサーバに問い合わせることができる様になる。これにより、「近い未来に使用するAssetを事前にダウンロードさせる」ということが可能になる。いう判断を盛り込むことができる。未DLのABの名前が来る。DLが済んでいるABの名前は含まれない。Preloadを継続する場合はproceed関数を実行、中断する場合はcancel関数を実行する。これからDLするABの名前一覧が取得できているので、これからDLするABの総重量をDL前に計算し、例えばプレイヤーに提示することができる。「このくらいの容量のデータをDLします、よろしいですか?」とか表示して、yesであればproceed関数を実行する。非同期で継続実行が可能になっている。次の図の様なフローを通過する。この関数上でリクエストヘッダのパラメータを調整することができる。ResetAssetBundle系のファクトリーリセットとして、ABやリストを削除してインストール状態時への復帰を行うメソッドがある。failed)このメソッドが成功すると、AppのAssetBundleはすべてUnloadされ、キャッシュから削除される。AssetBundleListもAppのインストール時の状態に戻る。そのため、AssetBundleListの再取得、最新のリストの再取得を行わせることができる。なにかしらABの配信に失敗した時に、プレイヤーが自発的に実行できるようにしておくといいかもしれない。