アセットバンドルのビルド

Important note: The AssetBundle Manager is deprecated for Unity versions 2018.2 and higher. It is no longer available from the Asset Store, but you can still download it from the AssetBundleDemo Bitbucket repository. If you use Unity version 2018.2 or higher, see documentation for Addressable Assets.

ドキュメントの アセットバンドルのワークフロー で、3 つの引数を BuildPipeline.BuildAssetBundles 関数に渡すコードサンプルがあります。もう少し実際的に掘り下げてみましょう。

Assets/AssetBundles は、AssetBundle (アセットバンドル) の出力先ディレクトリです。これを任意のディレクトリに変更することができます。そのフォルダーはビルドを始める前にすでに存在するフォルダーでなければなりません。

BuildAssetBundleOptions

BuildAssetBundleOptions は数種類あり、様々な効果を指定することができます。すべてのオプションの表は、スクリプトリファレンスの BuildAssetBundleOptions を参照してください。

必要に応じて自由に BuildAssetBundleOptions を組み合わせることができますが、AssetBundle (アセットバンドル) の圧縮に関しては、3 つの特定の BuildAssetBundleOptions があります。

• BuildAssetBundleOptions.None:このバンドルオプションでは LZMA 形式の圧縮を使用します。これはシリアライズされたデータファイルから成る 1つの圧縮 LZMA ストリームです。LZMA 圧縮では、バンドル全体が使用前に解凍されている必要があります。これにより、ファイルサイズは最小限に抑えられますが、圧縮解凍のためのロード時間が若干長くなります。この BuildAssetBundleOptions を使用する場合、バンドルからアセットを使用するには、バンドル全体を最初に圧縮解除する必要があることに注意してください。
  一旦バンドルが解凍されると、バンドルからアセットを使用する前に、バンドル全体を解凍する必要がない LZ4 圧縮を使用してディスク上で再圧縮されます。これは、バンドルがから1 つのアセットを使用する場合に、すべてのアセットがロードされるようなアセットが含まれている場合に最適です。キャラクターやシーンのすべてのアセットのパッケージ化を行う場合に、この方法を使用すると良い場合があります。
  LZMA 圧縮を使用するのは、ファイルサイズが小さいため、オフサイトのホストからアセットバンドルを最初にダウンロードする場合にのみ推奨されます。 UnityWebRequestAssetBundle を通してロードされた LZMA 圧縮アセットバンドルは自動的に LZ4 圧縮に再圧縮され、ローカルファイルシステムにキャッシュされます。バンドルを他の方法でダウンロードして保存する場合は、AssetBundle.RecompressAssetBundleAsync APIを使用してバンドルを再圧縮できます。

• BuildAssetBundleOptions.UncompressedAssetBundle: このバンドルオプションでは、データをまったく圧縮しないでバンドルをビルドします。圧縮しない不利な点は、ファイルのダウンロードサイズが大きくなることです。しかし、いったんダウンロードが終わると、読み込み時間はずっと早くなります。

• BuildAssetBundleOptions.ChunkBasedCompression: このバンドルオプションでは、LZ4 という圧縮方法を使用します。LZ4 ではファイルの圧縮サイズは LZMA より大きくなります。しかし、LZMA と異なり、使用前にバンドル全体を解凍する必要がありません。LZ4 では、「かたまり」に基づいたアルゴリズムを使用し、アセットバンドルを部分的、もしくは、かたまりごとに読み込むことが可能です。1 つのかたまりを解凍すると、たとえアセットバンドルの他のかたまりが解凍されていなくても、解凍したかたまりに含まれるアセットは使用することができます。

ChunkBasedCompression を使うことで、ディスク上のサイズを縮小できるという利点に加え、圧縮されていないバンドルと同等の読み込み時間を実現します。

BuildTarget

BuildTarget.Standalone: これにより、アセットバンドルをどのターゲットプラットフォームに使用するかをビルドパイプラインに指示します。スクリプトリファレンスの BuildTarget に可能なビルドターゲットが明記してあるリストがあります。ただし、ビルドターゲットをハードコードしたくない場合は、EditorUserBuildSettings.activeBuildTarget の利用も便利です。これを使うと、ビルドのターゲットとなる現在設定されているプラットフォームを自動的に検知し、そのターゲットに基づいてアセットバンドルをビルドします。

適切にビルドスクリプトを設定したら、最後にバンドルをビルドします。Assets > Build AssetBundles の順に選び処理を始めます。

問題なくアセットバンドルをビルドしたら、アセットバンドルのディレクトリに当初予想していたよりも多くのファイルがあることに気がつくでしょう。正確にいうと、2*(n+1) 個余分です。いったい BuildPipeline.BuildAssetBundles で何が起こっているかを見てみましょう。

エディターで指定したアセットバンドルにはすべて、アセットバンドルと同じ名のファイルと、アセットバンドル名 + “.manifest” というファイルがあります。

他にも作成したアセットバンドルと名前が違うバンドルやマニフェストが含まれています。それらの名はアセットバンドルがビルドされ配置されたディレクトリの名前に由来しています。これはマニフェストバンドルです。これに関しては後で詳しく説明します。

AssetBundle ファイル

AssetBundle (アセットバンドル) ファイルには .manifest の拡張子がなく、アセットをロードするためにランタイムにロードします。

アセットバンドルファイルは複数のファイルを内部に持つアーカイブです。このアーカイブの構造は、それがアセットバンドルなのかシーンのアセットバンドルなのかによって、多少変わります。以下は通常のアセットバンドルの構造です。

シーンのアセットバンドルは通常のアセットバンドルと異なり、シーンとそのコンテンツのストリームのロードのために最適化されています。

Manifest ファイル

追加の Manifest Bandle (マニフェストバンドル) も含め生成されたすべてのバンドルに対し、関連するマニフェストファイルが生成されます。そのマニフェストファイルは任意のテキストエディターで開くことができ、バンドルの巡回冗長検査 (Cyclic Redundancy Check, CRC) データや依存データなどの情報を含んでいます。通常のアセットバンドルでは、マニフェストファイルは以下のようなものです。

ManifestFileVersion: 0
CRC: 2422268106
Hashes:
  AssetFileHash:
    serializedVersion: 2
    Hash: 8b6db55a2344f068cf8a9be0a662ba15
  TypeTreeHash:
    serializedVersion: 2
    Hash: 37ad974993dbaa77485dd2a0c38f347a
HashAppended: 0
ClassTypes:
- Class: 91
  Script: {instanceID: 0}
Assets:
  Asset_0: Assets/Mecanim/StateMachine.controller
Dependencies: {}

これには含まれるアセット、依存関係、その他の情報が示されています。

生成されたマニフェストバンドルにはマニフェストが含まれますが、どちらかというと以下のように見えます。

ManifestFileVersion: 0
AssetBundleManifest:
  AssetBundleInfos:
    Info_0:
      Name: scene1assetbundle
      Dependencies: {}

これは、アセットバンドルの関連情報と依存関係を表しています。ここでは、 単に AssetBundleManifest オブジェクトがこのバンドルに含まれていることを、理解しておいてください。AssetBundleManifest オブジェクトはランタイムにどのバンドルの依存関係を読み込むかを見つけるのに、非常に役立ちます。このバンドルとマニフェストオブジェクトの使い方に関して詳しくは、マニュアルの ネイティブに AssetBundles を使用する を参照してください。

• 2017–05–15 Page published