Unity StrangeIoc 框架介绍

发表于2016-05-24
评论4 1.84w浏览

想免费获取内部独家PPT资料库?观看行业大牛直播?点击加入腾讯游戏学院游戏程序行业精英群

711501594
  该文是译文,方便大家理解,如有问题可以联系我。
  附上原文链接:http://strangeioc.github.io/strangeioc/TheBigStrangeHowTo.html
  UnityStrangeIoc 框架介绍
  Strange attractors createpredictable patterns, often in chaotic systems.
  这句话应该是作者从一本介绍混沌理论的书上面摘来的,大意为: 奇怪引子从混沌中创造出了可以预测的模式,算是盘古开天辟地吧。

一、介绍
  Strange 是一个轻量的高扩展性的控制反转框架,专为C#和Unity而设计,它拥有如下特点,大部分特点是可选的:
  一个核心的绑定系统,可以支持各种绑定(bindone or more of anything to one or more of anything else.)
依赖注入
1、映射为单例,值或者工厂(每次需要时创建一个新的实例)
2、命名注入
3、 构造函数注入或者setter注入(可以理解为属性注入)
4、标记指定的构造函数
5、标记指定函数在构造函数之后触发
6、注入到Monobehiavours
7、多态绑定:可以绑定接口或者实体类
  两种风格的共享事件桥(Two styles of shared event bus)
1、都可以发送信号到程序的任何地方
2、都会为本地通信映射本地的事件桥
3、都会映射事件到相应的Command类来分离逻辑
4、使用新的信号实现增加了类型安全保证
  MonoBehaviour 中介
1、帮助分离view与逻辑
2、隔离unity特有的代码与其它逻辑代码
  可选的MVCS(Model/View/Controller/Service)结构
  多个Context
1、允许子控件(子场景)单独运行,或者运行在主app之中
2、允许Context之间通信
  扩展简单,可以自建新的绑定器:

二、目录介绍:
  在项目的StrangeIoC > scripts > strange 目录下面有三个子目录,如果在unity里面只能看到两个:
  Framework 包含构成Strange的主要类
  Extensions 库函数
  tests 单元测试
1、绑定
  Strange 的核心内容是对于绑定的一个简单包装。也就是说,基本上我们可以建立各种绑定(bind,connect)。可以绑定一个接口到它的实体类上面。或者绑定一个事件到一个处理者(handler)上。或者绑定两个类:当一个被实例化时,自动创建另一个的实例。为何我们要这么做?很高兴你问了这个问题!当我们编程的时候,大部分的工作最后其实都是绑定。如果你曾触发过一个事件(或者使用Unity3D的SendMessage),如果你遇到过一个类要调用另一个类,如果你写了太多的“if…else”语句,你就是遇到了某种形式的绑定,也就是说,你曾把某些东西与另一些东西绑定。
  但是直接把一些东西绑定到一起会产生问题,因为这么做会造成代码很难去改变,而且容易出bug。例如,我肯定你编写过表达这类结构的代码:“一个东西,包含了另一些东西作为它的组成部分”。比如一个飞船的类,包含一个炮台和一个键盘控制,你实现了它,一切都看起来很好,直到你的老板说他不想要键盘控制,他想要鼠标控制。所以你重写了飞船类,但是等等,你的飞船类其实并没有改变,只是控制改变了,所以为何你要重写飞船类?
  你可以创建一个鼠标控制类并使用它,而不是把控制写到飞船类里面。但是如果飞船包含了鼠标控制类的一个引用,你仍然是直接绑定,为了从键盘控制变为鼠标控制(并且可以在老板改变主意的时候再改回来),你不得不改变飞船类内的引用。
  利用Strange 可以创建间接绑定,减轻你的代码对程序其它部分的依赖性。这是面向对象编程的一个基本原则。只有对象本身可以在不依赖其它实体类的情况下起作用,你的代码才可以称为真正的面向对象。使用绑定器可以让你的代码更加自由灵活。
