尧图网站建设 
为什么用 128 位 LongGuid 而非字符串名称完整拆解 ScriptableObjectCollection 的资产身份设计【免费下载链接】ScriptableObjectCollectionA library to help improve the usability of Unity3D Scriptable Objects by grouping them into a collection and providing easy access through code or user-friendly inspectors!项目地址: https://gitcode.com/gh_mirrors/sc/ScriptableObjectCollectionScriptableObjectCollection 是一款面向 Unity3D 的开源工具库它把 ScriptableObject 分组到集合Collection中并提供代码静态访问、检查器下拉选择等能力。在它的底层设计中有一个关键决策非常值得拆解每个集合与集合条目Item的身份标识不是大家熟悉的字符串名称而是一个 128 位的LongGuid值类型。这篇文章带你从新手视角理解为什么字符串名称撑不起资产身份128 位 LongGuid 又是如何兼顾唯一性、性能与序列化体积的。一、字符串名称为什么撑不起资产身份很多项目最初都用按名字找资产的思路Resources.Load(Consumables/PackOfCoins)或遍历列表比对item.name。但规模一上来字符串作为身份标识就暴露出四个致命问题问题场景后果 重命名即断裂策划把PackOfCoins改成CoinPack所有按名字保存的引用瞬间失效 命名冲突两个集合里都有BagOfCoins名字无法区分归属匹配到错误条目 本地化/改名项目做多语言或批量改名身份随内容漂移数据与引用全面失配 比对成本高每次查找都要做字符串比较GC 分配多、速度慢还涉及大小写与排序规则ScriptableObjectCollection的思路是名字只是显示标签身份必须是不可变的唯一标识符。这正是 128 位LongGuid登场的地方。二、LongGuid一张 128 位的资产身份证结构定义两个 long 拼出 128 位LongGuid的完整定义见 LongGuid.cs。它的核心结构非常简洁见 LongGuid.cs#L9-L12用**两个long各 64 位**存储一个 128 位 GUID合计正好 128 位它是struct值类型而非字符串可直接比较、无需装箱通过LongGuid.NewGuid()从System.Guid生成天然具备随机唯一性重写了/!运算符与GetHashCode()用起来和普通值一样自然。为什么选 128 位而不是 64 位128 位的意义在于碰撞概率小到可以忽略。按生日问题估算64 位 GUID生成约 50 亿个条目后出现一次碰撞的概率才超过 50%128 位 GUID需要生成约2⁶⁴1.8×10¹⁹个条目才有 50% 碰撞率——相当于全地球每人每秒生成几千个资产也要撞上好几个宇宙纪元。同时128 位也与 Unity 自身的.meta文件 GUID 体系保持同一量级概念上对新手非常友好每个资产一张 128 位身份证一辈子不变。三、值类型带来的性能红利 与字符串方案相比LongGuid的性能优势是结构性的零字符串分配比较两个long只需两次整数比较Equals实现见 LongGuid.cs#L54-L57没有哈希字符串、没有 GC 压力哈希快速定位GetHashCode用HashCode.Combine(value1, value2)一次算出可直接作为Dictionary的键查找走索引而非遍历集合内部维护LongGuid → 条目的字典缓存TryGetItemByGUID可以做到近乎 O(1) 查找实现见 ScriptableObjectCollection.cs#L508-L542位运算友好项目甚至基于条目索引提供了 64 位位掩码快速路径CollectionItemMask64集合间的条目集合比较可以退化为纯位运算零分配。而ScriptableObjectCollectionItem的相等性判断也完全建立在 GUID 上见 ScriptableObjectCollectionItem.cs#L88-L103——两个条目是否同一个由身份证决定与名字无关。四、序列化一条跨集合引用只需 4 个 long这是 LongGuid 设计最值钱的地方之一。当你在场景或存档中引用某个集合条目时CollectionItemIndirectReference定义见 CollectionItemIndirectReference.cs只序列化 4 个 long条目自身的LongGuid2 个 long所属集合的LongGuid2 个 long。见 CollectionItemIndirectReference.cs#L10-L21。运行时的解析路径是纯 GUID 查找先按集合 GUID 找到集合再按条目 GUID 找到条目TryResolveReference见 CollectionItemIndirectReference.cs#L106-L119。值得注意的细节源码里确实保留了itemLastKnownName/collectionLastKnownName两个名字字段但它们被#if UNITY_EDITOR包裹——名字只用于编辑器界面友好展示与错误定位绝不参与运行时解析这一决策可参考 CHANGELOG 2.6.0 的说明见 CHANGELOG.MD。这样既保留了调试便利性又彻底避免了靠名字恢复引用的脆弱路径。生成的间接引用文件示例可看 CarIDIndirectReference.g.cs它只是继承CollectionItemIndirectReferenceT的空壳真正的身份逻辑全部由 GUID 承载。五、GUID 的自动管理唯一性由系统兜底 ️你可能担心GUID 会不会重复会不会忘了生成ScriptableObjectCollection的答案是全自动生成时自动创建通过检查器 Add New 添加条目时会自动调用GenerateNewGUID()见 ScriptableObjectCollection.cs#L159-L160导入时自动校验编辑器端的资产后处理器SOCItemGuidProcessor在每次资产导入时检查每个条目的 GUID 是否有效且唯一发现无效立即重新生成发现真实重复则换发新证核心逻辑EnsureValidAndUniqueGuid见 SOCItemGuidProcessor.cs#L143-L166重命名/移动不误伤重复检测以 Unity 的.meta资产 GUID 为键而它天生能存活重命名与移动——早期基于路径的检测会在重命名后误判为重复资产并毁掉条目 GUID该问题已在 2.7.0 修复见 CHANGELOG.MD。对新手来说这意味着你只需要正常操作检查器身份系统自己会保持健康项目级注册表CollectionsRegistry则负责按 GUID 维护集合 → 条目的全局索引。六、名字还有用吗有用但只作为便利层而非身份层。集合依然提供TryGetItemByName见 ScriptableObjectCollection.cs#L489-L506、按名字排序、检查器内按名字搜索等功能——你随时可以用名字找条目、改条目但跨引用、跨集合、跨版本持久化的身份契约全部由 LongGuid 承担。这就像身份证号和昵称的关系你可以改昵称但证件永远认身份证号。七、版本演进从字符串到 LongGuid 的取舍从 CHANGELOG.MD 能清晰看到这条设计路线的演进2.0.0旧版基于字符串的 GUID 系统被更轻量的LongGuid全面替换当时的破坏性变更2.5.0无效 GUID 不再被序列化LongGuid 改用 Base64 字符串在检查器中展示2.5.1新增SOCItemGuidProcessor统一接管 GUID 的合法性与唯一性校验2.6.0移除GUID 解析失败时按名字回退查找的运行时兜底GUID 成为唯一运行时查找路径2.7.0重复检测改按.meta资产 GUID 建键修复重命名导致的 GUID 误重置。可以看到一个明确的工程取向逐步砍掉一切用名字猜身份的路径把身份收敛到单一、不可变、可验证的 128 位标识上。总结三个要点带走名字会漂移身份不能漂移字符串名称受重命名、冲突、本地化影响不适合作为持久化身份LongGuid用 128 位随机值把碰撞概率压到工程上可忽略的水平值类型即性能两个long的比较、哈希、字典查找都无字符串分配配合 GUID 索引缓存让条目查找接近 O(1)序列化极小、系统兜底一条跨集合引用只需 4 个 longGUID 的生成、校验、去重全部由检查器与资产后处理器自动完成使用者无需操心。理解这套资产身份证设计后你在使用 ScriptableObjectCollection 时就会明白放心改名、放心移动文件引用不会断——因为系统认的从来不是名字而是那张 128 位的 LongGuid。【免费下载链接】ScriptableObjectCollectionA library to help improve the usability of Unity3D Scriptable Objects by grouping them into a collection and providing easy access through code or user-friendly inspectors!项目地址: https://gitcode.com/gh_mirrors/sc/ScriptableObjectCollection创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 为什么用 128 位 LongGuid 而非字符串名称？完整拆解 ScriptableObjectCollection 的资产身份设计
为什么用 128 位 LongGuid 而非字符串名称完整拆解 ScriptableObjectCollection 的资产身份设计【免费下载链接】ScriptableObjectCollectionA library to help improve the usability of Unity3D Scriptable Objects by grouping them into a collection and providing easy access through code or user-friendly inspectors!项目地址: https://gitcode.com/gh_mirrors/sc/ScriptableObjectCollectionScriptableObjectCollection 是一款面向 Unity3D 的开源工具库它把 ScriptableObject 分组到集合Collection中并提供代码静态访问、检查器下拉选择等能力。在它的底层设计中有一个关键决策非常值得拆解每个集合与集合条目Item的身份标识不是大家熟悉的字符串名称而是一个 128 位的LongGuid值类型。这篇文章带你从新手视角理解为什么字符串名称撑不起资产身份128 位 LongGuid 又是如何兼顾唯一性、性能与序列化体积的。一、字符串名称为什么撑不起资产身份很多项目最初都用按名字找资产的思路Resources.Load(Consumables/PackOfCoins)或遍历列表比对item.name。但规模一上来字符串作为身份标识就暴露出四个致命问题问题场景后果 重命名即断裂策划把PackOfCoins改成CoinPack所有按名字保存的引用瞬间失效 命名冲突两个集合里都有BagOfCoins名字无法区分归属匹配到错误条目 本地化/改名项目做多语言或批量改名身份随内容漂移数据与引用全面失配 比对成本高每次查找都要做字符串比较GC 分配多、速度慢还涉及大小写与排序规则ScriptableObjectCollection的思路是名字只是显示标签身份必须是不可变的唯一标识符。这正是 128 位LongGuid登场的地方。二、LongGuid一张 128 位的资产身份证结构定义两个 long 拼出 128 位LongGuid的完整定义见 LongGuid.cs。它的核心结构非常简洁见 LongGuid.cs#L9-L12用**两个long各 64 位**存储一个 128 位 GUID合计正好 128 位它是struct值类型而非字符串可直接比较、无需装箱通过LongGuid.NewGuid()从System.Guid生成天然具备随机唯一性重写了/!运算符与GetHashCode()用起来和普通值一样自然。为什么选 128 位而不是 64 位128 位的意义在于碰撞概率小到可以忽略。按生日问题估算64 位 GUID生成约 50 亿个条目后出现一次碰撞的概率才超过 50%128 位 GUID需要生成约2⁶⁴1.8×10¹⁹个条目才有 50% 碰撞率——相当于全地球每人每秒生成几千个资产也要撞上好几个宇宙纪元。同时128 位也与 Unity 自身的.meta文件 GUID 体系保持同一量级概念上对新手非常友好每个资产一张 128 位身份证一辈子不变。三、值类型带来的性能红利 与字符串方案相比LongGuid的性能优势是结构性的零字符串分配比较两个long只需两次整数比较Equals实现见 LongGuid.cs#L54-L57没有哈希字符串、没有 GC 压力哈希快速定位GetHashCode用HashCode.Combine(value1, value2)一次算出可直接作为Dictionary的键查找走索引而非遍历集合内部维护LongGuid → 条目的字典缓存TryGetItemByGUID可以做到近乎 O(1) 查找实现见 ScriptableObjectCollection.cs#L508-L542位运算友好项目甚至基于条目索引提供了 64 位位掩码快速路径CollectionItemMask64集合间的条目集合比较可以退化为纯位运算零分配。而ScriptableObjectCollectionItem的相等性判断也完全建立在 GUID 上见 ScriptableObjectCollectionItem.cs#L88-L103——两个条目是否同一个由身份证决定与名字无关。四、序列化一条跨集合引用只需 4 个 long这是 LongGuid 设计最值钱的地方之一。当你在场景或存档中引用某个集合条目时CollectionItemIndirectReference定义见 CollectionItemIndirectReference.cs只序列化 4 个 long条目自身的LongGuid2 个 long所属集合的LongGuid2 个 long。见 CollectionItemIndirectReference.cs#L10-L21。运行时的解析路径是纯 GUID 查找先按集合 GUID 找到集合再按条目 GUID 找到条目TryResolveReference见 CollectionItemIndirectReference.cs#L106-L119。值得注意的细节源码里确实保留了itemLastKnownName/collectionLastKnownName两个名字字段但它们被#if UNITY_EDITOR包裹——名字只用于编辑器界面友好展示与错误定位绝不参与运行时解析这一决策可参考 CHANGELOG 2.6.0 的说明见 CHANGELOG.MD。这样既保留了调试便利性又彻底避免了靠名字恢复引用的脆弱路径。生成的间接引用文件示例可看 CarIDIndirectReference.g.cs它只是继承CollectionItemIndirectReferenceT的空壳真正的身份逻辑全部由 GUID 承载。五、GUID 的自动管理唯一性由系统兜底 ️你可能担心GUID 会不会重复会不会忘了生成ScriptableObjectCollection的答案是全自动生成时自动创建通过检查器 Add New 添加条目时会自动调用GenerateNewGUID()见 ScriptableObjectCollection.cs#L159-L160导入时自动校验编辑器端的资产后处理器SOCItemGuidProcessor在每次资产导入时检查每个条目的 GUID 是否有效且唯一发现无效立即重新生成发现真实重复则换发新证核心逻辑EnsureValidAndUniqueGuid见 SOCItemGuidProcessor.cs#L143-L166重命名/移动不误伤重复检测以 Unity 的.meta资产 GUID 为键而它天生能存活重命名与移动——早期基于路径的检测会在重命名后误判为重复资产并毁掉条目 GUID该问题已在 2.7.0 修复见 CHANGELOG.MD。对新手来说这意味着你只需要正常操作检查器身份系统自己会保持健康项目级注册表CollectionsRegistry则负责按 GUID 维护集合 → 条目的全局索引。六、名字还有用吗有用但只作为便利层而非身份层。集合依然提供TryGetItemByName见 ScriptableObjectCollection.cs#L489-L506、按名字排序、检查器内按名字搜索等功能——你随时可以用名字找条目、改条目但跨引用、跨集合、跨版本持久化的身份契约全部由 LongGuid 承担。这就像身份证号和昵称的关系你可以改昵称但证件永远认身份证号。七、版本演进从字符串到 LongGuid 的取舍从 CHANGELOG.MD 能清晰看到这条设计路线的演进2.0.0旧版基于字符串的 GUID 系统被更轻量的LongGuid全面替换当时的破坏性变更2.5.0无效 GUID 不再被序列化LongGuid 改用 Base64 字符串在检查器中展示2.5.1新增SOCItemGuidProcessor统一接管 GUID 的合法性与唯一性校验2.6.0移除GUID 解析失败时按名字回退查找的运行时兜底GUID 成为唯一运行时查找路径2.7.0重复检测改按.meta资产 GUID 建键修复重命名导致的 GUID 误重置。可以看到一个明确的工程取向逐步砍掉一切用名字猜身份的路径把身份收敛到单一、不可变、可验证的 128 位标识上。总结三个要点带走名字会漂移身份不能漂移字符串名称受重命名、冲突、本地化影响不适合作为持久化身份LongGuid用 128 位随机值把碰撞概率压到工程上可忽略的水平值类型即性能两个long的比较、哈希、字典查找都无字符串分配配合 GUID 索引缓存让条目查找接近 O(1)序列化极小、系统兜底一条跨集合引用只需 4 个 longGUID 的生成、校验、去重全部由检查器与资产后处理器自动完成使用者无需操心。理解这套资产身份证设计后你在使用 ScriptableObjectCollection 时就会明白放心改名、放心移动文件引用不会断——因为系统认的从来不是名字而是那张 128 位的 LongGuid。【免费下载链接】ScriptableObjectCollectionA library to help improve the usability of Unity3D Scriptable Objects by grouping them into a collection and providing easy access through code or user-friendly inspectors!项目地址: https://gitcode.com/gh_mirrors/sc/ScriptableObjectCollection创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考