第2章 Resources文件夹详解

2、Resources文件夹详解：Resources.Load()与Resources.LoadAsync()的使用方法，Resources文件夹的优缺点分析，Resources文件夹的适用场景与性能陷阱

2.1 初识Resources：Unity的“万能背包”

Resources文件夹，说白了就是Unity给开发者准备的一个“万能背包”。你把资源往里面一扔，代码里就能直接加载。我刚入行那会儿，觉得这玩意儿太方便了——不用管路径、不用管依赖，一个Load()搞定一切。

但后来我踩了坑才明白：这个背包是有重量的。你塞得越多，游戏启动就越慢，包体也越臃肿。嗯，咱们先看看怎么用，再聊聊它的坑。

2.2 Resources.Load()：同步加载，简单粗暴

这是最基础的用法。你写一行代码，资源就出来了。我习惯在编辑器工具或者测试脚本里用它，因为够快、够直接。

// 加载一个预制体
GameObject prefab = Resources.Load<GameObject>("Enemies/Enemy_Tank");
Instantiate(prefab);

// 加载一张纹理
Texture2D tex = Resources.Load<Texture2D>("Textures/UI_Btn_Bg");

// 加载一个文本文件
TextAsset config = Resources.Load<TextAsset>("Configs/GameSettings");
string json = config.text;

注意路径写法：从Resources文件夹开始，不用写扩展名。我在项目中遇到过有人写了“.prefab”后缀，结果加载失败——Unity会自动匹配，别画蛇添足。

⚠️ 性能警告：

Resources.Load()是同步操作。如果你在游戏主线程里加载一个几MB的纹理，画面会卡住。我见过一个项目，加载界面时直接卡了3秒——就是因为用Load()加载了所有UI图集。

2.3 Resources.LoadAsync()：异步加载，不卡主线程

如果你不想让玩家等得想砸手机，那就用异步加载。LoadAsync()会在后台加载资源，不阻塞主线程。我个人习惯在加载场景、大纹理或者复杂预制体时，优先考虑它。

// 异步加载一个角色模型
ResourceRequest request = Resources.LoadAsync<GameObject>("Characters/Player_Model");

// 等待加载完成
yield return request;

// 获取加载的资源
GameObject playerModel = request.asset as GameObject;
Instantiate(playerModel);

这里有个细节：ResourceRequest的progress属性可以让你做进度条。我曾经用这个做过一个加载动画，效果还不错。

// 带进度条的异步加载
ResourceRequest request = Resources.LoadAsync<GameObject>("Characters/Player_Model");

while (!request.isDone)
{
    float progress = request.progress;
    // 更新UI进度条
    loadingSlider.value = progress;
    yield return null;
}

// 加载完成
GameObject playerModel = request.asset as GameObject;

💡 小技巧：

LoadAsync()虽然不卡主线程，但如果你在协程里用yield return request，它其实还是串行的。想要真正的并行加载多个资源？可以用多个协程同时跑，或者用Addressables——那是后话了。

2.4 Resources文件夹的优缺点分析

咱们来掰扯掰扯这个文件夹的优缺点。我做了这么多年项目，总结下来就一句话：小项目用着爽，大项目用着痛。

优点	缺点
使用简单，无需管理路径	所有资源都会被打进主包，无法热更新
加载方便，代码量少	启动时Unity会构建资源索引，资源越多越慢
适合原型开发和快速迭代	无法按需卸载，内存容易爆炸
依赖关系自动处理	资源冗余严重，同一个资源可能被多次打包
跨平台兼容性好	不利于团队协作，资源冲突难排查

你想想看，一个中型游戏光UI图集就有几百MB。如果全塞进Resources，启动时Unity要扫描所有资源建立索引——我见过一个项目启动花了40秒，就因为这个。

2.5 适用场景：什么时候该用Resources？

我个人的经验是：Resources文件夹适合放那些必须随包体发布、且不会频繁变更的资源。比如：

启动引导资源：Logo、启动界面、核心UI框架
基础Shader和材质：所有场景公用的渲染资源
配置文件：游戏设置、默认参数等JSON/XML
小体量资源：图标、音效、字体等几KB到几百KB的资源
编辑器工具资源：只在开发阶段使用的测试资源

说白了，Resources适合放“死”资源——那些你确定不会改、不需要热更新的东西。我在一个休闲游戏项目里，只把启动Logo和默认字体放进了Resources，其他全用AssetBundle管理，效果很好。

2.6 性能陷阱：这些坑我替你踩过了

好了，重点来了。Resources文件夹的坑，我一个个说给你听。

陷阱一：启动时间爆炸

Unity在游戏启动时会扫描所有Resources文件夹，建立资源索引。资源越多，扫描越慢。我曾经接手过一个项目，Resources里有3000+个资源，启动时间直接飙到25秒。

解决方案：严格控制Resources里的资源数量，建议不超过200个。大资源用AssetBundle，小资源用Resources。

陷阱二：内存泄漏

Resources.Load()加载的资源，如果你不主动UnloadUnusedAssets()，它们会一直留在内存里。我见过一个团队，加载了100个角色模型，一个都没卸载——内存直接飙到2GB。

解决方案：用完即卸。可以用Resources.UnloadUnusedAssets()，但注意这个操作很慢，别在游戏运行时频繁调用。

陷阱三：资源冗余

同一个资源如果被多个预制体引用，Unity会把它打包多次。比如一个“子弹”材质被10个敌人预制体引用，最终包体里会有10份相同的材质。

解决方案：用AssetBundle的依赖管理，或者用Addressables的依赖分组功能。

陷阱四：无法热更新

Resources里的资源是打进主包的，玩家下载后无法修改。如果你想修复一个贴图错误，必须重新发版。这在手游时代简直是灾难。

解决方案：所有可能更新的资源，都放到AssetBundle里。Resources只放“打死也不改”的资源。

⚠️ 避坑指南：

我曾经在一个MMO项目里，把整个UI系统都塞进了Resources。结果每次更新UI都要重新打渠道包，运营团队差点没把我骂死。从那以后，我定了个规矩：Resources里只放启动资源，其他一律走AssetBundle。

2.7 总结：Resources的正确打开方式

说了这么多，其实就几点：

小项目：随便用，怎么快怎么来
中大型项目：严格控制数量，只放核心启动资源
任何项目：记住LoadAsync()比Load()更友好，别在主线程里搞大资源
永远记住：Resources不是银弹，它只是你工具箱里的一把螺丝刀

嗯，下一章咱们聊聊AssetBundle——那才是大项目资源管理的重头戏。