绑定的结构
  我们快速的看一下一个绑定的结构,这个结构在整个Strange 跟它的所有扩展中都会出现,所以你应该想要了解一下它的运作模式。
  一个Strange的绑定由两个必须的部分和一个可选的部分组成,这两个必须的部分是一个键值对(key and value),使用键来触发值;因此一个事件可以作为一个键来触发一个回调,或者一个类的实例化可以作为键来引发另一个类的实例化。可选的这部分是一个名称(name)。在某些状况下,我们需要描述使用同样键(key)的两个绑定,这时,使用名称(name)就可以加以区分。
  这三个部分有两种方法组合到一起,要么使用一个值,要么使用泛型(C# generics)
  使用泛型会是下面这种结构:


  ”Bind“ 后面是一个键,“To”后面是值。 或者我们也可以使用值来表示绑定:


  输入“MeaningOfLife” 将得到42。
  有时候这两种方法会混合使用:


  当我们使用 Spaceship输入将会得到一个字符串“Enterprise”。
  使用名称(name)时,绑定的形式也不会有大的变化:


  最后来说,以下这几种绑定其实是一样的:


  区别仅仅是语法糖而已。
  绑定的形式无穷无尽,Strange提供给你几个非常有用的绑定形式。不仅如此,整个绑定框架是很简单的,所以你可以自己去扩展,创建新的绑定器组件。下面的章节我们会一一介绍这些形式。
2、扩展
  或许你曾听说过Strange是一个依赖注入框架。我对这个描述感到些许不适。是的,Strange提供依赖注入(DI)并且它很有用,但是这个框架的核心,正如我提过的,是绑定(binding)。安装框架时会附带几个有用绑定器扩展,这个部分我们会详细讲解这几个扩展。记住,这并不阻碍你自己去实现你的自定义扩展。
  注意:下面的章节我提到的是MVCSContext版的Strange,是推荐版本,这个版本包含了下面提到的所有扩展。这是开始学习Strange的最佳方法。
注入扩展
  与控制反转(IoC)关系最大的绑定器扩展是注入器包(injector package)。我们在前面章节提到过注入,在这里将要特别说明一下。
  你也许对于编写接口很熟悉,一个接口内部并不包含任何实现,它仅仅对与类的输入输出做了一些规范定义。在C#里接口的形式:


  而此接口的实现类例如下面表示:


  使用接口编程,我们减轻了一些类包含另一些类的问题(Thing-Contains-SubThingsproblem)。我们的Spaceship类不再需要包含一个键盘监听器,它只需要一个对于输入的响应方法即可。它也不需要一个炮台,只需要一个实体类(’concrete’class)来实现IWeapon接口。这是一个很大进步。
  但是这里有个问题:谁来告诉Spaceship使用那种Iweapon(武器)?我们假设Spaceship在一个GameField类(战场)中,或许GameField可以告诉Spaceship使用哪种武器,但是,GameField仍然需要了解实体类,仅仅是依赖的位置变化了,这样是不够的。 
  GameField 需要有个接口来推送它自己的所有依赖(包括所有Spaceship的依赖),推送到应用的上层。


  这样就不需要实体类了,但是这意味着一个很长的依赖链,贯穿了整个类层次结构。这种结构是脆弱的,只要一个地方发生改变可能破坏很多其它地方,而这些可能被破坏地方又是很难定位的。而且,GameField(或者依赖链上的其它类)需要包含IWeapon。但是GameField 很可能不需要知道IWeapon,为何要为根本不需要的类创建一个依赖?
  那使用工厂模式呢? 如果我们创建一个 SpaceshipFactory, 用来创建Spaceship类并且实现了IFactory接口,这样的话GameField只需要这一个依赖,我们就快要成功了。


  虽然我仍需要关心ISpaceship现在又多了IFactory,但是不需要关心IWeapon了。然而我可能又要关心IEnemy,仔细想想,我需要把所有工厂都联系起来,并且搞清楚怎么安置它们。貌似这种做法还可以,但是其实这种收到普遍好评的模式有一个致命缺陷。
  所以我们来考虑一个完全不同的模式,在这个模式中,不会有一个类与另一个类显示的产生依赖。这个模式叫做依赖注入(Dependency Injection, DI)。在DI模式中,一个叫做Injector的类会提供某个类需要的依赖(通常用接口表示)。这种做法通常是利用反射机制来实现。
  使用依赖注入(DI),如果GameField 需要一个ISpaceship,它将会建立一个依赖如图:


  这里并不需要依赖链,或者工厂。除了你的类实际需要的,并没有其它多余的依赖。而且,你再也不需要显示的声明依赖了。
  那么这一切是怎么做到的?
  C# 的 System.Reflection (反射)允许一个类在运行时被解构和分析,值得注意的是它的速度并不快,所以我们在Strange里尽量少用。当我们反射一个类时,我们可以检测它的方法和属性,我们可以看到它的构造方法,还有它需要哪些参数。通过检查这些线索,我们可以推断出这个类的依赖是什么,而后给它提供这些依赖。
  在Strange中设置一个依赖的代码通常会是如下这种形式


  但是Strange是如何知道要提供哪个实体类给接口呢?你可以通过在一个叫做Context的核心文件中绑定依赖来达成。正如我说过的,“标准的”Context是MVCSContext,你可以扩展这个类来实现Strange的各种优点,当你扩展MVCSContext时,你可以使用如下的形式:


  现在,当一个类需要IWeapon(武器)接口时,它就获得了PhaserGun(激光枪)这个实体类。如果你想要把PhaserGun换成SquirtCannon(散弹炮),你不需要更改其它任何地方,只需要在Context里把代码改成如下:


  瞧!飞船(Spaceship)现在用的是散弹炮(SquirtCannon)了。所有这一切仅仅需要一个关键字来表示这里需要依赖注入:


  值得一提的是,即使你不使用依赖注入,这个[inject]标签也是完全无害的,所以你可以把它加到你的类里,如果有一天你不想使用依赖注入了,这个标签一点也不会影响现有的代码,去掉标签,“weapon”就成了一个普通的属性。

实例化可注入的对象(instances)
  这里有一个地方要注意。如果你想得到依赖注入带来的好处,你需要做如下两件事:
1、在Context中绑定相关类,这一点在上面已经讨论过。
2、使用InjectionBinder实例化所需对象
  一开始你可能觉得第二点有些不同寻常,但是它是很直观的。就像工厂模式一样,唯一不同的是我们在injector中做了所有事情,而不会去为每种类型去建一个工厂。并且大部分时候InjectionBinder是完全不可见的。我们已经习惯了使用如下形式来构造一个实例:


  …所以要好好整理一下思路,让我再一次重申,大多数情况下,你们不需要使用这个方法,因为实例是通过注入得来的。只要你听了我马上要告诉你的,你就不会总想着瞎写new myclass( )了


  正如你看到的,我们还是摆脱了实体类的专制。而且你拿到的实例附带了它本身所需的全部依赖。我们要做的跟以前的老方法比仅仅是略有不同。

注入映射(Injection mapping)的种类
  我们可以用多种方法来绑定注入,这些方法都很有用,其中一个很有用的绑定是ToSingleton(单例)。它的形式如下:


  单例模式可能你已经了解了。它是指在整个应用中只有一个实例会被创建。如果你使用了这种模式,你可能会见到如下代码:


  单例模式也有一些问题,最突出的就是有时它们并不是唯一的。例如,上面的代码,可能会造成本来只有一个ISocialService(Twitter),而由于设计上的改变,某一天可能会变成3个(Twitter,Facebook,G+)。写出TwitterService.Get()代码的人不仅具体的依赖了TwitterService,他还显式的认为这是一个单例。如果这一点变了,他不得不重构代码。
  与上面使用单例来Get的代码相比:


  等等,这个不可能是对的。它看起来跟之前我们看到的injection 标记一模一样。是的,这就是我要说的点,你的类并不需要TwitterService,它需要的是ISocialService。而且它并不会关心这个接口的实例是不是单例。
  由于Strange的依赖只是一个映射,所以更改单例的映射成了很繁琐的事情,客户端不仅不知道ISocialService用的是哪一个实例,而且不知道这些实例是不是单例。应该是这样的,一旦你使用了依赖注入,你就不需要再写单例了,而是映射单例(map Singletons)。
  但是在如下例子中,我们不仅仅是改变services,我们会增加多个services。那我们怎么分辨它们呢?这就引出了第二种映射方法:名字注入(namedinjections)


  名字注入与其他的注入方法稍有区别,注入器(injector)可以通过名称来分辨满足同一接口的不同类。使用这种方法,你可以在不同的地方注入ISocialService并且拿到满意的版本。使用类(client class)需要在标签中添加一个名字来匹配。


  名字可以是任意类型,但是实践中使用枚举是一个不错的选择。注意,类中的这个带名字的标签创建了另一种依赖(我们毕竟声明了实用类需要一个比某个接口更加具体的东西:不仅满足接口,还要满足名字),所以我们要小心使用这个功能。
  有时,你清楚的知道你想要注入的是什么。或许你加载了一个配置表,它会用在应用的各处。这个可以用值映射(value mapping)来实现.


  这个例子里,myConfig是某个配置文件的加载结果,现在,不管你在哪里需要Iconfig,你将会得到myConfig实例。再次申明,使用类并不知道它是否是一个单例,值或者其它类型。它只需使用Iconfig即可,不需要关心它的值从哪来。
  有时你也可能遇到你没有某个类的修改权限。也许这个类来自外部库,已经被写成了单例。这时你仍可以使用值映射来实现注入,只需要获取实例,映射实例即可:


  如果TouchCommander实现了某个接口,绑定到接口肯定是个更好的选择。或者(我自己经常这么做)你可以创建一个接口将TouchCommander包裹在facade(外观类)里面。毕竟,某天你可能将TouchCommander换成另外一个触摸事件处理系统。如果你真的这么做了,而你的应用中遍布TouchCommander的引用,那么你不得不面对大量的重构。一个实现了你所选接口的facade类可以帮你避免这个问题,并且可以牢牢的控制对于TouchCommander实例的引用。
  那现在如果你每次都想要一个新的实例呢?我们利用工厂映射(factory mapping)来实现这个要求:


  这与单例映射(ToSingleton mapping)基本相同,只是没有了ToSingleton指令。当这个注入发生时,你将得到一个新的IEnemy,在这个例子中,它映射到了一个实体类Borg上。注意我们可以结合这些映射,比如工厂映射也可以使用名字:

 

  你还可以多重绑定,这样允许绑定的多态性,这是对于一个类可以实现多个接口的另类说法:


  这样不管[inject]标签标记了IHittable还是IUpdateable都允许你获得一个enemy(敌人)。注意,多个“Bind”是有意义的,但是多个“To”却毫无意义。你可以绑定多个接口,但是只有绑定到单个实体类型(concrete type),或者值的时候才会生效。·

可注入类中的一些操作(Some thing you can do with Injectable Classes)
  在前文我层提过如何在类中声明setter注入。在这里我再重申一下,如果想要一个属性是可注入的,使用[Inject]标签:


  或者给它加上名字:


  或者用一个maker类来标记它:


  这些都是setter注入的例子,它只是Strange两种注入方式的一种。还有一种方式是构造器注入(constructor Injection),这种注入方式是在类的构造方法中完成的。Setter注入有两个显著的缺点,首先可注入的属性需要是public类型才能被注入。这可能并不是你最初的选择(如果不使用注入你可能希望它是private)。利用构造器注入你可以保持private类型是private的。其次如果你使用setter注入,你必须小心的编写你的构造函数。定义上来看,构造函数会在setter被赋值前运行。所以,注入的属性在构造函数中是不能使用的。而由于构造器注入是以构造函数参数的形式来提供所需依赖,所以注入值可以立即使用。


  除了[Inject]标签,你应该了解更多的状态标签(attributes)。
  如果你的类有多个构造函数,[Construct]标签可以用来标记哪一个会被Strange用到。如果没有构造函数被[Construct]标记,Strange会用参数最少的那个构造函数。当然,如果你只有一个构造函数,你完全不需要使用[Construct]标签。

 

  如果你使用setter注入,[PostConstruct]会是很有用的一个标签。任何标记了[PostConstruct]的方法,会在注入发生以后立即被调用。在这个方法中使用注入依赖不会产生空指针。


  可以声明多个带有[PostConstruct]标签的函数,而且它们可以被排序。


  到底要用setter注入还是构造器注入呢?详细请看这里。
  搬运两个图来加深理解:
  Setter注入:


  构造器注入:


  可以看一下两种注入方式的区别。
注意:
  下面几个点在使用注入的时候要格外注意:
1、 注意依赖回路。如果类之间相互注入,这将会导致一个依赖的死循环。Strange 会抛出一个InjectionException 异常来警告你,但是你应该第一时间避免这类情况。
2、依赖注入使用了反射,前文说过,它的执行比较慢。Strange使用ReflectionBinder来最小化这个问题(并且效果显著),但是要考虑这个方法对于性能要求很高的代码是否可行,比如说你游戏的主循环。
3、注意,如果你使用了注入,你必须要进行映射。创建依赖但是忘记填充它会造成空指针错误。幸运的是Strange会替你关注这些问题,并且帮你找出缺少的映射和需要映射的地方。

反射器扩展(The reflector extension)
  事实上,你并不需要十分了解这个扩展,但它确实存在,并且处理注入过程中的反射。反射是在运行时对类的分析过程。Strange使用这个技术来决定将要注入什么。
  值得注意的是反射器扩展是在开发后期才编写的,它是为了优化反射执行缓慢的问题。当时我觉得如果我把反射结果做缓存应该可以提高反射的性能,于是我写了ReflectionBinder来做这件事。在这之前,每个类在每次实例化的时候都会进行反射。现在每个类只进行一次反射。使用1000个中等复杂的实例来测试,结果有5倍的性能提升。这是一个极好的,扩展核心绑定器来解决问题的例子。)
  有一个值得你注意的特性是它可以“预反射”类。也就是说,你可以在当前性能压力比较小的时候来触发消耗比较大的反射过程(比如,当玩家在看一些静态UI的时候)。这个可以通过injectionBinder实现。
  第一个例子展示了怎样反射一个类的链表:


  第二个例子简单的反射了所有映射到injectionBInder的所有东西;


