Addressable Assets開発サイクル

##六、Addressable Assets開発サイクル

###6.1従来のアセット管理

Resourcesディレクトリでアセットを計画する場合、アセットはアプリケーションの初期パッケージに構築されることを意味しています。それに、Resources.Load のAPIのみを使用して、必要なコンテンツをロードするためのパスパラメーターを渡すことができます。アセットをどこでも参照するには、アセットを直接参照するか、AssetBundleとして参照する必要があります。AssetBundlesを使用している場合でも、アセットパスを渡し、ロード時に何らかの戦略に従ってそれらを組み合わせる必要があります。 AssetBundleがリモートであるか、一部の依存関係が他のAssetBundleにある場合は、それらのダウンロード、ロード、およびアンロードを管理するための独自のコードも作成する必要があります。
###6.2＃Addressableアセット管理

Assetにアドレスをバインドすると、その場所、ディレクトリ、またはアセットの作成方法に関係なく、そのアドレスからそのAssetを読み込むことができます。アドレス可能なアセットの名前を任意に変更しても問題ありません。ビルドまたはロードコードを変更せずに、アドレス可能なアセットをResourcesディレクトリに移動したり、ローカルビルド戦略からリモートまたは他のビルド戦略に切り替えたりすることもできます。
####6.2.1 Asset group schemas

Schemasはデータのセットを定義します。InspectorでSchemasをAsset Groupsにバインドできます。バインドされたSchemasグループは、その下のアセットのコンテンツをどのようにビルドするかを決定します。たとえば、BundledAssetGroupSchemaモードのグループは、Packed modeでビルドするときにAssetBundleのソースとして機能します。また、Schemasを組み合わせて、新しいGroupを定義するためのテンプレートにすることもできます。Schemasテンプレートは、AddressableAssetsSettingsのInspectorパネルから追加できます。
###6.3ビルドスクリプト

ビルドスクリプトは、プロジェクトでIDataBuilderインターフェイスを実装するためのScriptableObject assetsとして現れます。ユーザーは、独自のビルドスクリプトを作成し、Inspectorを介してそれらをAddressableAssetSettingsオブジェクトに追加できます。 Addressables Groupsウィンドウ（Window>AssetManagement>Addressables>group）でビルドスクリプトを適用するには、Play Mode Scriptを選択してから、ドロップダウンオプションを選択します。現在、完全なアプリケーションビルドをサポートするために3つのスクリプトが実装されており、エディターで反復するための3つの再生モードスクリプトが実装されています。
####6.3.1 Play Mode Scripts 

Addressable Asset Packageには、3つのビルドスクリプトがあります。それはアプリケーション開発を加速させるために、Play Modeデータの作成に用いられます。
**Use Asset Database（faster）**
Use Asset Database（BuildScriptFastMode）を使用すると、ゲームプレイ中にゲームをすばやく実行できます。Asset Databaseを介してAssetを直接ロードします。これにより、アナライザーやAssetBundleの作成を必要とせずに高速な反復が可能になります。
**Simulate Groups（advanced）**
Simulate Groups Mode（BuildScriptVirtualMode）は、AssetBundleを作成せずにレイアウトと依存関係の内容を分析します。Assetは、パッケージを介してロードされたかのように、ResourceManagerを介してAssetDataBaseからロードされます。ゲームプレイ中にBundlesがロードまたはアンロードされるタイミングを確認するには、Addressablesイベントビューアーウィンドウ（Window>Asset Management>Addressable>Event Viewer）でAssetの使用状況を表示します。Simulate Groups Modeは、読み込み戦略をシミュレートし、コンテンツGroupsを調整して、制作とリリースの適切なバランスを見つけるのに役立ちます。
**Use Existing Build（requires built groups）**
Use Existing Buildは、デプロイされたアプリケーションビルドに最も近いものですが、別のステップとしてデータをビルドする必要があります。このモードは、Assetが変更されていない場合に最速です。これは、Playモードに入るときにデータを処理しないためです。このモードのコBuild>New Build>Default Build Scriptを選択するか、ゲームスクリプトでAddressableAssetSettings.BuildPlayerContent（）メソッドを使用して、Addressablesグループウィンドウ(Window>Asset Management>Addressable>group>group)でビルドする必要があります。
**Choosing the right script**
Play Mode Scriptを適用するには、Addressables Groupsウィンドウメニュー(Window>AssetManagement>Addressable>group)からPlay Mode Scriptを選択してから、ドロップダウンオプションから選択します。開発および展開中、各モードには異なる時間とアセットの配置があります。次の表は、特定のモードが有効になる開発サイクルの段階を示しています。
![6.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653855/b9dc81b2-b517-bcc8-eb15-0edf844cdbb0.png)


