AssetRipper 数据存储底层拆解单例、列表与可插拔序列化一次讲透【免费下载链接】AssetRipperGUI application to analyze game files项目地址: https://gitcode.com/GitHub_Trending/as/AssetRipperAssetRipper 是一款分析 Unity 游戏文件、提取资产与脚本的工具。围绕它的 AssetRipper 数据存储层也就是整套 AssetRipper 数据库架构的核心可以按一次完整读写流程拆开看单例、列表两类容器如何存取资产元数据序列化又如何插拔替换。在一个 Unity 资产提取工具里导入器要读导入设置处理器要记导出根路径GUI 要回显每个选项提取结束还得把资产依赖清单写回磁盘。这些状态一旦散落在不同对象与临时变量里同一个游戏两次运行就会跑出两套结果。插件作者更麻烦想加一个自定义配置根本找不到该往哪里挂。AssetRipper 的解法是把全部可变状态收敛进一个薄层数据分单例与列表两种形态统一挂在一对泛型字典容器下序列化交给可替换的抽象类处理。整套 Unity 资产提取配置管理都发生在这层里源码集中在Source/AssetRipper.Configuration/。消费方 CoreConfiguration.cs 对外只暴露属性化入口导入设置与导出根路径都从这里进出。把单例配置挂进泛型字典先不看实现只看形状。所有可存取的数据项都继承自 DataEntry所有可存取数据项的基类它只要求一件事能被 Clear。单值形态由 DataInstance单值数据项承载多值形态由 DataSet多值数据项集合承载SingletonDataStorage 与 ListDataStorage 则分别把这两类条目装进 DataStorage 泛型字典容器后者内部就是一个 Dictionarystring, TClear 时会级联遍历每个条目并调用各自的清理方法。图 1AssetRipper 数据库架构中的数据存储层类结构public class DataStorageT where T : DataEntry { protected readonly Dictionarystring, T data []; public IEnumerablestring Keys data.Keys; public T? this[string key] { get data.TryGetValue(key, out T? value) ? value : default; } }容器本身不关心值怎么读出来序列化被整体推到了条目内部。这种泛型数据容器设计的代价是每次取值多一层 as 转型收益是容器逻辑与数据形态彻底解耦新增一种数据形态容器一行不用改。下表两种容器的差别只在装单值还是装集合。容器条目基类典型用途序列化载体SingletonDataStorageDataInstance单值ImportSettings、导出根路径JsonDataInstanceListDataStorageDataSet多值资产依赖列表、文件清单StringDataSet / ParsableDataSet走通一次完整读写从加载提取配置到写回资产依赖以导入器首次启动为例这一步发生在任何游戏文件被读取之前。CoreConfiguration导入流程的核心配置对象构造函数先把默认导入设置注入单例容器用的是 JsonDataInstance 按 JSON 文本存取的单例条目值来自源生成的序列化上下文public CoreConfiguration() { ResetToDefaultValues(); SingletonData.Add(nameof(ImportSettings), new JsonDataInstanceImportSettings(ImportSettingsContext.Default.ImportSettings)); }写入走 SetStoredValue用户改了网格导出格式GUI 侧直接修改条目的 Value对象原地更新不重新装箱。读取分温和与强硬两档温和档 TryGetStoredValue 在键缺失或类型不匹配时返回 false 并给出 default让调用方自己决定降级路径强硬档 GetStoredValue 遇到同样情况直接抛 KeyNotFoundException。这是有意的区分——默认值可以静默回退但配置丢了必须炸出来。public bool TryGetStoredValueT(string key, [MaybeNullWhen(false)] out T value) { if (data.TryGetValue(key, out DataInstance? storedValue) storedValue is DataInstanceT instance) { value instance.Value; return true; } ... }提取完成后的写回是列表通道的活ListDataStorage 的 Add 重载会按元素类型自动选 StringDataSet 或 ParsableDataSet 把依赖清单原样收好。反查某个键时GUI 侧的 GetOrAdd 扩展先查后建省掉调用方手写两次 TryGetValue 的样板。要落盘时条目的 Text 属性才把值变成字符串——也就是下一节要讲的插拔点。序列化层怎么换资产元数据序列化的插拔点真正让换格式成立的是条目与文本之间的双向门。DataInstance 内部持有一个 DataSerializer 负责值与字符串互转的抽象类Text 的读写全部委托给它Clear 则由它重建一个空值。序列化器在条目构造时注入之后终身不换public T Value { get; set; } public sealed override string Text { get serializer.Serialize(Value); set Value serializer.Deserialize(value); }于是字符串、IParsable 可从字符串解析自身的类型标记接口与 JSON 三种形态只是换了序列化器条目结构、容器与调用方全部不动。值以对象形态驻留内存序列化与反序列化只在 Text 被实际触碰时才发生。这正是延迟反序列化的落点一次流程里大多数条目根本不需要落盘省下的都是白做的字符串分配。评审视角的三个取舍索引器返回 default 而不是抛异常乍看像偷懒。它把键不存在与类型不对折叠进同一条温和路径把必须存在的语义留给 GetValue 一族。调用方按场景选档容器不必维护两套异常逻辑。TryGetStoredValue 里的模式匹配storedValue is DataInstance instance替代了显式类型检查加强转转型失败自然落入 false 分支。这是泛型约束做不到的部分——where 子句只能挡住一层具体条目类型还得靠 is 表达式兜底。可读性与安全性一起兑现。GetOrAdd 放在 GUI 侧而不是容器里划清了边界容器保持纯存储缺省则建这种编辑语义属于使用方。代价是插件作者需要自己引入这个扩展。换来的是核心层零业务假设容器可以原样搬到别的宿主。对二次开发者这套机制的门槛低得几乎不像数据库持久化自己的状态继承 DataEntry 一族、选一个序列化器、挂进 CoreConfiguration 即可不必碰容器与流程代码。想换存储格式替换 DataSerializer 就够读写路径一行不改。AssetRipper 的提取主流程则继续把配置当黑盒使用谁都不需要知道里面存的是 JSON 还是普通字符串。【免费下载链接】AssetRipperGUI application to analyze game files项目地址: https://gitcode.com/GitHub_Trending/as/AssetRipper创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 AssetRipper 数据存储底层拆解：单例、列表与可插拔序列化一次讲透
AssetRipper 数据存储底层拆解单例、列表与可插拔序列化一次讲透【免费下载链接】AssetRipperGUI application to analyze game files项目地址: https://gitcode.com/GitHub_Trending/as/AssetRipperAssetRipper 是一款分析 Unity 游戏文件、提取资产与脚本的工具。围绕它的 AssetRipper 数据存储层也就是整套 AssetRipper 数据库架构的核心可以按一次完整读写流程拆开看单例、列表两类容器如何存取资产元数据序列化又如何插拔替换。在一个 Unity 资产提取工具里导入器要读导入设置处理器要记导出根路径GUI 要回显每个选项提取结束还得把资产依赖清单写回磁盘。这些状态一旦散落在不同对象与临时变量里同一个游戏两次运行就会跑出两套结果。插件作者更麻烦想加一个自定义配置根本找不到该往哪里挂。AssetRipper 的解法是把全部可变状态收敛进一个薄层数据分单例与列表两种形态统一挂在一对泛型字典容器下序列化交给可替换的抽象类处理。整套 Unity 资产提取配置管理都发生在这层里源码集中在Source/AssetRipper.Configuration/。消费方 CoreConfiguration.cs 对外只暴露属性化入口导入设置与导出根路径都从这里进出。把单例配置挂进泛型字典先不看实现只看形状。所有可存取的数据项都继承自 DataEntry所有可存取数据项的基类它只要求一件事能被 Clear。单值形态由 DataInstance单值数据项承载多值形态由 DataSet多值数据项集合承载SingletonDataStorage 与 ListDataStorage 则分别把这两类条目装进 DataStorage 泛型字典容器后者内部就是一个 Dictionarystring, TClear 时会级联遍历每个条目并调用各自的清理方法。图 1AssetRipper 数据库架构中的数据存储层类结构public class DataStorageT where T : DataEntry { protected readonly Dictionarystring, T data []; public IEnumerablestring Keys data.Keys; public T? this[string key] { get data.TryGetValue(key, out T? value) ? value : default; } }容器本身不关心值怎么读出来序列化被整体推到了条目内部。这种泛型数据容器设计的代价是每次取值多一层 as 转型收益是容器逻辑与数据形态彻底解耦新增一种数据形态容器一行不用改。下表两种容器的差别只在装单值还是装集合。容器条目基类典型用途序列化载体SingletonDataStorageDataInstance单值ImportSettings、导出根路径JsonDataInstanceListDataStorageDataSet多值资产依赖列表、文件清单StringDataSet / ParsableDataSet走通一次完整读写从加载提取配置到写回资产依赖以导入器首次启动为例这一步发生在任何游戏文件被读取之前。CoreConfiguration导入流程的核心配置对象构造函数先把默认导入设置注入单例容器用的是 JsonDataInstance 按 JSON 文本存取的单例条目值来自源生成的序列化上下文public CoreConfiguration() { ResetToDefaultValues(); SingletonData.Add(nameof(ImportSettings), new JsonDataInstanceImportSettings(ImportSettingsContext.Default.ImportSettings)); }写入走 SetStoredValue用户改了网格导出格式GUI 侧直接修改条目的 Value对象原地更新不重新装箱。读取分温和与强硬两档温和档 TryGetStoredValue 在键缺失或类型不匹配时返回 false 并给出 default让调用方自己决定降级路径强硬档 GetStoredValue 遇到同样情况直接抛 KeyNotFoundException。这是有意的区分——默认值可以静默回退但配置丢了必须炸出来。public bool TryGetStoredValueT(string key, [MaybeNullWhen(false)] out T value) { if (data.TryGetValue(key, out DataInstance? storedValue) storedValue is DataInstanceT instance) { value instance.Value; return true; } ... }提取完成后的写回是列表通道的活ListDataStorage 的 Add 重载会按元素类型自动选 StringDataSet 或 ParsableDataSet 把依赖清单原样收好。反查某个键时GUI 侧的 GetOrAdd 扩展先查后建省掉调用方手写两次 TryGetValue 的样板。要落盘时条目的 Text 属性才把值变成字符串——也就是下一节要讲的插拔点。序列化层怎么换资产元数据序列化的插拔点真正让换格式成立的是条目与文本之间的双向门。DataInstance 内部持有一个 DataSerializer 负责值与字符串互转的抽象类Text 的读写全部委托给它Clear 则由它重建一个空值。序列化器在条目构造时注入之后终身不换public T Value { get; set; } public sealed override string Text { get serializer.Serialize(Value); set Value serializer.Deserialize(value); }于是字符串、IParsable 可从字符串解析自身的类型标记接口与 JSON 三种形态只是换了序列化器条目结构、容器与调用方全部不动。值以对象形态驻留内存序列化与反序列化只在 Text 被实际触碰时才发生。这正是延迟反序列化的落点一次流程里大多数条目根本不需要落盘省下的都是白做的字符串分配。评审视角的三个取舍索引器返回 default 而不是抛异常乍看像偷懒。它把键不存在与类型不对折叠进同一条温和路径把必须存在的语义留给 GetValue 一族。调用方按场景选档容器不必维护两套异常逻辑。TryGetStoredValue 里的模式匹配storedValue is DataInstance instance替代了显式类型检查加强转转型失败自然落入 false 分支。这是泛型约束做不到的部分——where 子句只能挡住一层具体条目类型还得靠 is 表达式兜底。可读性与安全性一起兑现。GetOrAdd 放在 GUI 侧而不是容器里划清了边界容器保持纯存储缺省则建这种编辑语义属于使用方。代价是插件作者需要自己引入这个扩展。换来的是核心层零业务假设容器可以原样搬到别的宿主。对二次开发者这套机制的门槛低得几乎不像数据库持久化自己的状态继承 DataEntry 一族、选一个序列化器、挂进 CoreConfiguration 即可不必碰容器与流程代码。想换存储格式替换 DataSerializer 就够读写路径一行不改。AssetRipper 的提取主流程则继续把配置当黑盒使用谁都不需要知道里面存的是 JSON 还是普通字符串。【免费下载链接】AssetRipperGUI application to analyze game files项目地址: https://gitcode.com/GitHub_Trending/as/AssetRipper创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考