How you load and manage assets in your project impacts on your application’s memory usage, load times, and build size. Unity provides several asset management systems, each designed for specific use cases and project sizes. Small applications with fixed content sizes can usually use Unity’s default asset management system. Systems like AssetBundles and Addressables provide better management for complex asset layouts, or applications that need to stream assets from remote servers.
By default, Unity uses the Scene List to determine which scenes and assets to include in a build and their load order. Unity only includes scenes in the SceneA 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 List in a build, and unused scenes and assets not referenced from these scenes are excluded from a build. You can also use the SceneManager API to determine how to load scenes in your project.
The exception to this is if you include any scenes in a Resources folder, or mark them as Addressable, then Unity handles scenes differently.
To determine what content to build, Unity uses the following information:
Resources folder.Choosing the right approach depends on factors like your target platform, content delivery requirements, and whether you need dynamic loading capabilities. The following management systems are available:
| System | Remote/CDN delivery | Incremental updates | Automatic dependencies | Dynamic load/unload | Best suited for |
|---|---|---|---|---|---|
| Direct references | No | No | Yes | No | Small applications with fixed content built into the Player. |
| Resources system | No | No | Yes | Yes (no per-asset unload) | Prototypes and small projects that need assets for the whole application lifetime. |
| Content directories | No (local only) | Yes (local distribution) | Yes | Yes | New projects that need local supplementary content shipped with the Player, such as optional DLC or expansion packs. |
| AssetBundle system | Yes | Yes | No (manual) | Yes (manual memory management) | Existing projects that already use AssetBundles, or need remote content pipelines with script-level control. |
You can additionally use the following packages depending on your project type:
If you want to create separate content builds through the content directories or AssetBundles system, then the Addressables package provides an Editor interface for organizing your assets into content builds. Originally built on top of the AssetBundle architecture, it’s also compatible with content directories. Addressables automatically manages dependencies, asset locations, and memory allocation, which you otherwise have to handle manually in the AssetBundle or content directory systems. The Addressables package aims to remove the limitations of the Resources, AssetBundle, and content directory systems to make it easier to manage assets on demand.
Once you have made an asset Addressable, you can reference it by address in your code, which means you can change the location of an asset without needing to rewrite any code. You can also use asset references to dynamically load and unload assets, so that you don’t always have to keep all assets in the scene in memory.
The Addressables system is designed for applications that are likely to have content updates over time. If your application has fixed content which is shipped in the initial download, then using direct references, or the Resources system is a better alternative.
For more information, refer to Addressables overview
The Entities package has its own content management system, where you use weak references to assets to load them at runtime. You can also create content archives to deliver content to an application. For more information, refer to Introduction to content management.