分发器扩展(The dispatcher extension)
  注:EventDispatcher是Strange默认的分发系统。现在我们有了Signal扩展,它在分发中加入了类型安全。我们推荐这个新的系统,但是计划对这两种系统都支持。使用哪一个由你来决定。
  原理上来说,分发器的功能类似经典观察者模式中的观察对象。也就是说,它允许被某些类监听,并且在特定事件发生时,通知这些类。在Strange中,我们实现了EventDispatcher,它会将触发器(可以是任何类型,但是一般用String或者枚举)与有单个参数或者无参函数绑定,当触发器触发时会调用所绑定函数。结果参数(如果需要)会以IEvent的形式提供,IEvent是一个包含了事件相关数据的值对象(你可以自己实现IEvent接口,Strange标准的实现叫做TmEvent)。
  如果你在使用MVCSContext版的Strange,默认将会有个全局的事件分发器(叫做‘contextDispatcher’),它自动被注入到了应用的各个地方,你可以用它来发送消息。还有一个crossContextDispatcher可以用来在不同的Context间发送消息。
  使用EventDispatcher可以实现两个基本功能:发送事件和监听事件。也就是说,只有少数几种方法可以配置事件怎样来被发送和接收。我们先从最简单的监听形式来开始。

 

  这将监听分发器,当“FIRE_MISSILE”事件被触发时,onMissileFire函数将会被调用。
  让我们先入为主的认为,简单的东西不一定好。使用String会使得代码不好维护。String可以在其它相关代码不可知的情况下被修改,这个可能造成灾难性后果。更好的形式应该是常量。。。或者是枚举:


  你可以像下面这样移除监听:


  在底层,AddListener和RemoveListener其实跟Bind与Unbind是同义词。AddListener/RemoveListener对只是提供大多数人熟悉的语法糖。还有一个比较方便的方法可以利用boolean来更新监听器:


  被调用的方法可以有一个参数或者没有参数,取决于你是否关心事件所带的信息:


  你也会想要发送事件。这是一种表达“看这里!我在做一件很酷的事情!”的方法,这里也有几中方法来做这件事。同样,我们从简单的开始:


  这种形式的发送会生成一个新的TmEvent并且调用所有的监听者,但是由于你并没有提供数据,TmEvent的数据将会是null。你也可以发送事件并提供数据:

 

  现在生成的TmEvent将会携带与orientation匹配的Vector3数据。
  最后,你还可以显式的构建TmEvent并将它发送:


  使用哪种方法取决于编码风格。每种方法对于监听器来说其实是一样的。

 