###6.4分析とデバッグ

デフォルトでは、Addressable Assetsはwarnings and errorsログのみを記録します。ただし、詳細ログは、Player Settingウィンドウ（Edit > Project Settings… > Player>Player)を開いて、ログの詳細を展開します。そして、Other Settings > Configurationセクションに移動し、Scripting Define Symbolsフィールドに「ADDRESSABLES_LOG_ALL」を追加してから、
AddressableAssetSettingsオブジェクトInspectorのLogRuntimeExceptionオプションをオフにすることによって異常を無効にすることもできます。必要に応じて、独自の異常処理アプリケーションでResourceManager.ExceptionHandlerプロパティを実装できますが、これは、Addressablesがruntime initializationを完了した後に実行する必要があります（以下を参照）。
####6.4.1オブジェクトの初期化

オブジェクトをAddressable Assets Settingsにバインドし、実行時に初期化アプリケーションに渡して処理します。CacheInitializationSettingsオブジェクトは、実行時にUnityのキャッシングAPIを制御します。独自の初期化オブジェクトを作成するには、IObjectInitializationDataProviderインターフェイスを実装するScriptableObjectを作成します。これは、作成・実行時にデータをシリアル化にするObjectInitializationDataシステムのEditorコンポーネントです。
###6.5コンテンツ更新ワークフロー

Unityは、ゲームコンテンツを次の2つのカテゴリに分類することをお勧めします。
>(1)Staticコンテンツ、更新されない静的コンテンツ。
(2)Dynamicコンテンツ、更新を希望する動的コンテンツ。

この構造では、静的コンテンツはアプリケーションに付随し（またはインストール後すぐにダウンロードされ）、少数のより大きなBundlesに存在します。動的コンテンツはオンラインで存在し、更新ごとに必要なデータ量を最小限に抑えるために、より小さなパッケージであることが望ましいです。Addressable Assets Systemの目標の1つは、スクリプトを変更せずにこの構造を簡単に使用および変更できるようにすることです。
ただし、Addressable Assets Systemは、アプリのまったく新しいビルドをリリースしたくない場合など、「静的」コンテンツを変更する必要がある状況にも適用します。
また、リモートアップデートが許可されていない場合（現在の多くのビデオゲームコンソールやサーバーのないゲームなど）、毎回完全で新しいビルドを実行する必要があることに注意してください。
####6.5.1仕組み

Addressablesは、コンテンツディレクトリを使用して、アドレスを各Assetsにマップし、アドレスをロードする場所と方法を指定します。アプリケーションにマッピングを変更する機能を提供するには、元のアプリケーションがこのディレクトリのオンラインコピーについて知っている必要があります。この設定を行うには、AddressableAssetSettingsインスペクターで「BuildRemoteCatalog」設定を有効にします。これにより、ディレクトリのコピーが指定されたパスにビルドされ、そこからロードされます。アプリケーションが公開されると、このロードパスは変更できません。コンテンツ更新プロセスは、ディレクトリの新しいバージョン（同じファイル名）を作成し、以前に指定されたロードパスで対応するファイルを上書きします。
アプリケーションが構築されると、唯一のアプリケーションコンテンツバージョン文字列が生成されます。これらの文字列は各アプリケーションがどのようなコンテンツディレクトリをロードするかを決めます。特定のサーバーには、複数のバージョンのディレクトリを競合させることなく含めることができます。必要なデータをaddressables_content_state.binファイルに保存します。これには、バージョン文字列と、StaticContentとマークされたグループに含まれるAssetのハッシュ情報が含まれます。デフォルトでは、このファイルはAddressableAssetSettings.Assetファイルと同じフォルダーにあります。
addressables_content_state.binファイルには、Addressablesシステムの各StaticContent asset groupのハッシュおよび依存関係情報が含まれています。 StreamingAssetフォルダーに組み込まれているすべてのGroupsは、StaticContentとしてマークする必要があります。一部の大きなリモートGroupも、そのように指定できます。次のステップ（コンテンツ更新を準備する。以下の説明を参照。）中に、このハッシュ情報は、すべてのStaticContentグループに変更が必要なAssetsが含まれているかどうか、およびそれらのAssetsを別の場所に移動する必要があるかどうかを判断します。
####6.5.2コンテンツ更新の準備

