AssetBundles
An AssetBundle is an archive file that contains platform-specific non-code Assets (such as Models, Textures, Prefabs, Audio clips, and even entire Scenes) that Unity can load at run time. AssetBundles can express dependencies
See in Glossary between each other; for example, a Material in one AssetBundle can reference a Texture in another AssetBundle. For efficient delivery over networks, you can compress AssetBundles with a choice of built-in algorithms depending on use case requirements (LZMA and LZ4).
AssetBundles can be useful for downloadable content (DLC), reducing initial install size, loading assets optimized for the end-user’s platform, and reduce runtime memory pressure.
Note: An AssetBundle can contain the serialized data of an instance of a code object, such as a ScriptableObject. However, the class definition itself is compiled into one of the Project assemblies. When you load a serialized object in an AssetBundle, Unity finds the matching class definition, creates an instance of it, and sets that instance’s fields using the serialized values. This means that you can introduce new items to your game in an AssetBundle as long as those items do not require any changes to your class definitions.
What’s in an AssetBundle?
“AssetBundle” can refer to two different, but related things.
First is the actual file on disk. This is called the AssetBundle archive. The AssetBundle archive is a container, like a folder, that holds additional files inside it. These additional files consist of two types:
- A serialized file, which contains your Assets broken out into their individual objects and written out to this single file.
- Resource files, which are chunks of binary data stored separately for certain Assets (Textures and audio) to allow Unity to efficiently load them from disk on another thread.
“AssetBundle” can also refer to the actual AssetBundle object you interact with via code to load Assets from a specific AssetBundle archive. This object contains a map of all the file paths of the Assets you added to this archive.
For more information, see the tutorial on Assets, Resources and AssetBundles.
Note: The “AssetBundle Manager” was a tool used with older versions of Unity that helped streamline Asset management using AssetBundles. Starting with Unity version 2018.2, you should use the Addressable Assets package instead, as Unity has deprecated the AssetBundle Manager.
Источник
Building AssetBundles
In the documentation on the AssetBundle Workflow, we have a code sample which passes three arguments to the BuildPipeline.BuildAssetBundles function. Let’s dive a little deeper into what we’re actually saying.
Assets/AssetBundles: This is the directory that the AssetBundles will be output to. You can change this to any output directory you desire, just ensure that the folder actually exists before you attempt a build.
BuildAssetBundleOptions
There are several different BuildAssetBundleOptions that you can specify that have a variety of effects. See Scripting API Reference on BuildAssetBundleOptions for a table of all the options.
While you’re free to combine BuildAssetBundleOptions as needs change and arise, there are three specific BuildAssetBundleOptions that deal with AssetBundle Compression A method of storing data that reduces the amount of storage space it requires. See Texture Compression, Animation Compression, Audio Compression, Build Compression.
See in Glossary :
BuildAssetBundleOptions.None : This bundle option uses LZMA Format compression, which is a single compressed LZMA stream of serialized data files. LZMA compression requires that the entire bundle is decompressed before it’s used. This results in the smallest possible file size but a slightly longer load time due to the decompression. It is worth noting that when using this BuildAssetBundleOptions, in order to use any assets from the bundle the entire bundle must be uncompressed initially.
Once the bundle has been decompressed, it will be recompressed on disk using LZ4 compression which doesn’t require the entire bundle be decompressed before using assets from the bundle. This is best used when a bundle contains assets such that to use one asset from the bundle would mean all assets are going to be loaded. Packaging all assets for a character or scene are some examples of bundles that might use this.
Using LZMA compression is only recommended for the initial download of an AssetBundle from an off-site host due to the smaller file size. LZMA compressed asset bundles loaded through UnityWebRequestAssetBundle are automatically recompressed to LZ4 compression and cached on the local file system. If you download and store the bundle through other means, you can recompress it with the AssetBundle.RecompressAssetBundleAsync API.
BuildAssetBundleOptions.UncompressedAssetBundle : This bundle option builds the bundles in such a way that the data is completely uncompressed. The downside to being uncompressed is the larger file download size. However, the load times once downloaded will be much faster. Uncompressed AssetBundles are 16-byte aligned.
BuildAssetBundleOptions.ChunkBasedCompression : This bundle option uses a compression method known as LZ4, which results in larger compressed file sizes than LZMA but does not require that entire bundle is decompressed, unlike LZMA, before it can be used. LZ4 uses a chunk based algorithm which allows the AssetBundle be loaded in pieces or “chunks.” Decompressing a single chunk allows the contained assets to be used even if the other chunks of the AssetBundle are not decompressed.
Using ChunkBasedCompression has comparable loading times to uncompressed bundles with the added benefit of reduced size on disk.
BuildTarget
BuildTarget.Standalone : Here we’re telling the build pipeline which target platform we are going to be using these AssetBundles for. You can find a list of the available explicit build targets in the Scripting API Reference for BuildTarget. However, if you’d rather not hardcode in your build target, feel free to take advantage of EditorUserBuildSettings.activeBuildTarget which will automatically find the platform you’re currently setup to build for and build your AssetBundles based on that target.
Once you’ve properly set up your build script, it’s finally time to build your bundles. If you followed the script example above, click Assets Any media or data that can be used in your game or project. An asset may come from a file created outside of Unity, such as a 3D Model, an audio file or an image. You can also create some asset types in Unity, such as an Animator Controller, an Audio Mixer or a Render Texture. More info
See in Glossary > Build AssetBundles to kick off the process.
Now that you’ve successfully built your AssetBundles, you may notice that your AssetBundles directory has more files than you might have originally expected. 2*(n+1) more files, to be exact. Let’s take a minute and go over exactly what the BuildPipeline.BuildAssetBundles yields.
For every AssetBundle you specified in the editor, you’ll notice a file with your AssetBundle name and your AssetBundle name + “.manifest”.
There will be an additional bundle and manifest that doesn’t share a name with any AssetBundle you created. It, instead, is named after the directory that it’s located in (where the AssetBundles were built to). This is the Manifest Bundle. We’ll discuss more about this and how to use it in the future.
The AssetBundle File
This is the file that lacks the .manifest extension and what you’ll be loading in at runtime in order to load your Assets.
The AssetBundle file is an archive that contains multiple files internally. The structure of this archive can change slightly depending on if it is an AssetBundle or a Scene A Scene contains the environments and menus of your game. Think of each unique Scene file as a unique level. In each Scene, you place your environments, obstacles, and decorations, essentially designing and building your game in pieces. More info
See in Glossary AssetBundle. This is the structure of a normal AssetBundle:
The Scene AssetBundle is different to normal AssetBundles, in that it is optimized for stream loading of a Scene and its content.
The Manifest File
For every bundle generated, including the additional Manifest Bundle, an associated manifest file is generated. The manifest file can be opened with any text editor and contains information such as the cyclic redundancy check (CRC) data and dependency
See in Glossary data for the bundle. For the normal AssetBundles their manifest file will look something like this:
Which shows the contained assets, dependencies, and other information.
The Manifest Bundle that was generated will have a manifest, but it’ll look more like this:
This will show how AssetBundles relate and what their dependencies are. For now, just understand that this bundle contains the AssetBundleManifest object which will be incredibly useful for figuring out which bundle dependencies to load at runtime. To learn more about how to use this bundle and the manifest object, see documentation on Using AssetBundles Natively.
Источник
Play Asset Delivery
Play Asset Delivery (PAD) is a Google Play Store feature you can use to deliver applications that are larger than 150MB. Instead of using APK expansion files (OBB) to store additional assets (such as textures, sounds, and meshes), PAD uses asset packs. Google hosts and serves asset packs on Google Play, which means you don’t need to create a content delivery network to send application resources to users. For more information about PAD, see Android’s Play Asset Delivery.
Important: PAD is only available for the Google Play Store. If you have a large application and want to support other digital distribution services, use APK expansion files (OBB).
Using Play Asset Delivery
To use Play Asset Delivery, you need to set up your project to build Android App Bundles and split the application binary.
To configure Unity to build Android App Bundles:
- Open Build Settings (menu: File >Build Settings).
- In Platform, select Android.
- If Export Project is enabled, enable Export for App Bundle. Otherwise, enable Build App Bundle (Google Play).
To configure Unity to split the application binary:
- Open Player Settings (menu: Edit >Project Settings then select Player).
- Select the Android settings tab and open the Publishing Settings section.
- Enable Split Application Binary.
Now when you build your application, Unity generates an Android App Bundle that includes your application split into a base module and asset packs.
- Base module: Contains the executables (Java and native), plug-ins A set of code created outside of Unity that creates functionality in Unity. There are two kinds of plug-ins you can use in Unity: Managed plug-ins (managed .NET assemblies created with tools like Visual Studio) and Native plug-ins (platform-specific native code libraries). More info
See in Glossary , scripts A piece of code that allows you to create your own Components, trigger game events, modify Component properties over time and respond to user input in any way you like. More info
See in Glossary , and assets in the first scene A Scene contains the environments and menus of your game. Think of each unique Scene file as a unique level. In each Scene, you place your environments, obstacles, and decorations, essentially designing and building your game in pieces. More info
See in Glossary . The first scene is the scene that has a build index of 0. - Asset packs: Contains everything else, including the remaining scenes, resources, and streaming assets. For more information about the asset packs that Unity generates at build time, see Generated asset packs.
Alongside the asset packs that Unity generates automatically, you can also create your own custom asset packs. This is useful when you need to control what an asset pack contains. Unity adds your custom asset packs to the final Android App Bundle. For more information about custom asset packs and how to set them up, see Custom asset packs.
Generated asset packs
Asset packs have download size limits. To account for this, Unity changes how it generates asset packs depending on the size of your additional assets:
- If the additional assets take less than 1GB of storage, Unity packs everything into a single asset pack with the install-time delivery mode. If you do not create any custom asset packs, this means that the device downloads the asset pack as part of the application installation and, when the user first launches the application, all assets are available.
- If the additional assets take more than 1GB of storage, Unity packs streaming assets into one asset pack and packs all other additional assets into another asset pack. Unity assigns the install-time delivery mode to the larger asset pack and assigns the fast-follow delivery mode to the smaller one.
Note: If either of these asset packs is larger than the upload limit the Google Play Store allows, Unity displays a warning but doesn’t fail the build. Also, Unity checks the sizes of asset packs individually and doesn’t perform size verification for custom asset packs. This means that, if a combination of custom asset packs and asset packs that Unity generates is too large for the Google Play Store, Unity doesn’t display a warning or error.
For asset packs that Unity automatically generates, Unity does not support changing the delivery mode. If you want to change the delivery mode of an asset pack, create custom asset packs with your assets.
Managing asset packs at runtime
Unity provides APIs to manage asset packs at runtime. They use Google’s PlayCore API, which means they have the same limitations as PlayCore, and can’t manage install-time asset packs. Using the PlayCore API also means your application requires the PlayCore plugin. If your project has asset packs, either custom asset packs or Unity-generated asset packs, Unity automatically adds the PlayCore dependency
See in Glossary to the application’s manifest.
The way you download asset packs and access their assets depends on the asset pack delivery mode. There are three asset pack delivery modes:
- install-time : Google Play automatically downloads install-time asset packs when the device installs the application. Google Play considers these asset packs to be part of the base application, and an end user can’t uninstall them without uninstalling the entire application. The PlayCore API doesn’t handle install-time asset packs, which means that you can’t check the status, request to download, or remove install-time asset packs. You also can’t directly access assets inside of these asset packs, except streaming assets in Unity-generated install-time asset packs. To access streaming assets, use Application-streamingAssetsPath to get the path to streaming assets location, then use UnityWebRequest to access assets in that path. If you create a custom asset pack, you can’t access assets inside it using standard file APIs. Instead, use Android’s AssetManager APIs.
- fast-follow : Google Play automatically starts to download fast-follow asset packs after it installs the application. However, it is possible that not all fast-follow asset packs are available on the first time the application launches. To check the status and download fast-follow asset packs, see below.
- on-demand : Google Play doesn’t automatically download on-demand asset packs. You have to manually start the download. For information on how to do this, see below.
For more information about delivery modes, see Delivery modes.
If your application uses fast-follow or on-demand asset packs, the device must download these asset packs before the application can access assets inside of them. To check the status of asset packs and download them if they are not on the device, you must first know the name of each asset pack. To get the names of Unity-generated asset packs, call AndroidAssetPacks.GetCoreUnityAssetPackNames. There is no runtime API to get the names of custom asset packs so you must keep track of them yourself. You set the name of custom asset packs at build time; it’s the name of the directory.
After you have the names of your asset packs, to check the status of each asset pack, call AndroidAssetPacks.GetAssetPackStateAsync, passing in the asset pack name. This returns the status of the asset pack you query, and you can use the result to determine whether you need to download the asset pack. If you want to quickly query the status of every Unity-generated asset pack, you can use AndroidAssetPacks.coreUnityAssetPacksDownloaded. This is useful because you must ensure that every Unity-generated asset pack is available before you load any scene other than the first one or try to access other resources that Unity handles.
For every asset pack you need to download, call AndroidAssetPacks.DownloadAssetPackAsync, passing in the asset pack name. While the asset pack downloads, monitor the download status, because downloads can pause or fail. There are two ways to do this:
- Periodically check the DownloadAssetPackAsyncOperation instance that AndroidAssetPacks.DownloadAssetPackAsync returns.
- Use the version of AndroidAssetPacks.DownloadAssetPackAsync that takes a callback as its second parameter. The callback you pass in must take an AndroidAssetPackInfo as a parameter which you can use to determine the state of the download.
Custom asset packs
If you want to control which non-code resources are in a particular asset pack, you can create a custom asset pack. Unlike Unity-generated asset packs, you can set the delivery mode for custom asset packs. If you create a custom asset pack, be aware that the Google Play Store has size and quantity limits for asset packs. For information on the limits, see Download size limits.
To create a custom asset pack, create a directory with a name that ends with .androidpack. You can place this directory anywhere in your project’s Assets directory, or any subdirectory. For example, to create a custom asset pack named MyAssets1:
- Go to the directory you want to create the asset pack in. This could be directly in Assets or a subdirectory like Assets/CustomAssetPacks.
- Create a new directory and call it MyAssets1.androidpack. To add any assets to the asset pack, place them inside this folder. Note: Unity doesn’t include empty asset packs in builds. Also, asset pack names must begin with a letter and consist of English alphanumeric characters or an underscore.
- By default, the delivery mode is on-demand , which means that if you don’t change the delivery mode, you need to manually download the asset pack at runtime. For information on how to do this, see Managing asset packs at runtime.
- To use a different delivery mode, create a file called build. gradle An Android build system that automates several build processes. This automation means that many common build errors are less likely to occur. More info
See in Glossary inside the custom asset pack directory. Paste the following into the file:
This sets the delivery mode to fast-follow , which means Google Play automatically downloads the asset pack after it installs the application. For information on the format of this file, see Integrate asset delivery.
Источник