命令扩展(The command extension)
  除了将事件与方法绑定,你也可以绑定事件与命令(Command)。Command是经典Mode-View-Controller-Service架构中的Controller(控制器)。在MVCSContext版本的Strange中,CommandBinder监听着分发器所有的事件(当然在你自己的Context中你可以改变这一点)。下文中将要讲到的信号(Signals),也可以与命令绑定。当触发一个信号或者事件时,CommandBinder 会查看是否有Command与信号或事件绑定。如果找到绑定,一个新的Command实例会被创建。这个Command会被注入,执行,然后销毁。我们先来看一个简单的Command:


  这个例子中有几个值得注意的地方。首先,注意我们继承了EventCommand,而且我们使用了strange.extensions.command.impl命名空间。继承EventCommand甚至是Command并不是必须的,但是你必须实现ICommand接口。其次,注意你可以在Command中使用注入。这一点非常有用,因为它意味着在Command中可以与model或者service进行交互。最后要注意通过继承EventCommand我们可以使用dispatcher(EventDispatcher被注入到了Context的各个地方 ),所以contextDispatcher的所有监听者,无论在应用的哪个地方,都可以接收到我们发出的GameEvent.STARTED事件。由于这是一个同步命令,我们只需触发事件即可。一旦Execute()执行完毕,这个命令将被清除。
  但是,对于异步命令,比如调用网络服务该怎样处理呢?我们可以使用Retain()和Release()这一对方法来处理,请看这个例子:


  你应该差不多会理解上面的例子了。我们给gameServer发送了SendScore请求,这个请求需要处理一段时间。这个命令需要等待服务器返回结果。通过在Execute方法中第一行调用Retain(),我们将这个命令保存在了内存中。当你调用了Retain(),无论回调函数的结果是怎样,记得还要调用ReLease(),否则会造成内存泄漏。

