Unity Addressable资源缓存路径自定义指南：告别C盘爆满烦恼
你是否也曾在深夜打包项目时，被Windows系统盘那刺眼的红色存储空间警告打断思路？对于Unity开发者而言，Addressable系统无疑是管理海量资源的利器，但它默认将下载的资产缓存到用户目录下的AppData文件夹，这个设计在长期开发或处理大型项目时，很容易让C盘“压力山大”。更棘手的是，当团队协作或需要在多台机器上同步开发环境时，这些散落在个人系统盘深处的缓存文件，就成了版本控制和环境一致性的隐形杀手。今天，我们就来彻底解决这个问题，将Addressable的资源缓存从系统盘解放出来，迁移到你的项目目录下，实现资源的集中管理和空间的自由掌控。
1. 理解Addressable缓存机制与痛点
在动手改造之前，我们有必要先厘清Addressable的缓存到底是如何工作的。这不仅仅是修改一个路径那么简单，理解其背后的逻辑能帮助我们在遇到问题时快速定位。
Addressable系统在运行时，会根据资源包的哈希值（Hash）在本地缓存中查找。如果找到，则直接加载；如果未找到，则从配置的路径（本地或远程）下载资源包，并将其存储到缓存目录中，以备后续使用。这个默认的缓存目录位于： C:\Users\[你的用户名]\AppData\LocalLow\Unity\[公司名]\[项目名]
为什么默认设计如此？ Unity的初衷是为了保证缓存数据的用户隔离性和应用沙盒安全性。每个用户的缓存互不干扰，也避免了应用随意向系统其他位置写入数据可能带来的安全风险。对于发布后的玩家客户端，这是一个合理的设定。
开发者的现实困境： 然而，在开发阶段，这套机制带来了几个显著问题：
- C盘空间危机：高清纹理、音频、动画等资源包动辄数百MB，多个项目或频繁的构建测试会迅速吞噬系统盘空间。
- 团队协作障碍：
AppData是用户专属目录，不会被纳入版本控制（如Git）。新成员拉取项目后，需要重新下载所有远程资源包，耗时漫长。 - 清理不便：缓存目录深藏在系统文件夹中，手动清理既麻烦又有误删系统文件的风险。
- 构建物大小不可控：在某些需要打包整个项目文件夹进行分发的场景下（如某些CI/CD流程），这些隐藏的缓存会无形中增大构建物体积。
理解了这些，我们自定义缓存路径的目标就非常明确了：将缓存目录移至项目文件夹内，使其可被版本控制（或至少易于管理），并释放系统盘空间。
2. 核心工具：CacheInitializationSettings 配置文件
Addressable系统提供了一个优雅的解决方案——CacheInitializationSettings。这是一个可脚本化对象（ScriptableObject），专门用于初始化并配置资源缓存的行为。
注意：
CacheInitializationSettings是AddressableAssetSettings初始化流程的一部分。它会在Addressable系统初始化时最早被加载并生效，确保后续的所有资源加载操作都使用你定义的缓存路径。
2.1 创建与基础配置
让我们一步步创建并配置它。
-
创建配置文件： 在Unity编辑器的Project窗口中，导航到你的
Assets/AddressableAssetsData文件夹。这是Addressable系统的核心配置目录。 右键点击该文件夹，选择 Create -> Addressables -> Initialization -> Cache Initialization Settings。 Unity会在当前目录下创建一个名为CacheInitializationSettings.asset的新文件。 -
关键参数详解： 选中新创建的
CacheInitializationSettings.asset文件，在Inspector窗口中你会看到如下可配置项：
86
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
