這部分主要討論了Resources系統使用的相關問題。Resources目錄允許開發者在一個或者多個Resources目錄下存放Asset文件，在運行時可以通過Resources系統的相關API去加載和卸載Asset中的Object對象。
Resources系統的最佳實踐方式
最好不要使用Resources系統。原因如下：
- 使用Resources目錄會導致粒度管理內存變得困難。
- Resources文件夾的不合理使用會導致啟動時間很長，而且會增加包的體積。
- 隨著Resources目錄的增加，這些文件夾內的Asset管理也會很復雜。
- Resources文件夾的使用還會影響針對不同平臺分發特定內容的功能以及更新，而AssetBundle變量可以針對不同的設備或者平臺進行控制。
可以使用Resources系統的少數情況
Resources在某些特殊的情境下也是可以使用的，但是需要滿足如下的情況，否則還是建議不要使用：
Resources系統對于原型開發和實驗階段的產品而言比較好，因為簡單容易使用。但是，最后確定推出產品的時候，還是應該去掉Resources系統的管理，改用AssetBundle系統。
Resources在其他的情境下使用需要滿足如下的條件：
- Resources里面不能存放太多內容，而且不能有非常占據內存的資源。
- 整個工程運行過程中都始終需要這部分的內容。
- 這部分的內容極少需要被替換，不需要做補丁。
- 和平臺與設備無關，所有平臺上都有這部分的內容。
第二種情況適用的例子包括：持有單例MonoBehaviour的全局Prefab【照相機Prefab】或者某個Asset包含第三方的配置數據文件，如Facebook APP id這些內容。
Resources系統的序列化
所有命名為Resources文件夾中的Asset和Object在打包過程中都會被處理成一個單一的序列化文件，這個文件和AssetBundle文件類似，包含metadata和索引信息，索引信息是一個序列化之后的查找樹結構，用來將給定的Object的名稱和對應的文件GUID和局部ID建立聯系，還包括用來在序列化之后的文件中Object的偏移量。
在大部分平臺上，這個查找樹的數據結構是一個平衡二叉樹【在大多數平臺上，是通過std::multimap的C++標準模板庫實現的】，構建復雜度是O(N·log(N))，N代表查找樹中的Object數目。隨著Resources系統中文件數目的增加，復雜度的增長速度是快于線性增長的。
這個操作在啟動階段是不可避免的，初始化一個超過10000個Asset的Resources系統在低端設備上超過數十秒，盡管這些Asset在第一個游戲場景中根本不會被用到。
