The Resources folder
Vérifié avec version: 5.3
This is the third chapter in a series of articles covering Assets, Resources and resource management in Unity 5.
This chapter discusses the Resources system. This is the system that allows developers to store Assets within one or more folders named Resources and to load or unload Objects from those Assets at runtime using the Resources API.
Don't use it.
This strong recommendation is made for several reasons:
- Use of the Resources folder makes fine-grained memory management more difficult.
- Improper use of Resources folders will increase application startup time and the length of builds.
- As the number of Resources folders increases, management of the Assets within those folders becomes very difficult.
- The Resources system degrades a project's ability to deliver custom content to specific platforms and eliminates the possibility of incremental content upgrades.
- AssetBundle Variants are Unity's primary tool for adjusting content on a per-device basis.
There are two specific use cases where the Resources system can be helpful without impeding good development practices:
Resources is an excellent system for during rapid prototyping and experimentation because it is simple and easy to use. However, when a project moves into full production, it is strongly recommended to eliminate uses of the Resources folder.
The Resources folder is also useful in trivial cases, when all of the following conditions are met:
- The content stored in the Resources folder is not memory-intense
- The content is generally required throughout a project's lifetime
- The content rarely requires patching
- The content does not vary across platforms or devices.
Examples of this second case include a globally-used prefab hosting singleton MonoBehaviours or an Asset hosting third-party configuration data, such as a Facebook App ID.
The Assets and Objects in all folders named "Resources" are combined into a single serialized file when a project is built. This file also contains metadata and indexing information, similar to an AssetBundle. As described in the Sidebar: What's in an AssetBundle? section of the AssetBundle fundamentals chapter, this indexing information includes a serialized lookup tree that is used to resolve a given Object's name into its appropriate File GUID and Local ID. It is also used to locate the Object at a specific byte offset in the serialized file's body.
As the lookup data structure is (on most platforms) a balanced search tree(1), its construction time grows at an O(N log(N)) rate, where N is the number of Objects indexed within the tree. This growth also causes the index's loading time to grow more-than-linearly as the number of Objects in Resources folders increases.
This operation is unskippable and occurs at application startup time while the initial non-interactive splash screen is displayed. Initializing a Resources system containing 10,000 assets has been observed to consume multiple seconds on low-end mobile devices, even though most of the Objects contained in Resources folders are rarely actually needed to load into an application's first scene.
- On most platforms, it is a
std::multimapfrom the C++ Standard Template Library. ↩