我印象中的AS3 框架发展过程

1. 最早的单例式框架

          正如鲁迅所说 “世界上本来没有路，走的人多了，也就成了路”。AS3刚刚问世时，几乎所有公司的笔试题中都要问及单例模式。那个时候也就无所谓什么框架解耦的概念，小点的程序根本就没有框架和设计模式之类的概念，大一些的就是一堆单例之间互相调用。

 

2. MVC模式的局限性

       随着PC性能的不断提高和Flash技术的日益成熟，Flash不再局限于，功能逐渐复杂化、大型化，是简单的。连连看、俄罗斯方块之类的小游戏和电子相册之类的网站应用蹬上了历史舞台，甚至出现了Flash全站、社区之类的复杂交互和展示应用。当时的标志性口号叫做RIA（Rich Internet Application），这个词当年曾经红极一时，仿佛一夜之间进入了RIA的时代。

           但这种模式存在着一定的局限性，只适合做比较小型程序，一旦程序复杂，就会出现难以避免的问题。具体情况如下：

              1）.  View的刷新的Model中数据变更所导致的，而Model个体则是对具体程序角色属性的集中存储。

              2）.  复杂程序由多个Model和多个View组成，且一个View可能要关心多个Model中的不同数据项。

              3）.  一条程序逻辑（Command）可能需要改变若干个Model中的数据项。

             由于上述三个问题的普遍存在，一条程序逻辑可能造成几个View刷新几次，这样造成的结果就是：程序复杂度升高，逻辑分支混乱。程序可控性降低，Bug难于排查和定位等等。

           此外，MVC模式还出现了一些变种，由于大多数程序逻辑由I/O操作导致，因而越来越多的程序将Command中的逻辑封装到了View中，淡化Command的工作甚至弃用。

           随着人们对MVC模式认知的不断深入和成熟，以及MVC模式的固有缺陷，MVC框架应运而生。

3. MVC框架
           MVC模式的框架，最具代表性的就是Cairngorm 和PureMVC了。Cairngorm 是Adobe官方推出的AS3程序框架，较好的演习了MVC的设计模式，而PureMVC则是当时最为成熟，最为程序员认可的AS3框架。

        Cairngorm 官方Demo（两个三角形（也可以想象成两只小老鼠）进行追逐的那个Demo）侧重于在Command中实现逻辑，PureMVC则把重头戏放在View部分（消息通信中枢，即全局被观察者单例就位于View单例当中！），而且在它的程序结构图中还画出View模块下有许多UI子模块，这符合“尽量将子系统自身的细节和复杂性隐藏在子系统中”的封闭性原则，又叫闭包原则。

        把每条具体游戏行为写在Command中，便于重用。即：在任意地方想要执行某个逻辑，只需要发消息即可。但这会产生大量的冗余代码和工作量。不但不便于程序的调试和问题排查，而且想要知道所触发的这条逻辑何时完成，完成的结果如何以及是否是这段代码触发的，都变得困难，由此导致逻辑不可控。

            PureMVC侧重于将执行逻辑写在Mediator中，或一些闭包的逻辑直接在UI模块内部实现。PureMVC之所以比Cairngorm 更受追捧，是因为PureMVC已经有了向MVP方向转型的萌芽。虽然PureMVC也有Command这个类，不过一个明智的开发者是不会使用的。

          PureMVC和Cairngorm 开始时是单例核版本的，随后都推出了多核版，但对于如页游（WebGame）这样的大型交互应用，无论是在功能上，还是在性能上所产生的意义并不是很大。

4. MVP框架
          PureMVC和Cairngorm 虽然做到了程序模块化和解耦，但冗余代码过多等因素逐渐引发了开发者的不满。随后，各种框架如雨后春笋般频繁出现，有的侧重于轻量级和代码简洁，有的侧重于整合UI表单，有的则侧重于物理系统运动学等常用功能的封装，还有大而全的传统型代码库....。逐渐出现了百家争鸣的盛况，但可惜的是并没有出现一个能彻底替代PureMVC和Cairngorm的框架。

          就在这个时候，市场上出现了页游井喷潮，各大页游厂商成了AS3的重要舞台，他们的框架基本上都是由PureMVC或Cairngorm衍生出来的，每个公司的业务不同框架也就各有侧重。这个基本上都是每个公司的核心技术，本人的了解也就只有我工作过的几家公司了，不足以说明整个行业的情况了。

          由于智能手机的崛起等市场因素，作为技术顶峰的页游市场也江河日下市场份额不断缩小，后来AS3也是后劲不足，最终页没有自然孕育出一个非常经典的MVP框架，上图是我自己的MVP框架结构图。

5. 关于MVVM模式

         关于MVVM，早在Flex2.0（或更早）就引入MVVM模式，并且支持CSS。这种模式有其自身的有优点，如：

            1. 开发效率高，比MVC、MVP模式的开发效率都要高，几乎没有冗余代码，代码简洁，可读性高。

            2. 封闭性强，将数据直接写到View中，大大提高了封闭性从而代码可读性也大大提高了。

            3. 支持CSS，便于样式的复用，提高代码可读性。

         但是这种模式并不适合游戏等复杂逻辑应用，我认为有以下下几点理由：

             1. VM这种结构本身有一定的局限性。游戏中有许多数据都是公用的，而VM作为一个闭包，最优方案是将数据移入到View中，这样就难以两全其美,要么破坏VM的结构增加数据耦合性，要么就需要在代码逻辑中对同一数据的多份副本同时分别进行维护，这样势必造成架构上的缺陷和不足。

             2. 数据绑定的问题。数据绑定是可以绑定函数的，这样会多出来许多getter函数的调用，即便UI不需要刷新也会引发调用，并且重新给View赋值，即便数据还是和原来一模一样的，这个时候View是否刷新就不一定是应用层代码能控制的事情了。

            3. 游戏本身对性能要求较高，有些逻辑操作要求是惰性的。如果使用了数据绑定（如微信小程序），那么数据的绑定和解绑的可控性不那么强，什么时候解绑、什么时候清空View和Model之间的相互引用的清空并非全由创建者（具体模块开发人员）控制，给内存回收造成风险及内存泄漏。