映射命令(Mapping commands)
  虽然我们可以在任何地方映射命令,但是我们通常在Context中做这件事。这样当你需要时可以更方便的找出映射关系。命令映射看起来像一个注入映射:


  你可以绑定多个命令到单个信号:


  你也可以随时取消绑定:


  如果你想要一个命令只触发一次,有一个表示“一次性”的指令可以很方便的满足这个需求:


  通过Once()方法,你可以确保命令触发一次以后绑定关系会自动销毁。
  序列(Sequences)是指一系列的命令按照顺序执行。命令一个接一个的被触发,直到队列结束,或者其中一个命令执行失败。命令可以调用Fail()函数来打破序列。如果要创建几个链形依赖的事件,比如建立有序动画,或者设立一个守卫类来判断命令是否需要执行。
  映射一个序列只需要加一个InSequence()指令:


  上面这个序列代表的意义是,一次点击可能表示已经通过了一个关卡。所以我们运行CheckLevelClearedCommand(检查是否已通关)。如果通关,我们运行EndLevelCommand(结束关卡)。如果这这个命令表示我们已经打到最后一关,那么我们运行GameOverCommand。在这个过程中,我们可以调用Fail()来停止这个流程。
  如同常规的命令一样,序列中的命令可能是异步执行的。如果是这种情况(假设Fail()没有被调用),后面的命令将会在Release()调用后被执行。

信号扩展(The signal extension)
  信号是一个分发机制,它可以代替EventDispatcher,在Strange v.0.6.0中被引入。EventDispatcher创建并且发送 IEvent对象并使用其中的一个data属性来传递信息,而信号通过注册到回调,可以传递0到4个强类型的参数。这样做相比EventDispatcher有两个主要优势。第一,信号的发送不会产生新的对象,所以不需要对很多新的实例进行GC(垃圾回收)。更重要的是第二点,信号发送是类型安全的,如果信号与它注册的回调不匹配,在编译时就会报错。
  另外一个重要的不同点是每个context里有一个“全局“的EventDispatcher(还有“更加全局”的CrossContextDispatcher)触发事件,信号使用了一个不同的模式。每个”事件“都是一个针对某一任务的信号个体产生的结果。所以EventDispatcher是完全统一的,而信号可能会有多种。让我们来看一些例子。
  这里是两个信号,每个有一个参数:


  注意看每个信号的发送类型是怎样在实例化中确立的。我们用几个回调来延伸一下上面的例子:


  值得注意的是信号是强类型的,信号与侦听者类型符合是编译要求。也就是说应用会编译失败,如果你写了下面的代码:


  这样,很难有一些运行时的类型错误。(作者原话:This makes screwingup your listeners pretty darned difficult)信号的参数是类型安全并且向下兼容的。这表示对于参数类型可赋值即可构成合法的


  你可以创建带有0-4个参数的信号,信号使用Action类作为底层机制来实现类型安全。Unity的C#实现每个Action允许最大4个参数,所以我们只提供这么多。如果你想要4个以上参数,考虑创建一个值对象,并且发送这个对象。


  当然,如果不想使用上述例子中的声明方法你还可以自建信号的子类。这个在Strange中很有用,特别是当你想要一些简单的,易读的跨Context信号的名称时。这是一个信号子类的例子;


将信号映射到命令 
  如果你想要在你的Context中将Signal绑定到Commands(很好的想法)你需要做一些小变动。要是想要全部的Signals体验,加入如下代码到你的Context中:


  这段代码告诉Strange我们不再使用默认的CommandBinder,而是用SignalCommandBinder来代替它。这样,Signals会触发Commands而不是Events。注意Stange目前支持Events或者Signals映射到Commands但是二者不可以混用。
  加入上面代码后,Signals也可以像Events一样被映射到Commands。基本语法如下:


  注意,这仍然是commandBinder。我们只是去掉了原来处理EventDispatcher的映射,然后加入了处理Signals的映射。当然所有Command-mapping的一些特性都支持,包括多命令(multipl ecommands),序列和Once()映射。
  将一个信号映射到命令会自动生成一个注入映射,你可以使用[Inject]标签来获取它,示例如下:


  你可以在任何需要的地方使用这个注入(当然最好要符合一定的规范),包括在Commands(命令)中或者是Mediators中。
  为了弄清楚Signal/Command映射是如何工作的,我们简单的过一个例子,例子中我们将上述ShipDestorySignal 信号映射到一个Command,我们将从在Context中绑定信号开始:


  在ShipMediator类中,我们注入这个信号,然后将它发送:


  发送一个通过SignalCommandBinder映射的信号会产生一个ShipDestoryedCommand实例:

 

  你可以看到,映射信号到命令的方法与之前使用事件的方法比较相似。
  有两个重要警告:第一,Signals支持相同类型的多个参数,但是Injections(注入)不支持。所以映射到Command(命令)的信号不允许有多个相同类型的参数。


  再次提醒,你可以使用值对象来突破这个限制
  第二个警告:Strange有一个方便的,内置的START事件来驱动程序开始。解绑EventDispatcher会把这个事件关闭。因此推荐的解决方法是使用自定义的StartSignal来重写你Context中的Launch方法,像如下一样:


不需要Command来映射信号
  上面提到,将Signal映射到Command会自动创建一个映射,通过注入的方式,它可以在任何地方获得,但是要是你只想要一个没有绑定Command的Signal呢? 这种情况下,只需像如下一样用injectionBinder来创建映射,跟其他注入的类一样:


中继扩展(The mediation extension)
  MediationContext 是Strange专为Unity3D编写的部分。这是因为mediation目的是为了细致的控制你的View(视图)与程序的其它部分交互。在开发过程中View 本身就是常常变动的,把这种天然的杂乱留在view类里面处理是极其明智的选择。因此,我们建议你的view包含两个不同的MonoBehaviours:View和Mediator。

