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对象进行收发。对于劣势可能是在于使用成本方面，由于引用依赖注入，框架要复杂很多。同时对于不需要开发大量视图交互的游戏，就没有这个优势了。 

       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的访问。整个游戏结构一目了然！