三套容器管好一套配置AssetRipper 数据存储架构完整指南Unity 资产提取工具【免费下载链接】AssetRipperGUI application to analyze game files项目地址: https://gitcode.com/GitHub_Trending/as/AssetRipperAssetRipper 是一款用来从 Unity 游戏文件中提取资源纹理、模型、脚本、音频的工具它的每次导出行为都由一组配置驱动网格导出成什么格式、脚本反编译到什么级别、音频用哪种压缩。有意思的是作者并没有引入配置库、SQLite 或一套 JSON 文件约定来存这些数据和资产元信息而是在 AssetRipper.Configuration 这个目录里手搓了一小块数据存储架构——整个模块加起来不过几个文件。为什么不用Dictionarystring, object了事因为配置里既有一个 key 一个值也有一个 key 一串值还要支持 GUI 页面按纯文本编辑、支持随时序列化落盘纯字典方案会让类型转换散落得到处都是。下面直接顺着源码把这套小架构走一遍。一图看懂分层关系先建立整体印象先给结论这套存储是一个字典基类 两种存储门面 两类值容器 可插拔序列化器的结构层次关系如下。读这张图只需要记住一件事基类只负责按 key 找门值的结构和序列化方式全部由泛型参数在编译期钉死。逐个拆三种容器基类、单例、列表 这三个类都在 DataStorage.cs、SingletonDataStorage.cs、ListDataStorage.cs 里一个比一个窄。DataStorage 基类一个带类型安检的键值档案柜定性话它就是Dictionarystring, T的薄壳价值全在读取侧的包装。写入就是Add(key, value)读取提供两种姿势——indexer 取不到给defaultGetValue取不到直接抛KeyNotFoundException属于宽容/严格二选一。真正的设计点在泛型下钻TryGetValueTValue要求TValue : T取出后做一次as转型类型对不上就安静返回 false而不是让调用方自己 cast 出InvalidCastException// 基类核心字典 下钻转型。as 转型失败返回 false把类型判断收进基类 // 调用方拿到的 TValue 要么正确、要么知道失败了不需要再写 is 检查 public bool TryGetValueTValue(string key, out TValue? value) where TValue : T { if (data.TryGetValue(key, out T? storedValue)) { value storedValue as TValue; // 转型在门上做一次后面各处白拿 return value is not null; } value default; return false; }另一个值得注意的行为是Clear()它不是把字典清空而是逐个调用每个 entry 的Clear()让每个值回到序列化器定义的出厂默认。这让重置配置和删光数据成为两个明确不同的操作。SingletonDataStorage一个 key 只装一个强类型值定性话它是单值配置的门面单例指的是值的个数不是这个类本身。它把基类的T锁定为抽象的DataInstance对外再包一层TryGetStoredValueT / GetStoredValueT / SetStoredValueT。套路都是同一个先按 key 拿到实例再判断它是不是恰好装着DataInstanceT是就解包出强类型Value不是就返回 false 或抛异常。业务代码因此能写出settings.SingletonData.GetStoredValueImportSettings(ImportSettings)这种零转换的调用。ListDataStorage一个 key 装一串值定性话它管的是列表形态的数据连添加入口都替你收窄成两种。Add 方法 只有两个重载Liststring落成StringDataSetListT where T : IParsableT, new()落成ParsableDataSetT。想塞一个任意对象进列表编译器不让你。DataSetT内部就是一个ListT加一个序列化器而抽象基类DataSet额外送了一个Strings视图——任何 DataSet 都能通过隐式转换当IReadOnlyListstring用每个元素现取现序列化。这层字符串视图不是装饰GUI 的配置页就是靠它把列表渲染成可编辑文本框的后面旅程部分会看到。真实用法可以参考 CoreConfiguration 里 DEBUG 分支塞进去的斐波那契数列ListData.Add(Fibonacci, [1, 1, 2, 3, 5, 8, ...])int 天然可解析直接入列。三种序列化怎么选String / Parsable / JSON 对比表序列化器是注入进值容器的DataInstanceT/DataSetT的构造函数都要传一个DataSerializerT接口只有三个方法Serialize、Deserialize、CreateNew。三个实现的选择逻辑一目了然维度StringDataSerializerParsableDataSerializerTJsonDataSerializerT对 T 的约束固定stringT : IParsableT, new()T : new()序列化方式原样返回value.ToString()System.Text.Json JsonTypeInfoT源生成无反射反序列化失败时不存在失败恒等转换TryParse失败 → 静默返回new()空串/抛异常 → 静默返回new()定位纯文本设置项能用一个字符串表达的值int、路径、版本号结构化配置对象ImportSettings、ExportSettings注意两个实现里都留着注释// Forgiving parsing坏数据不抛异常直接回退到空实例。这是刻意的取舍——配置被改坏时宁可回到默认值也不能让一个导出工具在加载自己的设置时崩掉。CreateNew()统一承担了默认值工厂的角色DataInstance的Clear()就是靠它回到出厂状态的。一条配置的完整旅程从构造到 GUI 再到读回抽象讲完了跟一条真实配置ImportSettings走一圈。它的门面在 CoreConfiguration.cs// 业务代码看到的只是强类型属性存储细节全部藏在两个转发调用里 public ImportSettings ImportSettings { get SingletonData.GetStoredValueImportSettings(nameof(ImportSettings)); set SingletonData.SetStoredValue(nameof(ImportSettings), value); }第 1 步写入初始化。构造函数里把它包进 JSON 容器挂上存储SingletonData.Add(nameof(ImportSettings), new JsonDataInstanceImportSettings(ImportSettingsContext.Default.ImportSettings))。此刻内存里存的是对象本体字符串形态还不存在。第 2 步GUI 编辑序列化发生点。Web GUI 的配置页不碰对象只碰字符串GameFileLoader.Settings.SingletonData.GetOrAdd(key).Text content。DataInstance.Text的 setter 在此处调用serializer.Deserialize把用户输入的文本变成Value。也就是说序列化不是保存时才发生而是 UI 与存储之间的翻译层随取随用。第 3 步业务读取。导入流程里直接settings.ImportSettings走GetStoredValueImportSettings解包出强类型对象全程没有一次手工 cast。导出侧的 FullConfiguration 用完全相同的手法管理ProcessingSettings和ExportSettings模式完全一致。第 4 步重置。ResetToDefaultValues()调用SingletonData.Clear()和ListData.Clear()基类逐个触发 entry 的Clear()每个DataInstance的Value被serializer.CreateNew()打回默认——没有文件被删没有状态残留一切回到第 1 步的初始态。这条旅程说明这套架构真正解决的问题同一份配置同时服务三种读者业务代码要强类型、GUI 要纯文本、序列化器要字符串而分层结构让每种读者只接触自己那一层的抽象。工程细节与取舍为什么这些设计值回票价⚡ 把散落在源码里的几个点收拢成判断延迟序列化DataInstance内存里放Value对象Text是派生属性。不读写文本时序列化一次都不会发生配置页反复刷新也不会重复生成 JSON。双层泛型的类型安全存储层DataStorageT管这个柜子的格子装什么类型实例层DataInstanceT管这一格里的具体值是什么类型。类型错误在as转型处就被false接住而不是运行到深处才炸。内存细节DataSetT.AddStrings批量添加前检查来源是否IReadOnlyCollection能数出个数就先EnsureCapacity避免列表反复扩容——这是整条链路里唯一一处数着放的优化。宽松读取、严格写入三个序列化器读取失败全部静默回退CreateNew()写入失败key 不存在则抛KeyNotFoundException。坏配置降级为默认值是工具类程序比崩溃更体面的姿态。线程安全是主动放弃的整个模块没有任何锁。这不是疏漏——GUI 是单线程事件驱动的读写模型加锁只会带来死锁风险而换不来实际收益。如果你要把这套设计搬进多线程环境锁要加在DataStorage的字典访问上且要意识到Clear()的级联过程也需要纳入临界区。体量即答案整个 Configuration 模块 没有持久层、没有锁、没有依赖注入容器全部代码加起来比一个中型 Service 还薄。它解决的是进程内配置的分层管理没有试图解决数据库问题——边界划得清才是它好读的原因。这套设计能搬回你项目的哪三处 如果你也在纠结配置存哪儿有三件事可以直接抄值容器与存储分离。当你的配置同时存在单值和列表、且各自要支持多种序列化格式时字典基类 强类型值容器比Dictionarystring, object省掉的是每一处取值时的类型断言。判定标准很简单只要你发现自己写第二遍is XxxSettings ? (XxxSettings)obj : null就是该分层的信号。用 Text 字符串层隔离 UI 和业务。GUI 层只操作字符串视图本文里的Strings/Text业务层只操作强类型序列化器夹在中间做翻译。这个夹层让你的界面、CLI、文件导入三条入口可以共用同一份存储互不污染。把CreateNew()当作默认值工厂。重置不再是一坨手写赋值的复制粘贴而是每个序列化器声明一次、所有容器级联生效。最后提醒一句边界这套结构适合进程内的配置与元信息管理不适合当持久层用——落盘、并发、大对象这些需求它一概不管也正因为不管这些它才一直只值这几个文件的大小。【免费下载链接】AssetRipperGUI application to analyze game files项目地址: https://gitcode.com/GitHub_Trending/as/AssetRipper创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考