View
  View 类代表着MVCS结构这种的V,一个View就是一个MonoBehaviour,你可以编写它来控制视觉(和听觉)的输入和输出。这个类可以在Unity编辑器中挂在相关的GameObject上。如果它有公有组建,它们可以像其它正常脚本一样在编辑器中调整(Inspector上)。想要绿色的按钮吗?在View中实现吧。想要绿色按钮上面有数字吗?在View中实现吧。想要注入一个model或者service吗?等等,不要这么做!为什么呢?
  你的View可以被注入,但是将你的View直接与models和services绑定是非常不好的习惯。正如我说过的,你的View代码可能会变得混乱,保护其它类不受这些混乱影响是值得的。下一章我们将会带出我们认为的使用Strange开发程序的最佳架构,但是现在我们先来考虑一下你的View应该只负责做如下的事情:
1、编写可视组建。
2、当用户与这些组建发生交互时发送事件。
3、暴露接口,允许其它角色修改这些组建的视觉状态。
  通过用这三条来限制你自己,通过把所有的逻辑或者状态都放在View之外,通过拒绝将models和services注入到View里,你包装了View并且让开发更加简单,在长远来看好处会越来越突出。在这个上面请相信我。
  现在,在上面的第三条中我提到要暴露接口给其它角色。谁将是这个角色呢?

Mediator
  Mediator类是一个单独的MonoBehaviour,它的工作是既要了解View又要了解整个程序。它是一个thin class(瘦类),也就是说它的职责会很专精。它对View有亲密的了解,而且它可以注入,并且拥有发送和接收信号的权限。所以想想绿色按钮上面的数字。你本来打算将一个service注入到View中来展示,比如说,在线好友的数量。现在你可以将service注入到mediator,但是既然Mediator应该是瘦的,更好的答案是发送一个请求,让Command来处理Service调用,然后发送一个响应。这样做代价是绕了很多弯路,但是得到是清楚的代码结构。
  这个是一个Mediator的示例:


  需要注意的点:
1、DashBoardView的注入说明了Mediator获得它的View的途径。
2、OnRegister() 是注入之后立即调用的方法。它就像构造函数一样,你可以用它初始化view和其它一些的初始进程,包括——上面的例子中使用的——请求重要数据。
3、ContextDispatcher会在每个继承EventMediator的Mediator中注入,所以你可以向整个context中发送事件。
4、OnRemove()是为了清除和收尾的;它会在View被销毁的时候调用。记得在这里去除添加过的listener。
5、这个例子中的View暴露了两个方法作为接口。在实际情况中,你很可能需要更大的接口,但是原则是不变的:Mediator只被用来在View和程序的其它模块传递信息。
  将View绑定到Mediator对你来说应该很熟悉了:


另外两点备注:
  并不是所有的MonoBehaviour都有资格作为View。这里有幕后的魔法来让Stange知道某个View的存在。所以要么是继承View类,要么是复制那个魔法在你的代码中(只有几行),或者自己建立一个view继承于View类,然后你的其它类继承于自建的view。最后的那个模式很有用,因为你可能想要插入一些debugging代码可以被所有的View调用。
  Mediation绑定是实例对实例的。一个新的View被创建时一个新的Mediator也会被创建来支持它。所以很多View意味着很多Mediator。

环境扩展(The context extension)
  Context包把所有的各种不同的Binder(绑定器)包装在一起。比如说,MVCSContext包含一个EventDispatcher,一个InjectionBinder,一个MediationBinder和一个CommandBinder。你也可以,像我们讨论过的,把CommandBinder重映射到SignalCommandBinder。(Signal)CommandBinder 监听着EventDispatcher(或者Signal)。Commands和Mediators依靠Injection。Context就是我们将这些依赖联系起来的地方。建立项目时,你将要重写Context或者MVCSContext,所有使得程序正常运行的绑定将被写在在它们的子类中。
  多个Context也是可行的。这将是你的程序更加模块化。独立的模块可以自己运行,仅仅在需要时才与别的模块交互。因此核心游戏可以写成一个app,社交模块可以分开编写,聊天app可以作为另一个app,这个三个app在后面的开发中可以被绑定在一起,每个只需共享其它两个需要的部分。

3、MVCSContext:整体情况
  这一章节基本上是对于如何使用Strange和它的MVCSContext创建一个app。前面几个章节,我描述了所有的组件,在这里,我将解释如何将它们结合到一起。
  如果要写一个游戏,使用Strange的话,应当从哪里入手呢? 让我们从最基本的地方开始。
概念:
  Strange 使用MVCSContext 将整个微框架(micro-architecture)包装成一个方便,易用的包。正如它的名字所体现的,它被设计成使用MVCS模式运行的应用。(S 是Service,代表所有你的应用之外的东西,比如web service)。
  以下是所有将要被组装的组件:
1、你的应用的入口是一个叫做ContextView的类,它只是一个简单的MonoBehaviour 用来初始化MVCSContext。
2、MVCSContext(技术上来说,这里应该是一个MVCSContext的子类)是设置所有绑定的地方。
3、The dispatcher(分发器)是通信总线,允许你在整个app中发送信息。MVCSContext中dispatcher发送的对象叫做TmEvent。你还可以重写Context来使用信号。
4、Commands 是可以被IEvent 或者 Signal触发的类。当一个Command被执行时,它承担了部分应用逻辑。
5、Models 存储状态。
6、Service 与外部程序通信。
7、View是附加在Gameobject 上面的MonoBehaviour组件:这部分是玩家实际看到和与之交互的部分。
8、Mediator 也是MonoBehaviour,但是它的功能是分离View和程序的其它部分。
  下图表示了这些部分是怎样结合在一起的:


建立你自己的项目
  下载Stange的目录。在里面你将找到一个完整的Unity项目实例(我建议你看看这个)。打开项目中的TestView.unity文件。
  所有使用Strange所需的东西都在以下目录:


  其中有两个重要的子目录分别是 framework 和 extensions

