Version: Unity 6.0 (6000.0)
言語 : 日本語
ビルドの出力
AssetBundle compression formats

マルチプロセスアセットバンドルビルド (実験版)

マルチプロセスアセットバンドルビルドは、以前のバージョンの Unity と比較して、アセットバンドルのビルド方法を大幅に改善します。この機能 (2023.1 で導入) は、最初は既存のビルドコードと並行して提供され、デフォルトでは無効です。この新しい機能は、BuildPipeline.BuildAssetBundles() でビルドされたアセットバンドルにのみ適用され、Addressables でビルドされたアセットバンドルには適用されません。

この機能により、ビルドパフォーマンスが向上し、アセットバンドルに関する長年の問題が解決されました。導入を容易にするために、出力の互換性が高く、既存の API から利用できます。

新しいメカニズムでは、アセットデータベースを使用して複数の並行インポートを実行し、中間ファイルをキャッシュします。多くの場合、この機能を有効にすると、クリーンビルドはより速くなり、インクリメンタルビルドはより速く、より正確になります。さらに、Accelerator を使用してマシン間でビルドアーティファクトを共有できるため、あるマシンでのビルドで他のマシンでの同様のビルドのスピードを上げることができます。詳細については、並行インポート を参照してください。

マルチプロセスビルドを有効にすると、シェーダーコンパイル作業も専用のビルドステップに移動します。これにより、ビルドの他のステップと比較して、シェーダーのコンパイルにかかる時間がより明確になります。

マルチプロセスアセットバンドルビルドの有効化

ユーザーインターフェースで新機能を有効にするには、以下の手順に従います。

  1. Editor 設定を開きます (トップメニュー:__Edit > Project Settings__ を選択し、Editor カテゴリを選択します)。
  2. Multi-Process AssetBundle Building のチェックボックスをクリックします。

この設定は、 EditorBuildSettings.UseParallelAssetBundleBuilding を使用してスクリプトに公開されます。

相違点と既知の制限

  • マルチプロセスアセットバンドルビルドを使用すると、メッシュの最適化は有効になりません。ビルド中は強制的に “オフ” になります。注意実際には、メッシュの最適化はビルドプロセスのコストを高くしプロセスを複雑にします。そして多くの場合、ランタイムにはあまり効果がありません。
  • Sprite Atlas V1 はサポートされていません。この古い形式が検出されると、エラーが出力されます。ビルドを成功させるには、V1 アセットを SpriteAtlasV2 に更新する必要があります。
  • オブジェクトが互いにどう影響し合うかが、個々のアセットバンドルの範囲ではなく、すべてのアセットバンドルで計算されるようになりました。例えば、マテリアルで特定のシェーダー機能を有効にする必要がある場合は、シェーダーが異なるアセットバンドルに含まれていても、そのシェーダー機能が有効になります。これにより、通常期待される結果に近付きますが、特にシェーダーが複数のアセットバンドルで繰り返される場合は、シェーダーのコンパイル時間が長くなる可能性があります。詳細については、シェーダーキーワード を参照してください。
  • 入力が同一でも、マルチプロセスビルドの出力は、非マルチビルドとバイナリ的に同一になりません。ただし、機能的には同一になる必要があります。つまり、すでにアセットバンドルをユーザーに配布している場合、マルチプロセスビルドを使用するようにプロジェクトを更新すると、すべてのアセットバンドルファイルが変更される可能性があります。次のリリースをプッシュすると、ライブユーザーのダウンロードがトリガーされます。バイナリの違いは、改善とバグ修正によるもので、アセットバンドル内のオブジェクトの名前や順序が若干異なる可能性があります。
  • AssetDatabase を使用して中間ビルドアーティファクトをキャッシュするため、プロジェクトの Library フォルダーで使用されるディスクスペースが大きくなる可能性があります。これらのアーティファクトは、BuildAssetBundleOptions.ForceRebuildAssetBundle フラグを指定すると、ビルドの開始時に完全にフラッシュされます。
  • マルチプロセスを有効にすると、アセットバンドルハッシュはアセットバンドルの非圧縮コンテンツのハッシュ値になります。これは、圧縮とは関係なく、アセットバンドルヘッダーのコンテンツが組み込まれない、ファイルバージョン識別子として機能します。ヒント: BuildAssetBundleOptions.AssetBundleStripUnityVersion フラグは、アセットバンドルのコンテンツから Unity バージョンを除外することで、ハッシュからも除外するのに便利です。
  • この新しいハッシュ計算方法では、ハッシュはフルビルド実行によってのみ決定できます。したがって、 BuildPipeline.BuildAssetBundles が BuildAssetBundleOptions.DryRunBuild で呼び出されると、 AssetBundleManifest.GetAssetBundleHash は 0 を返します。

ビルドコールバック

ビルドコールバックを使用する既存のプロジェクトをマルチプロセスアセットバンドルビルドと連携するように適応させる場合は、ビルドコールバックコードのコード変更が必要になる場合があります。

ビルド中に、シーンファイルがロードされて、出力形式に再保存されます。スクリプトコードは、この間に、例えば IProcessSceneWithReport.OnProcessScene ビルドコールバックを介して実行されます。マルチプロセスアセットバンドルビルドを使用する場合、このスクリプトコードは AssetDatabase ワーカープロセス内のインポートジョブのコンテキストで実行されます。これは、ScriptedImporter の実行方法と同様です。

