最近的工作跟 UI 打交道比较多, 各种坑.
今天从 Prefab 的序列化功能来说说 System.Diagnostics.Conditional 的妙用.
我们做 UI 面对各种按钮, 组件的获取方式大致也就两种, 一种直接序列化到 Prefab 中, 另一种是在代码中去获取 :
序列化
tagObj = transform.Find("Child/Cube").gameObject; // 代码获取
各有各的好处 :
序列化很直接, 代码都不用写了, 并且随便你拖动 UI 到哪个节点, 都能正确引用. 不过问题也很明显, 过了几天连自己都找不着北了, 有过长期维护经验的人应该了解.
代码获取的方式从维护性来说, 直接就能让看的人知道那个组件在哪个节点上, 理解起来更简单. 可是如果节点路径发生变更, 就要出问题了, 这在频繁改动的 UI 设计上来说很要命. 特别是如果使用封装好的函数进行安全获取, 就更难发现问题了, 比如:
// 封装好的函数, 连错都不报 public static GameObject GetGameObject(Transform from, string find) { var trans = from.Find(find); if(trans) { return trans.gameObject; } return null; }
如果从效率的角度来看, 应该是序列化 Prefab 的效率要高于使用代码查找的效率的, 因为序列化对象是一个唯一ID, 而代码查找时 Transform 的子对象是在列表中的, 所以 Find 函数查找效率是跟 List 一样的 :
这里用 tagObj 引用了自己, 看到序列化对象的 ID 就是指向上面的 m_GameObject 的, 应该就是个内部 GUID 了. 从效率上看略胜一筹, 因为我在之前的项目碰到过有几千个 Child 的节点, 然后通过数据库得到的几千个数据对节点下面的对象进行查找, 那效率简直酸爽, 有这种需求的一定要先厉遍 Transform 把所有节点都放到 Dictionary 里引用啊, 血的教训...
第二点, 存储大小 :
如果序列化到 Prefab 里面, 它使用了 ID 作为引用, 增加的存储大小基本是个定值, 并且打包之后还能进行压缩等, 实际占用空间非常小, 而且作为资源它可以热更.
代码如果写在 C# 中, Find("XXX/ooo") 里面的字符会被放到静态域中, 这就很要命了, 因为到项目后期不仅由于过多的代码, 更多的字符串导致程序包过大, 我们真的碰到过超过 IOS 50多M限制的单个 DLL 问题...当然如果写在 Lua 中的话就跟资源一样了, 你能编译成二进制, 你能压缩, 万能的 Lua. 不过按照一般情况, "XXX/ooo" 字符一般都会比 ID 更长特别是 UI 层级很深的情况, 有中文的时候就更糟了.
假设我们有了 Lua, 你问问开发人员他们愿意写一大堆 Find 代码, 还是简单拖一拖了事? 因为 Lua 在使用上跟 C# 没有什么不同, 如果使用了序列化谁都懒得再去写代码了... 这真的是少有的 Unity 官方功能比民间方法更牛的特例.
这样看来序列化真是又简单又高效, 还省空间, 主要问题还是在后期维护上, 比如我们的变量叫 tagObj, 制作的人可能引用的对象名称是 Cube, 名称上完全没有关联性, 在一些不可预知的情况下如果引用丢失了, 连制作者都不知道原来引用的是哪个对象的情况多的是. 我们能把两种模式结合起来的话就好了, 比如在组件上面加个注释 :
恩, 不错, 还有更好的 :
System.Diagnostics.Conditional 可以根据编译条件决定是否编译, 它在非编辑器下就跟注释一样是不会加进去的, 而在编辑器下你是可以通过 GetCustomAttributes 获取的, 那么它的用处就大了 :
1. 在编辑器下检查序列化对象是不是丢了, 丢了的话找 Attribute 然后通过 loadPath 去自动获取.
2. 在编辑器下检查序列化对象跟 loadPath 的对象是不是一致, 检查数据正确性.
这些看似简单的功能, 在发布版本之前可能救不少人的命呢, 避免了每次抓人去祭天. 通过这个应用方法添加了一些信息, 并能提供上述功能支持.
测试一下 :
-------- 编辑器 --------
-------- 发布后 --------