场景设置:
  当你在Unity中打开场景时,你会找到一个叫做“ViewGO”的Gameobject它的下面还包含一个camera。ContextView最好是游戏层级的最上层,其它内容都在它的下面。虽然Unity并不要求一个单独的顶层GameObject,但是使用Strange的话这样是最好的,尤其是有多个context的时候,因为Strange用展示的层级来决定某个View是属于哪个Context的。GameObject上还有一个叫做“MyFistProjectRoot”的MonoBehaviour脚本。
  运行一下场景,当你点击旋转的文字时候观察会发生什么。没什么特别的,我们现在只是展示一下结构。
  在Inspector视图中,双击一下MyfirstProjectRoot,打开脚本编辑器。

开始了解ContextView…
  ContextView 是一个MonoBehaviour脚本用来实例化你的Context。MyFirstProjectRoot 继承了 ContextView类,并且是我们程序的起点。


  注意,我们使用了strange.extensions.context.impl 命名空间。所有Strange使用的命名空间都是这样的结构,所以你只引入你需要的。
  其余的代码很简单。ContextView定义了一个叫做context的属性来引用我们的内容(context)。我们只需要将它定义就好。我们已经写了MyFirstContext类。This参数是MyFirstProjectRoot的引用。它告诉了Context哪一个GameObject被认为是ContextView。True参数表示一旦我们调用start,其余的部分都会运行。有些时候我们可能需要只运行context而不运行程序本身,但是不在这里讨论了。
  最终,调用context.Start()来开始。

Contextbind
  正如我在上面解释过的,Context是绑定操作进行的地方。如果没有绑定,Strange 应用只不过是一堆杂乱的组件。Context是让混乱恢复秩序的胶水。由于我们继承了MVCSContext,我们也拥有了一系列绑定的优点。MVCSContext被设计用来使得IoC-style的程序有着清晰的结构。IoC-style的程序包含一个注入器,一个消息总线,命令模式,model和service的支持,还有UI的中继。下面是一个简单的Context的代码。

 

  如你所见,我们继承了MVCSContext,也就是说我们继承了它所有的映射关系(你会发现对它更深层次的探索会很有趣)。所以我们已经有了injectionBinder和commandBinder以及dispatcher。注意dispatcher可以在应用的任意地方取得,而且与commandBinder是耦合的,所以任何一个发出的事件既可以触发回调,也可以触发commands和sequences。
  若你已经看过了各个组件的介绍,上面的映射关系正是你所预期的。对注入来说,我们映射了一个model和一个service,它们都是单例。在这个例子中我们将会只有一个view(ExampleView),我们将它绑定到一个Mediator(ExampleMediator)。最后我们映射了两个commands。其中更重要一个的是StartCommand。它与一个特殊的事件:ContextEvent.START相绑定。这个事件会触发程序的开始。你可以绑定一些command或者sequence在它后面,然后将它们当作你的应用的初始化。而且可以看到我们用了Once()来约束它,这个方法会在事件触发一次之后解绑该事件。
  注意还有一个postBinding()方法。如果你想在绑定之后而在程序启动(Launch()方法调用)之前运行一些代码,它是非常有用的。MVCSContext用它来处理那些较早(在mapBindings()运行之前)注册的View。另一个明显并且有用的例子是当你切换场景时在postBinding()中调用DontDestoryOnLoad(contextView),来保留contextView(和Context)。

当Command被触发
  当ContextEvent.START事件触发时,因为它与StartCommand绑定,一个新的StartCommand实例将会被实创建并且执行


  StartCommand继承自EventCommand,这说明了它是一个合法的Command可以被commandBinder使用。它继承了Command和EventCommand中的所有东西。特别要说明的是,继承EventCommand意味着你已经获得了一个IEvent来注入事件,并且你可以获得dispatcher。
  如果你仅仅继承自Command,你将没法自动获得那些对象,但是你可以手动注入它们通过以下方法:


  上面使用了两种不同的注入。IEventDispatcher和GameObject都用了被命名的实例。是因为我们想要参考这些对象的版本。我们不是仅仅想要任何一个GameObject,我们只想要被标记为ContextView的。我们也不会满足于任何一个旧的IEventDispatcher.仅有的一个用来在整个Context中通信的EventDispatcher被标记为ContextKeys.CONTEXT_DISPATCHER. 另一方面IEvent为了被这个特殊的command使用而被简单的映射,所以不需要名字。
  在当前场景中我们所用的依赖是ContextView。我们将会给它增加一个子view。
  Execute()方法是由commandBinder自动调用的。在大多数情况下,执行的顺序如下:
1、实例化与事件绑定的Command
2、注入依赖,包括IEvent本身
3、调用Execute()
4、删除Command
  Commond并不需要立刻被清除,稍后我们会再做说明。如果你看了Excute()中的代码,你会发现它是纯Unity代码。创建一个实例,将一个MonoBehaviour赋上。然后将它的父节点设置为ContextView。我们所用的这个特别的MonoBehaviour正好是一个Strange IView。由于我们在context中映射了这个view:


  这个view自动被中继,也就是说一个新的ExampleMediator刚刚被创建!