StaticContentグループのAssetsを変更した場合は、「Check for Content Update Restrictions」コマンドを実行する必要があります。これにより、変更されたassetが静的グループから取得され、新しいグループに移動されます。新しいAsset Groupsを生成します。
1.UnityのAddressablesGroupsウィンドウを開きます。 （Window > Asset Management > Addressables > Groups）
2.Addressables GroupsウィンドウのToolsメニューを選択し、Check for Content Update Restrictionsをクリックします。
3.開いたBuildDataFileダイアログで、addressables_content_state.binファイルを選択します。デフォルトでは、このファイルはAsset / AddressableAssetsDataProjectディレクトリにあります。
このデータは、アプリケーションが最後にビルドされてから変更されたAssetsまたは依存関係を判別するために使用されます。更新コンテンツの生成に備えて、システムはこれらのAssetsを新しいGroupに移動します。
注：すべての変更がnon-static groupsに制限されている場合、このコマンドは効きません。
重要：prepare operationを開始する前に、バージョン管理システムでブランチを作り、そこで操作することをお勧めします。prepare operationは、updating contentに適した方法でAsset Groupsを再配置します。ブランチを作ると、次に新しいplayerをリリースしたときに、カスタム設定にすばやくロールバックできるようになります。
####6.5.3ビルドコンテンツの更新

コンテンツの更新を作成します。
>1.UnityはAddressables Groupsウィンドウを開きます。（Window > Asset Management > Addressables > Groups）
2.Addressables Groupsウィンドウで、上部メニューのBuildを選択してから、Update a Previous Buildを選択します。
3.Build Data Fileダイアログが開いたら、既存APPによってビルドされたビルドディレクトリを選択します。このディレクトリには、addressables_content_state.binファイルが含まれている必要があります。

ビルドにより、コンテンツディレクトリ、Hashファイル、およびAsset Bundlesが生成されます。
生成されたコンテンツディレクトリは、選択されたアプリケーションによって生成されたディレクトリと同じ名前で、古いディレクトリとhashファイルを上書きします。アプリケーションはHashファイルをロードして、新しいディレクトリが使用可能かどうかを判断します。システムは、アプリに付属している、またはすでにダウンロードされている既存のAssetBundleから変更されていないAssetsトをロードします
システムは、addressables_content_state.binファイルのコンテンツ、バージョン、文字列、および場所の情報を使用して、AssetBundleを作成します。更新されたコンテンツを含まないAssetBundleのファイル名は、元のファイル名と同じです。 AssetBundleに更新されたコンテンツが含まれている場合は、元のファイル名と共存する新しいファイル名を使用して、更新されたコンテンツを含む新しいAssetBundleを生成します。新しいファイル名のAssetBundleは、指定されたコンテンツホスティングの場所にコピーする必要があります。
システムは静的コンテンツのためにAssetBundleを構築することもできますが、それらを参照するAddressable Asset Entriesがないため、コンテンツホスティングのところにアップロードする必要はありません。
####6.5.4コンテンツ更新の例

