项目UI框架中存在的问题分析

目前我们游戏中使用的UI框架是采用树形结构记录父子节点之间的跳转关系，然后每个节点上提前设置好上下级界面的关闭打开方式。这种树形结构最大的好处是不管我们跳转了多少层都可以一层层返回来(理论上上这样，但是我们实际使用中还是要尽量规避一下跳转层级太深，这个也是我们目前的游戏的一个痛点)，应对诸如MMORPG这种有大量UI跳转的游戏也不在话下。

当然，这种树形结构也有很多缺点，比如无法支持环形跳转，也就是说A>B>C>A这种结构，我个人觉得这种环形跳转本质上是设计问题，需要避免掉。由于我们每个界面都对应一个树形结构的节点，所以需要维护一个复杂的树形结构，每次新增跟删除都会非常麻烦，特别是在项目后期，界面很多，层级很深，相同的界面节点超级多，简直是个灾难。

最近刚好项目刚上线，抽时间对这套UI框架存在的问题进行了一下总结：

1、某些异常情况下导致一个界面都没有，需要加强保护；
2、每个弹出的界面都要有对应的节点，维护重复的界面节点比较麻烦，操作的时候非常容易遗漏；
3、"显示的时候隐藏所有UI"功能存在隐患，同时触发这个选项会相互干扰；
4、现在显示和隐藏界面的时候是实时递归查找对应节点的，需要针对父节点和孩子节点进行缓存，提高效率；
5、之前的查找方案为了尽可能的找到对应的节点，会递归遍历孩子节点和整个树，有时候会查找到了错误的节点，效率比较低，而且也不合理，容易把问题掩盖；
6、显示界面的时候不支持可变个数的参数；
7、界面预设上需要手动填写界面图集，有点不灵活；
8、UI的遮罩表现虽然是全局的，但是每次开关界面都会各自执行，因为我们界面开关的时候会触发多个其他界面的开关，导致这个遮罩的算法逻辑重复执行，而且可能相互干扰，得到错误的结果；
9、“是否需要货币栏”跟“货币栏类型”可以合并成一个选项，统一用“货币栏类型”，不设置则不需要；

优化方向：

1、每个界面节点下存储自己的父节点和孩子节点，提高查找效率，在首次访问父节点或者孩子节点的时候动态初始化，避免所有节点同时初始化造成性能浪费；
2、"显示的时候隐藏所有UI"功能存在隐患，将发起临时隐藏的界面节点记录下来，界面恢复的时候，只有记录清空才能还原临时隐藏状态；
3、节点上新增“继承孩子节点”功能，可以选定一个已存在的节点，用来继承它的所有孩子节点，避免维护重复的节点关系。运行时根据引用动态生成真实的孩子节点（之前尝试过把引用的节点临时挂靠到当前节点下，实践的时候发现父节点频繁变动有坑隐患，关系一旦错乱会造成不可逆转的错误，最后还是采用了更加保险的方案）。
4、删除"关闭的时候关闭所有子界面"功能，默认直接关闭子界面。
5、删除"关闭的时候显示上级界面"功能，默认打开上级界面。
6、界面遮罩的算法逻辑可以考虑放到所有界面开关后统一处理，新增一个用于刷新遮罩的事件，用于特殊情况下的额外刷新，比如临时关闭的一些UI，不走界面开关事件，但是遮罩需要重新刷新；
7、节点查找方案优化：
     a、第一优先级从直接子节点进行查找；
     b、第二优先级从直接父节点递归往上查找；
　  c、第三优先级从兄弟节点(父节点的子节点)进行查找；
     d、第四优先级从默认的节点开始查找，这个默认的节点需要提前自定义，没有的话就不查找；
     e、没有找到的话直接报异常，这样既避免了查找到了错误的节点带来bug，也规避了大量的递归查找带来的性能损耗；

 

标签：遮罩,界面,框架,项目,查找,UI,跳转,节点
来源： https://www.cnblogs.com/ppne/p/16224263.html