烦恼一般都是想太多了。

0%

关于使用PureMVC及FairyGUI在CocosCreator中进行开发的一个架构

是时候做一个总结了。之前一直抱怨 Cocos Creator 的 UI 实在是太难用了,因此再找到了 PureMVC 和 FairyGUI 后,发现进行整合以后,虽然说代码的量会进行增加,但是进行了相当程度的解耦了。在文章 PureMVC在JavaScript的实现关于Fairygui的实现机制了解 分别做了详细的介绍。

Cocos Creator 本身的架构

Cocos Creator 本身是一个 ECS 系统,以每个 cc.Node 节点作为容器(Entity),然后在每个 节点 上挂上不同的组件,来实现不同的功能。如 Cocos Creator 本身内置提供的 Label,Button,Layout 等都是这样做的。

我们可以在 Node 上挂载需要进行渲染的组件,或者单纯的逻辑组件,这些组件只有都是继承自 cc.Component 就行。事实上 Cocos Creator 本身,也是节点上承载的组件的不同,进行了分类:UI节点,渲染节点。渲染节点包括:Sprite,Label,ParticleSystem,其他的都是 UI 节点了。

digraph { subgraph cluster_scene{ label="Scene" subgraph cluster_canvas{ label="Canvas" RN[label="Render Node"] RC[label="Render Component"] RC -> RN } N[label="LogincNode"] C[label="LogicComponent"] C -> N -> NetWork -> Server } C -> RC[style=dotted] }

之后, Component 可以通过一些 API 来访问本节点上的其他 Component,或者 Scene 内的其他节点,及节点上的 Component。一般来说,我们都会将 UI 节点和 渲染节点放在 Canvas ,也方便进行多分辨率的适配。

这样在游戏规模不大的时候其实没有什么问题,但事实上,UI,渲染的内容,实际上是与逻辑相关的,没有做到分层,因此我们引入 PureMVC。

PureMVC

在这样的架构中,所有的信息都是用通知的形式进行交互,在 UI 和数据之间使用了一个 Mediator 来作为中间层,将 UI 和逻辑进行分开。 M V C 间的通信都是使用 Notification 来进行的。

digraph { Core[label="PureMVC CORE"] F[label=Facade] P[label=Proxy] M[label=Mediator] C[label=Command] F -> Core[dir=both] F -> {P M C}[dir=both] P -> Model -> {Server Local Cache} M -> UIComponent -> "Node" }

现在,我们将 UI 也独立出来。

PureMVC FairyGUI

digraph { Core[label="PureMVC CORE"] F[label=Facade] P[label=Proxy] M[label="Mediator\n调用Proxy\n调用UIComponent更新方法\n为UIComponent绑定事件"] C[label=Command] UIComponent[label="UIComponent\n根据数据更新UI方法"] F -> Core[dir=both] F -> {P M C}[dir=both] P -> Model -> {Server Local Cache} M -> UIComponent -> "FairyGUI bin 文件" "Fairy GUI 编辑发布" -> "FairyGUI bin 文件" {rank=min Core} }

因此,这种架构,重点就落到了 Proxy 和 Mediator ,UIComponent 上。

  • Proxy 负责与数据模型的交互,然后发出通知。
  • Mediaotr 负责关注相应的通知类型,进行响应,最终会调用到 UIComponent 中的关于 UI 逻辑的部分。
  • UIComponent 负责加载 FairyGUI 发布的 bin 文件,构造 UI。