共计 979 个字符,预计需要花费 3 分钟才能阅读完成。
文章次要介绍了红点零碎的特点,如何基于前缀树这一数据结构实现红点零碎,提出了相干实现中存在的两个性能问题,以及如何去解决这两个问题,并在最初基于 UnityEditor 的 TreeView 开发了树视图窗口,不便使用者在开发阶段的 Debug 需要。
红点零碎是在大部分游戏中都能看到的常见需要。
其作用在于,在玩家达成某种条件时(如新取得某个配备、道具数量达到某个需要),在相干的 UI 上亮起红点来提醒玩家进行相干操作。
红点零碎的一个鲜明特征即是它的“层层套娃”性,子界面亮起红点时其父界面也须要同时被亮起红点,始终点亮到主界面为止。
以下图为例,当某个特定的主线章节亮起红点时,
其父界面的主线章节按钮和出击页签也须要被亮起红点。
最初主界面上的出击按钮也会亮起红点来最终达到提醒玩家的目标。
如此层层嵌套下来,如果不对父子红点进行对立的触发治理,而是让负责各个模块的程序员各自治理,必将导致各个模块的红点触发逻辑难以保护且性能堪忧的后果。
而针对红点零碎这种非常强调父子关系的业务需要,应用“前缀树”进行治理将是十分好的抉择。
那么何为前缀树呢?
前缀树实质上是一种多叉树,树节点存储了字符,具备雷同前缀的字符串将具备雷同的父节点,在进行字符串保留和查找时具备较好的性能劣势。
通过将红点形象为门路,只须要稍加批改,让节点中存储对应的门路字符串和节点值,便能够不便地实现红点零碎。
以之前的图为例,笔者将每一层 UI 都依其父子关系设置为树中节点,最终只须要点亮门路为 MainAttack/Attack/Chapter/18 的节点,便能够同时亮起其所有父节点对应的 UI 的红点。
而当叶子节点的红点被暗藏时,其所有父节点也会自动检测所有子节点状态来决定是否暗藏本身的红点。
应用前缀树来实现红点零碎天然并非笔者的独创,但目前为止网上能找到的相干材料中往往存在两个性能痛点:
- 在解决门路时间接应用 split 办法进行字符串暴力切割,导致造成额定的内存调配。
- 在子节点状态扭转后须要也扭转父节点状态时不进行限度,多个子节点同时扭转将导致额定的无用刷新。
笔者在后续章节对红点零碎的具体实现中,便试图解决这两个痛点,并开发一个编辑器下的红点树可视化窗口,辅助使用者对红点零碎进行 Debug。
课程最初会提供蕴含残缺代码与测试用例的 Demo 工程不便读者学习。
返回课程:《Unity 中基于前缀树的高性能红点零碎实现》