ロードされたシーンの状態だけで機能するシーンコールバックの場合、AssetDatabase インポーターの一部として実行しても問題はありません。ただし、以下のような特定の状況では問題が生じる可能性があります。

  • アセットの変更。ビルドコールバック内から外部アセットを作成、削除、変更しないでください。アセットを変更する AssetDatabase API の呼び出しを防ぐ特定の保護が追加されています。このような呼び出しが行われた場合は、スクリプト例外がスローされ、明確なエラーメッセージが表示されます。

  • 依存関係の追跡。コンテキストによっては、ビルドコールバックがシーン外の他のアセットのコンテンツを読み取る必要があります。シーンがそのアセットも明示的に参照している場合は、追加の変更をしなくても、この読み取りは正しく機能します。参照していない場合は、新しい BuildPipelineContext.DependOnAsset 呼び出しを使用するようにビルドコールバックの実装を更新して、依存関係を追跡する必要があります。そうしないと、将来のインクリメンタルビルドで、キャッシュされた古いアーティファクトが再利用される可能性があり、コールバックスクリプトが呼び出されません。

  • シングルトンとグローバル状態。新しいビルドシステムのマルチプロセスの特性は、シーンやその他のアセットがメインの Unity プロセス内ですべて順番にロードされるのではなく、異なるワーカープロセスでロードされることを意味します。これは、シングルトンなどのグローバルデータへの共有アクセスを使用するコードが機能しなくなる可能性がある、ということです。シーン内、アセット内、場合によっては一時ファイル内に直接保存されたデータを使用するには、共有メモリーに依存するコードを再作成する必要がある場合があります。

コールバックのバージョン管理

キャッシュのため、インクリメンタルビルドは、シーンまたは別の依存関係が最後のビルド以降に変更された場合にのみ、ビルドコールバックを呼び出します。スクリプトコールバックが変更され、再度実行する必要がある場合は、コールバックの BuildCallbackVersion 属性を増加させることで、これを強制的に実行できます。この属性を指定しないコールバックの場合、デフォルトのバージョン番号は 1 です。

ノート: ビルド中にスクリプトコードが呼び出される状況は他にもあります。例えば、ExecuteInEditMode 属性を持つ、MonoBehaviour 派生クラスの Awake メソッドなどです。AssetDatabase のインポート中に許可されていないアクションをコードで実行している場合は、そのコードの変更が必要な場合があります。ヒント: BuildPipeline.isBuildingPlayer API はアセットバンドルのビルド中に true を返すため、これを使用して条件ロジックを追加できます。例えば、ビルド中に問題のあるコードの実行を避けながらも、再生モードに入るときはこのコードを許可することができます。

高度なトラブルシューティングのための診断フラグ

アセットバンドルのトラブル のトピックで説明されている一般的なテクニックとツールに加え、Preference ウィンドウで使用可能ないくつかの 診断フラグ が、アセットバンドルビルドに関する詳細情報の収集に役立ちます。これらのフラグは高度な使用を意図しており、将来変更または削除される可能性があります。

後方互換モード

BuildPipelineBinaryBackwardCompatibilityMode 診断フラグは、マルチプロセスアセットバンドルビルドに固有のフラグです。有効にすると、特定の動作が変更されて、既存のアセットバンドルビルドロジックの動作により適合します。このフラグを有効にすると、アセットバンドルのバイナリコンテンツが、マルチプロセスプロジェクト設定をオフにして実行されたビルドとまったく同じになる場合があります。このフラグはデフォルトではオフになっています。これは、アセットバンドルコンテンツの違いのほとんどが意図的な改善の結果であり、互換性モードが将来削除される可能性があるためです。ただし、このフラグは、アセットバンドルコンテンツへの影響を最小限に抑えることが重要である既存のプロジェクトで役立つ場合があります。

ビルドプロファイリング

BuildPipelineTEPCapture 診断フラグを有効にすると、BuildPipeline.BuildAssetBundles の呼び出しで “トレースイベント” 形式のプロファイラーファイルが生成されます。このファイルを使用して、各 AssetDatabase ワーカープロセスで実行されたステップなど、ビルドで実行されたステップの詳細を把握できます。

このファイルはビルドごとに上書きされ、パス Logs/BuildAssetBundlesTEP.json にあります。これは、Chrome のトレースでサポートされているファイル形式です。詳細については、Trace Event Format を参照してください。このコンテンツを表示する方法の 1 つは、Google Chrome または別の Chromium ベースのブラウザーの chrome://tracing ツールで開くことです。

ビルドデバッグファイル

BuildPipelineWriteDebugFiles フラグはマルチプロセスアセットバンドルビルドに固有のフラグです。有効にすると、ビルドで Temp/BuildInstructions フォルダーに余分な JSON 形式ファイルが書き込まれます。これらのファイルは、テストとデバッグの目的でのみ役立ち、ビルド自体には不要であり使用されません。Unity にバグレポートを送信する場合、特にプロジェクト全体を提出できない場合に、これらのファイルを提供すると役立ちます。

ビルドの出力
AssetBundle compression formats