A View is mediated
  如果你之前写过unity代码,当你创建了一个View,你会认为它是一个MonoBehaviour, 但是重点是View是你可以看得到或者与之交互的。我将不会花时间来过ExampleView的代码。如果你懂得C#和Unity, 可以在示例文件中自己去看,并不需要过多解释。在此我只想让你注意两点,第一:


  通过继承View,你可以将每个View与Context建立联系。要使用Strange,你要么继承自View要么自己写相关的功能。但是如果你不继承View,你仍然需要实现IView接口。这个要求是为了确保Context可以操作你的MonoBehaviour。(在未来的版本里我或许会寻找其它方法来实现,允许你将一个Mediator映射到任意MonBehaviour)。
  第二点:

 

  注意我们正在注入IEventDispatcher。但是这个跟与StartCommand里的那个不一样。仔细看代码,在上文中提到的EventCommand中写的是下面这个


  通过对注入命名,Command指明了它使用共同的context dispatcher。View不应该注入那个dispatcher。中继的用途是将view与你的逻辑隔离。然而Strange仍然允许你注入到View,但是最好对这个功能有所限制。注入一个本地的dispatcher来与Mediator通信是可以的。注入一个布局文件(当你要发布到多个平台时会很有用)或者配置也是可以的。但是听我的建议,永远不要将model或者service或者其它View和Mediator之外的实例注入。
  现在我将告诉你:这是整个框架中大部分开发者最难理解的概念。View应该只做展示和输入。当一些输入发生时View应当通知Mediator。Mediator(它被允许注入context dispatcher)抽象出View中与应用中其它地方有交互的部分。这将保护你的应用不受混乱的view代码影响,并且保护你的view不受相反的情况影响。
  所以,别说我什么都没告诉你。
  最后针对view,注意View基类使用了标准的MonoBehaviour回调 Awake(),Start(),和OnDestroy().所以如果你重写了这些回调的话,请记得要调用base.Awake()等,保证Strange运行正确。
  现在我们看看Mediator


  在最上面,看看我们在哪注入了ExampleView。这是Mediator获得他所中继的View的方法。Mediator可以获得View的绝大部分信息。(Mediator经常被认为是抛弃型代码”throw-away-code”,因为它十分针对View和程序其它部分的特性)。当然Mediator被允许知道View有个dispatcher并且这个dispatcher有一个叫做ExampleView.CLICK_EVENT的事件。通过监听该事件,Mediator使用了一个处理函数(onViewClicked())来告知程序其它部分,这个事件代表什么。
  我再次强调我之前的观点:View不应该发送REQUEST_WEB_SERVICE事件,View仅仅是视图作用。它仅仅触发一些事件类似 帮助按钮被点击,碰撞,向右滑动。将这些事件变得对程序其它部分有意义是Mediator的工作,比如 请求帮助,导弹击中敌方,玩家重新装弹。后面的事件会绑定到Command上,然后Command会调用支持系统,计算比分增加(增加Score Model中的分数)或者决定玩家是否被允许重新装填。
  OnRegister()和OnRemove()方法就像mediator的构造函数和析构函数。OnRegister()在注入后会立刻调用,所以我通常用它设置监听器或者调用view的初始化函数。OnRemove()在MonoBehaviour的OnDestroy()后调用。他正好可以用来清除操作。确保你移除了所有的监听器,否则Mediator可能不会被正确的回收。
  最后请注意,我们通过继承EventMediator可以获得common dispatcher。通过它Mediator类监听了SCORE_CHANGE事件,这单将在后面讲到。当View中有点击事件时,Mediator会发送REQUEST_WEB_SERVICE事件 ,这将会导致:

另一个Command被触发
  回顾之前的Context代码,其中有一行我们没有讲清楚


  这个表示每当收到这个事件,就会启动CallWebServiceCommand。目前,我们并不是真正的去调用一个web服务,因为它跟教程无关,但是它会让你的注意力集中到一个稍微不同的使用Command的方法。


  现在,其中的大部分代码你都应该理解了。我们在这个command中注入了ExampleModel和ExampleService。我们监听这个服务,并且触发时调用函数。我们使用了mediator触发的事件上所携带的数据(url)。当服务完成时(可能很快,也可能是5ms或者30秒!)就触发了onComplete()。我们取消监听器的映射,在model中设定一个值,最后触发SCORE_CHANGE事件,它会被mediator监听到。
  一切都很顺利,但是如果你认真看就会想起我之前说过Command在执行Execute()后会立即释放。所以为何这个Command没有被垃圾回收?答案是在command的最顶部调用了Retain()函数。它会防止这个Command被释放。直到Release()被调用。显然调用Release()非常重要,除非你想要有内存泄漏。

And we’re served…
  你可以看看ExampleModel和ExampleService来弄明白它们是怎么运行的,但是它们其实很简单。Models仅仅是存数据的地方,Services是参与调用网络的。他们只有一个角色,比较简单。

不要让Model和Service监听事件。
  Model和Service都是被Command使用的,它们并不在交互链中,所以他们不应该那样使用。你可以注入它们,而且你也可以注入一个本地的dispatcher (像上面一样)用来让它给你的Commands回应。而且注入context dispatcher并且发送事件也是可以的。但是

不要让Model和Service监听事件。
跨Context的映射
  通常来说,你应该接受Context之间存在界限的事实。毕竟存在界限是有原因的:它可以使你的一部分程序独立的运行,更加模块化。但是有时一些对象,可能是一个model或者service或者signal需要跨越多个Context。在strange 版本v.0.6.0中我们增加了一个机制使得实现跨越更容易。像下面一样容易:


  加上CrossContext()表明这个绑定会夸Context实例化。它将在所有子Context中可用。注意你也可以重写一个CrossContext绑定。如果你做了本地绑定,本地的绑定会覆盖了夸Context的绑定。

结论
  上面大概解释了Strange如何使用。现在你了解了很多关于Strange如何运行,它可以做一些事情使得这个世界更美好。我建议你试一试多context的例子,因为它将给你更多的可能。我还建议你用Strange写一些东西,实践出真知。如果你从未用过一个IoC框架,我保证它会优化你的开发方式。如果你用过,我希望它不会让你失望。
  最后,Strange是可以扩展的。无穷无尽的绑定器可以被创造。当更多的人接触这种思考方式,我希望我们能够看到更多令人惊艳的插件。

如社区发表内容存在侵权行为,您可以点击这里查看侵权投诉指引

游戏学院公众号二维码
腾讯游戏学院
微信公众号

提供更专业的游戏知识学习平台