資源文件夾
版本檢查：2017.3 - 難度：高級
這是關於資產，資源和資源管理系列文章的第三章。
本章討論資源系統。這是一個允許開發人員將資產存儲在名爲Resources的一個或多個文件夾中的系統，以及使用資源在運行時從這些資產加載或卸載對象的系統。
2.1.資源系統的最佳實踐
不要使用它。
這個強有力的建議有幾個原因：
* 使用Resources文件夾會使細粒度的內存管理變得更加困難
* 資源文件夾使用不當會增加應用程序啓動時間和構建時間
* -隨着資源文件夾數量的增加，這些文件夾中資產的管理變得非常困難
* 資源系統降低了項目將定製內容傳送到特定平臺的能力，並消除了增量內容升級的可能性
* -AssetBundle變體是Unity用於根據設備調整內容的主要工具
2.2.正確使用資源系統
在不妨礙良好開發實踐的情況下，資源系統有助於兩種具體用例：
Resources文件夾的簡易性使其成爲快速原型的優秀系統。但是，當項目進入全面生產階段時，應取消使用Resources文件夾。
如果內容是：Resources文件夾可能在一些微不足道的情況下很有用。
- 一般在項目的整個生命週期中都需要
- 不是內存密集型的
- 不容易修補，或不跨平臺或設備不同
- 用於最小自舉
第二種情況的例子包括用於託管預製件的MonoBehaviour單件，或包含第三方配置數據（如Facebook應用程序ID）的ScriptableObjects
2.3.源序列化
在構建項目時，名爲“資源”的所有文件夾中的資產和對象都合併爲單個序列化文件。該文件還包含元數據和索引信息，類似於AssetBundle。如AssetBundle文檔中所述，此索引包含一個序列化的查找樹，用於將給定對象的名稱解析爲適當的文件GUID和本地ID。它也用於在序列化文件正文中的特定字節偏移處定位對象。
在大多數平臺上，查找數據結構是一個平衡搜索樹，其構建時間以O（n log（n））速率增長。隨着資源文件夾中對象數量的增加，這種增長也會導致索引的加載時間增長超過線性。
此操作是不可跳過的，並且在顯示初始非交互式啓動畫面時出現在應用程序啓動時。據觀察，初始化包含10,000個資產的資源系統在低端移動設備上會消耗多秒，即使資源文件夾中包含的大部分對象很少真正需要加載到應用程序的第一個場景中。