この例では、次のグループの概念を理解する必要があります。
![7.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653855/4833c52d-a21d-5131-f58b-73642a832ceb.png)


バージョンがアクティブだったとき、一部のデバイスにLocal_Staticを持っていて、リモートパッケージをローカルにキャッシュしている場合もあります。
各Group（AssetA、AssetL、およびAssetX）からAssetを変更してから、Check for Content Update Restrictionsを実行すると、ローカルのAddressable設定の結果は次のようになります。
![8.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653855/af2d0193-89dc-8474-16ae-98d8a5d0d218.png)


prepare operationは実際には静的グループを編集しているため、通常の理解と矛盾する可能性があることに注意してください。システムは上記のレイアウトを自動的に構築しますが、静的Groupsは結果を破棄します。したがって、プレイヤーの観点から次の結論を導き出します。
![9.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653855/2664bae0-ecca-ed07-9d0d-d4e4446003d5.png)


LocalStatic bundleはすでにプレーヤーのデバイスにあるため、変更できません。この古いバージョンのAssetAは参照されなくなりました。代わりに、ジャンクデータとしてプレーヤーのデバイスに残されます。
![10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653855/4b963187-7f42-83df-c18a-328e7bc1fb88.png)


Remote_Staticbundleは同じままです。プレーヤーのデバイスにまだキャッシュされていない場合は、AssetMまたはAssetNが要求されたときにダウンロードされます。AssetAと同様に、この古いバージョンのAssetLは参照されなくなりました。
![11.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653855/ec388410-d057-aa8a-4ff4-d63f6372a57c.png)


Remote_non-Staticパッケージは廃止されました。サーバーから削除することはできますが、どちらの方法でも、ここから再度ダウンロードされることはありません。すでにキャッシュされている場合は、永久にキャッシュに残ります。 AssetAやAssetLと同様に、この古いバージョンのAssetXは参照されなくなりました。
![12.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653855/5074a2cf-b3f7-b1fc-e7e6-5d35dad60070.png)


古いRemote_non-Staticbundleは、hashファイルによって区別される新しいバージョンに置き換えられます。変更されたAssetXバージョンは、この新しいBundleで更新されます。
![13.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653855/814f985e-2874-9db3-c7a9-187d094aca84.png)


content_update_groupのBundleは、参照され、変更されたAssetsで構成されます。
上記の例には次の意味があることに注意してください。
1.変更されたローカルAssetsは、ユーザーのデバイスに永続的に残り、未使用の状態を保持します。
2.ユーザーが非静的Bundleをキャッシュした場合、変更されていないAssets（AssetYやAssetzなど）を含め、バンドルを再ダウンロードする必要があります。理想的には、ユーザーはキャッシュされたBundleを持っていない場合、新しいRemote_non-Staticバンドルをダウンロードするだけで済みます。
3.ユーザーがStatic_Remote bundleをキャッシュしている場合は、更新されたAsset（この場合はcontent_update_groupを介したAssetLをダウンロードする）をダウンロードするだけで済みます。しかし、この状況は理想的です。ユーザーがBundleをキャッシュしていない場合は、content_update_groupを介して新しいAssetLをダウンロードし、参照されていないRemote_StaticBundleを介して現在は廃止されているAssetLをダウンロードする必要があります。初期のキャッシュ状態に関係なく、完了のある時点で、ユーザーはデバイス上で非アクティブ化されたAssetLを持ち、アクセスまたは参照されていないにもかかわらず、永続的にキャッシュされます。
リモートコンテンツの最適な設定は、それをどのように使用するかによって異なります。

---
UWA Technologyは、モバイル/VRなど様々なゲーム開発者向け、**パフォーマンス分析**と**最適化ソリューション**及び**コンサルティングサービス**を提供している会社でございます。

今なら、UWA GOTローカルツールが**15日間に無償試用**できます！！
よければ、ぜひ！

UWA公式サイト：https://jp.uwa4d.com
UWA GOT OnlineレポートDemo：https://jp.uwa4d.com/u/got/demo.html
UWA公式ブログ：https://blog.jp.uwa4d.com