Unity

浅谈Unity开发中的分层设计

在最初的时候,我在开发的时候并没有分层的概念,也没有所谓的复用代码,写过的项目代码也是用完之后就不会再碰,下次需要做新项目的时候就 从头开始写。
并且整体的构架耦合也非常严重,代码可以用一坨一坨来形容。

后来做了更多的项目之后,发现有很多代码可以进行重用,例如资源加载、UI管理、通用工具类等等。层级结构开始发生了一些变化。
我们会将很多代码抽出来,可以为各种不同的项目提供服务,而逻辑业务层则是每一个游戏都需要各自进行编写。逻辑业务层依赖于通用服务层,服务层通过事件系统来与普通逻辑业务层交互,而业务逻辑层之间也通过事件系统进行交互。关于事件系统可以参阅我以前的文章:在Unity中自定义一个自己的事件分发系统

但是这个层级设计依旧存在着较大的问题,例如底层服务之间相互引用,造成在单独取出某个模块的时候产生了很多问题,我们不得不将很多不需要的模块全部迁入到新的项目当中。特别是通用工具类以及资源加载模块,非常多的服务层模块与它们出现了耦合。在这方面,我曾经才用过几种不同的方法:
首先我尝试使用宏对模块之间进行分离。之前我也有一篇文章特别讨论过使用宏进行模块分离:在Unity中利用宏将不同的模块完全分离 。但是我在后面的开发中发现,宏对代码而言不易管理,并且容易对开发者造成误解。
然后我则是尝试将代码的耦合直接完全进行分离,而将未实现的代码在别的模块中另外实现一份,但是特别是对于资源加载模块而言,这种冗余是不允许的,因为要保证每一个模块的加载方式都是相同的。
除了服务层模块耦合的问题以外,上层逻辑与UI的耦合也是一个大问题。在游戏开发当中UI交互占了游戏开发的很大一部分,如果逻辑与UI紧耦合,则会造成更换皮肤时大量返工的情况发生。
首先我们来说一下UI分层,为了应对UI逻辑紧耦合的情况,我们通常的做法是将逻辑与UI分离,常用的三大设计模式:MVC、MVP以及MVVM。其中较为知名框架的有PureMVC、StangeIOC还有uFrame。我自己也针对自己的情况专门实现了一套MVVM的框架,将逻辑与UI分离。实际上是分成了三块:表现、逻辑、数据。想要具体了解其中内容的可以阅读我之前的文章:在Unity中搭建一套自己的MVVM框架
层级图如下所示:

当然,其实UI表现层也是会依赖于通用服务层的,毕竟通用服务层要对所有能提供的底层功能负责。例如UI层级的管理,资源的加载,当然通用工具类更是少不了。
但是只要不涉及向上依赖旧不存在什么问题。
接下去我们要解决困扰已久的服务层模块耦合的问题。
这思想又来自于设计模式,也就是中介者模式,中介者模式是大量依赖的优良解决方案,包括事件系统也是构建在这一模式之上的。

在之前的架构之中,每个服务模块之间都直接对其他模块进行引用。而在这里我们将通用工具类放入了更下一层,我们称为公用基础类库,在公用基础类库中我们将我们所有模块种最通用的功能进行抽出,尽量保证每一个服务模块都只依赖于通用工具,首先这就保证了尽量少的冗余代码。
然后我们尽量将UI管理模块之间的通信功能使用接口进行抽出,这样我们就可以保证我们可以将被引用模块的实现替换。例如在某些情形下我需要使用细粒度资源加载,而另外一款游戏当中我需要采用粗粒度的加载方式,只要实现了函数接口我便可以保证模块之间的松解耦与引用。
我们要做的是将我们将会用的模块注册到模块管理模块当中,模块管理模块会帮助我们创建与销毁模块,并且帮助我们获取不同的模块。
在业务逻辑层,我们可以通过ModuleManager.Get<类名>来获取完整的模块功能,而在服务层内部则尽量通过接口来进行模块之间的相互引用,例如ModuleManager.Get<接口名>,以保证每一个模块能够进行轻易的添加、移除、替换。
到这里为止,我的分层设计也差不多了,但是事实上我们依旧可以抽出很多东西以提高代码的重用度。
例如我们可以将常用的UI控件单独抽出,这样我们就不需要每次自己重新编写控件了。

事实上很多公司也是这么做的。统一的UI标识有利于产品的标识度,也可以减少程序与美术的工作量,何乐而不为。
在帧同步或者状态同步的网络游戏中甚至需要将逻辑层与表现层(例如角色的行走表现、技能释放等等)也进行分离,以保证游戏的流畅运行等等。
构架的改进是永无止境的。而且世界上也不存在最好的框架,而只有最合适的框架。如果为了一个小游戏而在框架上面大费心思,可能真的是杀鸡用了牛刀了。
但是不容忽视的是代码重用的重要性,巧妙地将各个模块分离之后能够帮助我们更好地开发新的项目,让我们的积累能够更加有效地投入到新的项目当中去。

本人才疏学浅,如有疏漏,请多多指正。

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注