Unity3d中UI开发的MVC模式 ,和游戏开发的其他模块类似,UI一般需要通过多次迭代开发,直到用户体验近似OK。另外至关重要的是, 我们想尽快加速迭代的过程。使用MVC模式来进行设计,已经被业界证明了是可以解耦屏幕上的显示,如何控制用户的输入对显示的改变,以及如何根据应用的状态进行改变。MVC模式提供了以下好处:
(1) 可以修改UI的外观,而不用修改一行代码
(2) 在不同的组件里面可以共享同一套逻辑代码,用来创建复杂的视图;
(3) 可以用很小的代价来改变UI的实现,比如正在使用NGUI , 但将来会切换成 UGUI
代码示例
这里提供了一个MVC在使用NGUI开发的例子,需要注意的是,我们不能在代码中提供NGUI库,毕竟它是收费的,所以想运行起来的话,需要自己导入NGUI库。接下来的内容都会以这个例子的代码作为基准,所以可以在阅读时可以先把代码下载下来。
总体概述
这是一张简图,从宏观的角度描述了代码中MVC模式的不同部分。
Model
传统的MVC中的Model,我们都很熟悉:
(1) 不保存任何View的数据或者View的状态
(2) 只能被Controller或者其他Model访问
(3) 会触发事件来通知外部系统进行处理和变更
这里的Model是使用Plain Old C# Objects(POCOs)来实现的,就是不依赖于任何外部库的C#代码。这是例子中对于PlayerModel的链接地址,它表示了Player的数据,包括HitPoints,XP和level,使用两个属性来进行访问。我们可以增加XP点,而Model则会raise一个XPGained事件。当获得升级的经验时,Level属性会更新,并raise一个LevelUp事件。
View
概念上的view一般就是在屏幕上渲染的东西。View的职责包括:
(1) 处理用户绘制元素的reference,包括纹理,特效等
(2) 播放动画
(3) 布局
(4) 接受用户输入
在代码这个特定例子中,View的实现使用了NGUI,所以它只是Unity工程中的一个Prefab。但这个实现细节需要解耦。想了解更多学术上的知识的话,还可以看下Passive View。View不知道工程中其他部分的任何事情,无论是数据还是逻辑。这样其他的代码必选显式地告诉View显式什么,播放什么动画等等。
Controller
Controller是连接Model和View的桥梁。它会保存View的状态,并且根据外部事件来更新View的状态:
(1) 持有View所需要的应用状态
(2) 控制View的流程
(3) 根据状态show/hides/activates/deactivates/updates View或者View的某些部分。如controller可临时将攻击按钮Distable掉,因为此时攻击处于冷却状态,冷却状态一过,controller会re-enable这个按钮。
(4) load/Instantiate需要的assets,比如显示particles, 动态改变sprites等
(5) 处理用户在View中触发的事件,比如用户按下了一个按钮;处理Model触发的事件,比如player获得了 XP并触发了升级,所以controller就更新了View中的Level Number
这就是MVC模式中定义的三个基本元素。但在这个例子中,我们加入了另外一个中间层来进一步解耦NGUI的View实现,称之为:
ViewPresenter
一个ViewPresenter位于View和Controller之间,作为一个接口存在,暴露了对于一个View来说是普适的操作集合,无论View本身是基于什么库来实现的(NGUI,UGUI等)
比如一个游戏中的按钮,一般来说都有以下功能集:
(1) 设置按钮label中的文字
(2) 修改按钮的背景图
(3) enable/disable用户输入
(4) 当用户点击按钮时,进行Notify
这些都是与UI具体实现无关的操作,在任何一个UI toolkit中都能找到这些操作。ViewPresenter实现为一个MonoBehaviour被Attach到NGUI View的Prefab上,所以可以在Controller中通过GameObject.GetComponent来得到它来进行功能调用。由于ViewPresenter是游戏代码和UI代码的桥梁,所以它不能完全独立于屏幕渲染的底层实现。在这个例子中,ViewPresenter需要持有NGUI Widgets(比如UIButton,UILabel等)的引用,用来于它们进行交互。其实ViewPresenter实际上是一个适配器模式(Adapter pattern)的实现: 我们额外创建了定制的接口来对应用进行访问。这些引用必须在Inspector或者其他代码中进行设置。
幸运的是,这个设置过程可以部分自动化,可以参看ViewPresenter.AutoPopulateDeclaredVidgets(),虽然ViewPresenter和某个特定的UI系统有耦合,但使用创建用于Controller的接口得到了一个好处:如果需要更换GUI库,只需要修改修改ViewPresenter的实现,而不需要修改ViewPresenter的接口以及controller的任何逻辑。
之所以将其称之为ViewPresenter是因为它与Model-View-presenter模式中的Presenter有些类似,只不过Presenter可以访问Model,但ViewPresenter不可以。
ViewPreseter可以持有一些player标识的状态,比如View存储了不同的颜色来提示heath point( 以健康度作为基准来提示满血,充裕,虚弱之类的),这些值可以暴露出来作为公共属性,运行在运行时通过inspector来进行实时修改。但无论如何,ViewPresenter不能持有应用程序逻辑的任何状态,而逻辑由controller管理,ViewPresenter根本不应该知道什么样的heath level是表示low。
比如,如果扩展PlayerController来处理Hit points,可以增加一个方法来改变label的颜色,当处于low health的时候:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
public
class
PlayerController
{
// ...
void
UpdateHitPointsUI()
{
if
(Player.HasLowHitPoints)
{
HitPointsViewLabel.ShowLowHealthColor();
}
else
{
HitPointsViewLabel.ShowNormalHealthColor();
}
}
}
|
如果你想创建一个非常特定或者复杂的UI,并在工程中进行重用的话,这个方法可能有些过度设计了。在这个Sample代码中,我们很轻松地进行了如此处理:controller只需要修改ViewPresenter中的一个UnityEngine.Color类型的属性。
Handling UI events
NGUI提供了一个设计良好的时间系统,在任何定义了某事件hander的MonoBehaviour中都可以触发这个事件。这样就解耦了触发事件的MonoBehaviour和处理这个事件的MonoBehaviour。然后,强大的功能增加了结构混乱的机会,因为可以使用任何MonoBehaviour作为事件的handler,很随手的就把scene中的某个monoBehaviour拖放到inspector的handler上了,这样当创建一个包含了若干个控件的复杂View时,就容易得到一个难以track的依赖,这个依赖图的复杂度可以非常快速地增长。
为了防止代码中混乱的蔓延,我们遵守了一个非常容易的原则:所有的View的UI事件只能被attatch到这个View的ViewPresenter来进行处理。ViewPresenter会捕获NGUI的事件,并Raise一个 .net的Event作为回应。其他的代码只订阅那个.net时间。这么做是因为需要将UI事件的具体实现与NGUI解耦,因为这样做我们使用代码中的事件,而不是inspector的事件。在我们的观点中,这是一个更安全的方法:可以很容易地在IDE中搜索处理这个Event的代码;而且更加类型安全:(如果你删除了一个处理这个Event的MonoBehavior,你只会发现控件在Play Mode中停止工作了), 可以允许设置Event上的各个参数。当然我们需要在View Presenter中封装NGUI的Event,但我们的使之自动化:看看这个代码ButtonViewPresenter.wireUIEvents()
创建复杂的View
现在已经有一些模块可以支持建造了,通过组合来创建一些更复杂的View变得容易:由若干个UI prefab来组合成一个新的View, 并为这个组合出来的view创建一个新的ViewPresenter, 将子View中的ViewPresenter暴露出来,这样就可以在controller中进行访问了。