高性能自动化 ZMUIFrameWork 框架介绍 点我跳转
相信有不少人在开发游戏时会经常忽略一个问题,就是我们的日常工作中经常会掺杂着大量的,重复的,无效化工作。而这去做这些无效化工作是毫无意义的,完全是在浪费我们的时间,我们完全可以把这些时间用在学习上,提升一下自己的技术,百害而无一利。或者…也可以用来干点别的。当然如果你觉得可以用这些无效化工作用来摸鱼,额…那你可以当我没说,出门左拐。不过建议你还是留下,用摸鱼的时间咱们唠唠嗑,也是不错的嘛。
书接正文,什么是无效化工作呢?
这里博主举个栗子:我们收到了一个需求,一天的时间,让我们去做三个功能,分别是:背包、任务、排行榜。OK,让先我们先来确定下功能制作流程。
首先是背包功能:我们需要 拼界面-创脚本-声明组件属性-编写脚本声明周期-编写组件查找代码或直接拖拽组件进行赋值-接入背包协议-编写业务逻辑与界面交互相关代码。
接着是任务功能:我们仍需要 拼界面-创脚本-声明组件属性-编写脚本声明周期-编写组件查找代码或直接拖拽组件进行赋值-接入任务协议-编写业务逻辑与界面交互相关代码。
最后是排行榜功能:我们还是需要 拼界面-创脚本-声明组件属性-编写脚本声明周期-编写组件查找代码或直接拖拽组件进行赋值-接入任务协议-编写业务逻辑与界面交互相关代码。
由上面的功能制作流程我们可以清晰的看到,三个功能是不同的,但是有一半的工作都是相同的,比如:创脚本-声明组件属性-编写脚本声明周期-编写组件查找代码或直接拖拽组件进行赋值。这些工作都是重复性工作,回想一下,我们在编写代码的时候,都会把重复性的代码提取成一个方法供多处使用,一方面是使用方便,另一方面是则代码阅读性提高,出了问题改下总接口即可。试想一下,那我们能不能把 创脚本-声明组件属性-编写脚本声明周期-编写组件查找代码或直接拖拽组件进行赋值 这些重复性的工作也提取出来呢?
答案当然是可以。请往下看。
我们做自动化工具最终的目的就是把 创脚本-声明组件属性-编写脚本声明周期-编写组件查找代码或直接拖拽组件进行赋值 这些重复性的工作一键自动化。
我们在拼好界面的之后只需按下一个按键,就会自动创建脚本、自动声明属性,自动创建脚本声明周期、自动编写组件查找代码、或自动拖拽组件进行绑定。
原本需要5分钟的事情,我们一秒钟即可完成。这提升的效率可就是几十倍了。
这里博主介绍下该工具的功能:
1.一键生成界面脚本
2.自动声明组件属性(自定义字段名)
3.自动生成组件查找代码(图方便选此)
4.自动拖拽组件进行序列化 (图高性能选此)
5.自动绑定组件监听事件
6.自动创建脚本声明周期(可定制声明周期)
我们只需要在制作界面的过程中按照一定的规则去打理一下界面的节点,即可自定义脚本字段名称。
博主不管是做游戏还是做工具,只有一个前提,那就是 精品。
所以该工具提供了两种自定义脚本字段名的方式。
方式一:固定格式节点名称法。我们在制作界面时只需要给节点按照 [组件类型]字段名称
的格式起名,即可自动生成在脚本中。
比如:[Button]Login [Image]Logo
对应的生成则为
public Button LoginButton;
public Image LogoImage;
方式二:节点Tag标记法。这种方式相较于第一种方式而言更加方便且自由,因为我们不需要修改节点的名字,也就意味着能更好的去兼容老项目的UI界面。
比如:Login节点的Tag选择为Button,Head节点的Tag选择为Image,对应的生成则如下:
public Button LoginButton;
public Image HeadImage;
总结:方式一与方式二的区别在于是否要修改节点的名称,若不想修改节点的名称,则可以使用Tag标记法去生成界面脚本,若为了可视化,能够在第一眼就知道该节点是什么作用,则可选择固定格式命名法。
我们可以看到组件查找代码按照我们的格式生成出来了,并且组件的查找路径以及组件的获取、组件的事件监听都自动生成了出来。这些工作量由界面的复杂程度来决定,界面越复杂我们手动编写消耗的时间就越长,并且在手动编写查找路径时还极易出错。但是使用了我们的一键生成工具之后,不管界面有多复杂,我们都能一秒钟搞定。而且永远不会出现路径查找出错的问题。
注意:从之前的3步(声明属性-编写组件查找代码-监听组件事件) 到现在的一步。减少的不仅仅是操作步骤,还有我们宝贵的时间。 并且不管我们如何修改界面,只需重新生成下脚本即可。
下面是增加两个组件的生成效果:
可以看到,随着我们一个按钮的按下,非常完整、整洁并且分区域的一个界面脚本就生成出来了。不仅是我们的效率上去了,同时逼格也提升了。这么规范的编写格式,不管项目后期有多复杂,我们的代码都会非常的规范、好看。随着人员的变动以及需求的修改,他能保证我们的代码不会在乱的像坨奥里给一样,不管是回顾自己的代码,还是新成员进来,我们的代码都能让人感觉到很舒心,整齐、规范。
并且他还有很大的一个优点,就是我们只需要去编写业务逻辑即可。无需操心UI组件相关的东西。
由上图可以看到,我们的代码生成出来后,已经是一个非常完善的脚本了,所有的组件会自动查找好,所有的声明周期会自动声明好,以及组件的监听方法也会自动生成好,并且建立监听。可以说,我们只需要去调用下业务逻辑的接口,整个功能就制作完成了。
这里回复一下很重要的一个问题,就是:
自动生成会不会覆盖掉自己编写的代码?
答案是: 不会!
再次生成之会在原有的代码上去新增新的自动生成的代码,并不会覆盖掉原有的任何逻辑。
所以说,可以放心大胆的使用。
由上图可以看到,我们在新增或修改组件之后去生成代码,并不覆盖掉我们原本的逻辑,所以该工具还是非常安全的,并不会造成我们的代码丢失等问题。所以我们可以放心去使用。当然,如果美术愿意,搭界面的工作直接分离给美术也是没有任何问题的。我们只需要关心逻辑如果编写即可。所有的流程完全自动化。不管是新手还是老手,都是必备,并可以以此为基础打造一套属于你的高逼格框架。
众所周知,Unity的Find方法是有一定的性能消耗的,所以如果追求性能到极致,可以选择第二种生成方式,自动拖拽组件进行赋值。其实大家都有做过手动去拖拽组件进行赋值,虽然性能是优势,但无奈组件太多的话,拖拽起来着实麻烦。所以该工具针对性解决痛点,把手动拖拽完全自动化。我们只需要点一个按钮,脚本会自动创建-声明属性-生成组件事件监听方法-自动拖拽组件到 Inspector面板上进行赋值。免去了我们手动一个一个拖拽的烦恼。
组件查找的优点: 可以在代码种直接看到组件的获取路径,降级工程不会出现引用丢失。
组件查找的缺点: 有性能消耗,需要编写大量组件查找代码,易报空,代码美观度下降,且组件名称不能随意改动,组件层级也不能发生改变。
组件拖拽的优点: 性能好,无报空可能,代码量减少更加舒适整洁,节点名称可以随意变化,节点位置及层级可自由改变。
组件拖拽的缺点: 在降级工程的情况下可能会出现引用丢失问题。
注意:该工具演示的界面为 UI逻辑与数据组件分离式设计。
所以生成会有两步,第一步式数据组件,第二部则是界面脚本。
设计初衷是为了减少UI逻辑脚本的代码量,使其看起来更加规范,舒适,整洁,开发者只需关心逻辑即可,无需关心数据组件。如果放到一起的话,会造成脚本代码过于膨胀,杂乱,阅读速度下降。反而违背了设计的初衷。