ActionScript通用开发框架
ActionScript 3(简称as)自2006年诞生以来,出现了一大批很优秀框架。就我的知识领域,运用包括pureMVC、pushButton Engine(组件框架)、Robotlegs、Ash等等。我将对这几个通用的开发框架进行一个较深入的总结。同时下文的种种判断、结论可能不完全正确,完全限于个人的思考、理解得到的。运用框架让开发效率更高,扩展性好,可维护。理解框架让框架的作用发挥极致,开发挥洒自如!
1 PureMVC
PureMVC很多人应该很熟悉,记得那时候as的开发框架还是很少的,这种基于mvc的框架对于as来说很实用的,as是客户端语言,处理大量视图逻辑,提供了机制去解决视图和控制器间的低耦合。既然是开发框架,我从几个方面去分析它。
> 框架机制:PureMVC几个核心的类组成:Facade(外观),Proxy(模型代理),Mediator(中介器),Command(控制器)。Facade是整个框架的核心,包括mediator、command、proxy全部由它管理。框架大量采用单例,包括Facade本身。mediator是视图的代理器,负责和view打交道,view本身只提供一个ui布局,逻辑控制处理全部在mediator中完成。command提供一种命令模式,单独处理一项逻辑事务,并且这种对应是可以配置,即使用一个命令名称对应一个命令体。这样将整个控制逻辑简单化,单一化模块化,便于替换,更新维护。proxy是数据模型的代理,一般情况我们会设计vo,就是特定的数据模型结构(data struct),然后使用proxy进行代理。整个框架静态分析下来就是这样的了,至此我们还没有分析框架的事件流,没有这个无法进行逻辑控制,协作处理。PureMVC采用了另一种设计模式,观察者模式,这里就涉及到观察者、通知者、消息。观察者就是对象的一个消息处理方法,通知者自然就是发送消息,消息又包括消息名称、内容等。消息发送是通过Facade进行的。Facade提供了机制,在mediator、commnad被注册时进行了消息名称+处理句柄的关联。所以当通过Facade发送消息的时候,将查找这种关联,并让那些observer观察者(meditor、command)进行响应。
> 有图有真相,看看框架示意图更加清晰点
> 运用与优缺分析
第一步,继承Facade,实现自己的外观,进行数据模型代理、控制器、中介器的安装。设计数据模型(vo),完成对数据模型vo的proxy。安装视图组织设计对应的mediator,完成视图事件处理句柄和控制逻辑。划分逻辑,将不同的处理逻辑封装在不同的command中。
pureMVC优点体现在:轻量级的库、简单易用、极大降低耦合度,独立不依赖第三方库。可以很好的协调人员进行mvc模式开发。就当前的框架而言,由于Facade是单例的,在多模块协作会出现问题。一个解决方案是让Facade在不同的包下。当然pureMVC提供了多核版本,这里就不进行讨论了。
2 PushButton Engine(组件框架)
pushButton其实是一个
游戏engine,这里我列出来,是因为pushButton里面使用了一种基于组件的开发模式。按着设计者的初衷,一个游戏的设计,抛弃复杂的继承(因为继承本身也有诸多弊端,在复杂的游戏世界里),而采用一种“平铺”的方式,整个系统采用实体+组件完成。这个engine是比较复杂的,至今我的理解也不深入。如果是详细的讨论整个engine的开发流程,必须单独写一篇了。
> 框架机制:一切皆组件。pushButton包括几个核心类:entity(实体)、component(组件)、template(模板)、group(组)。entity就是一个对象,比如角色、npc,是个抽象的对象。entity总是由component组成,各个component负责不同部分,比如有的是渲染,空间属性,数据模型等。template理解为可以多次初始化创建的entity。group是一组对象的集合,当group被创建的时候,group的子节点objectReference对应的实体等也会被初始化创建。
pushButton提供了查找、访问别的组件的接口,同时提供了一个共享的eventDispatcher,实现消息事件的传递。如果深入去研究,有LevelManager(负责关卡的具体初始化工作)、NameManager(负责名称和类对象索引)、TemplateManager(负责加载卸载关卡文件,和序列化控制)等。
> 框架示意图
查看大图: Go,右键另存为即可。
> 运用与优缺分析
pushButton engine提供了基于XML配置文件的方法加载读取游戏,特别是关卡类游戏。一切基于组件! 在设计的时候,划分好不同的entity,然后分别设计不同的component。如果使用配置,必须写明objectReference,以完成初始化工作。如果使用手动,需要手动给entity添加不同的component,并手动实现整个流程。pushButton提供了屏幕管理类,方便视图间的切换,继承BaseScreen,实现自定义的screen。pushButton api很丰富,提供了很多公用组件模块。对应大的项目可以考虑发布一下组件,让多人提供协作开发。
pushButton的api相对比较复杂,engine核心控制逻辑也需要深入学习才能弄懂!对应这样一个engine,学习成本相对是较高的,稳定性方面也可能存在风险。
3 Robotlegs
robotlegs框架对我而言,很熟悉了。我们的整个项目ui部分完全是基于这个开发的,我还看到过有人使用robotlegs开发出了完整的大型rpg游戏。robotlegs本质上还是mvc类型框架。不过robotlegs使用了依赖注入的方式降低对象间的耦合,简单的说对象间的相互引用是通过robotlegs框架完成的,同时robotlegs提供了更好的通信机制,和更低的耦合性。
> 框架机制:robotlegs本质上也是使用mvc框架机制。包括:Actor(数据模型)、mediator(中介器)、command(控制器)、context(上下文)。整个框架的核心是依赖注入。context中负责完成几个映射的初始化工作,包括控制器、中介器、视图的映射。同时还包括对注入器的初始化工作。并且context里面还提供了一个事件派发器eventDispatcher。actor就是model部分,对应自定义数据模型一般继承actor,事件数据模型更新是派发事件通知给meditor和command。mediator提供对view的中介,负责处理和view的交互,发生消息命令。mediator被注入了meditorMap,可以实现新的视图中介器关联。
command即是控制器部分,负责处理特定的逻辑块。需要说明的是command被注入了commandMap、meditorMap、eventDispatcher,还有injector。这些对象提供了command更加广阔的能力,包括发送事件、映射新的命令关联、新的视图中介器关联。最后就是mvcs中的“s”,s即是service,提供获取外部数据的服务功能。本质上将robotlegs、pureMVC是一个东西,最大的区别是依赖注入、事件派发机制。
> 框架示意图
事件流参看Robotlegs官网: Go
> 运用与优缺分析
robotlegs的具体运用和pureMVC很像。继承context设计自己的context,完成数据模型、视图、命令体映射等工作。设计基于actor的数据模型,当模型属性改变时派发事件。完成视图组织对应的mediator,安装好视图事件处理句柄,和处理逻辑。设计完成特定处理的命令体。注意的是依赖注入是框架自己完成的,并且注入点可以使用接口。
robotlegs的优势可见一斑:轻量级的库、简单易用、极大降低耦合度。耦合度比pureMVC做的更彻底。并且依赖注入是可配置的。同时,我认为robotlegs的事件机制更高效,简单易懂,整个框架通过eventDispatcher对象进行收发。对于劣势可能是在于使用成本方面,由于引用依赖注入,框架要复杂很多。同时对于不需要开发大量视图交互的游戏,就没有这个优势了。http://www.shengshiyouxi.com
4 Ash
Ash是richardlord在2012设计的框架,借助这个框架richardlord开发了一个太空大战游戏,让我看到一个新的设计框架的诞生。实体系统现在正变得越来越受欢迎,有名的例子比如Unity。当然Ash现在很简陋,还不成熟,相信richardlord能做的更好!
> 框架机制:“实体系统结构来源于解决游戏主循环这个问题的一次尝试。它将游戏主循环作为整个游戏的核心,并且预先假设在现代游戏结构中,简化游戏主循环比其他任何方面都重要,比如,它比分离控制器上的视角重要的多”。这是这个框架的出发点,简化游戏主循环。在ash中,最终游戏的主循环控制完全通过迭代system的update方法实现。ash包括几个核心类:entity(实体)、component(组件)、node(节点)、system(系统)。entity对应任何游戏都是存在的,可以理解为游戏中一个用例,一个组成对象,比如太空飞船。component理解为entity的不同部分,飞船可以分为渲染、数据模型、碰撞检测、控制组件等。system可以理解为处理具体一组抽象的针对node节点的逻辑。node是为system服务的,因为一般来说系统不关注具体的entity,而是关注一组特定的节点。节点又是由特定的组件构成的。本质上讲node提供了特定或者抽象的entity的组件的访问。system通过处理特定的node,实现处理对应的entity的组件,而组件对应一个entity来说,是共享传递的,从而实现逻辑处理。
> 框架示意图
> 运用与优缺分析
Ash提供了Game类,使用时考虑给Game添加处理系统即可。一般会先划分不同entity,以及添加各自对应的component类。处理逻辑有先后顺序,决定了添加system到Game时有顺序安排,通过划分逻辑处理层次,将设计不同的system的扩展类,同时设计出配合system处理的node类。node类本质上是收集对entity的component的访问。整个游戏结构一目了然!