The Resources folder
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
2.2. Proper uses of the Resources system
There are two specific use cases where the Resources system can be helpful without impeding good development practices:
The ease of the Resources folder makes it an excellent system to rapidly prototype. However, when a project moves into full production, the use of the Resources folder should be eliminated.
The Resources folder may be useful in some trivial cases, if the content is:
Generally required throughout a project's lifetime
Not prone to patching, or does not vary across platforms or devices
Used for minimal bootstrapping
Examples of this second case include MonoBehaviour singletons used to host prefabs, or ScriptableObjects containing third-party configuration data, such as a Facebook App ID.
2.3. Serialization of Resources
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 AssetBundle documentation, this index 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.
On most platforms, the lookup data structure is a balanced search tree, which has a construction time that grows at an O(n log(n)) rate. 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.