【IT168 评论】ActionScript/MXML

　　其实就是说 Adobe Flash 平台不值得进入。2011 年，Flash 终于能够开发 iOS/Android 应用，再加上网页游戏市场火爆，估计很多人会想要进入这个平台。但我有不同的看法，列几点理由：

　　1、Adobe 是市场导向的，没有技术领袖气质。视频网站兴起后，Flash Player 的新版本就加强视频播放;网页游戏兴起后，新版本就加强图形渲染;移动设备开发兴起后，新版本就是能够运行在更多的平台上。一直在跟随，从来不能领导;选择 Flash 平台就意味着你永远都不能走在时代前缘，只能吃别人吃剩下的;选择 Flash 平台就意味着你最急切的需求无法满足，比如最近他们都在忙着支持移动设备，我们做网页游戏的希望他们加强实时性小数据包网络传输的需求就根本没有人理会。

　　2、HTML5 出来以后，Adobe 这个本来也没有多少技术人员的公司还分心去支持它，去把 swf 转为 html+js+css 工具，出图形化 html5+css3+js 编程的工具。它乐于革掉自己的命，因为它只是个卖工具的，支持 html5 就像是 photoshop 支持多一种图像格式;但是程序员你呢，你被革命后你的未来在哪里，见过当年的“中年下岗工人”不?

　　3、从 ActionScript 3 发布之后，这门语言基本上没有什么变化。你看从 Flash Player 9 发布 AS3 以来，连 C++、C 语言都出了新的标准，java/c# 这类有大公司支持的语言变化巨大，甚至 python 也出了 python 3，更别提 google 公司新出的 go 和 dart 两门优秀的语言。AS3 作为 ECMAScript 的一种方言，现在 ECMA-262 都发布到 5.1 版本了，它仍然没有想要跟进的样子。

　　4、Flex SDK 类库狗血地照抄了早期版本的 java 类库的设计，连缺陷也照抄不误。你有多少次为了截取 Array 的一部分元素而去看它的手册的?这也就算了，还有一堆的 bugs。你知不知道 Application.application 是会变的?

　　5、虚拟机方面，javascript 都有了 V8 引擎，而 AVM 还是那个 AVM，无数用户抱怨它慢都没有用的，优先级高的需求永远是更能够直接赚钱的特性。选择 Flash 就好像你是一个赛车手选了一辆小马力的车，虽然你弯道转得很好，也从不撞车，但可能一辆大马力的车还是从容地超越你。js 有了 V8 后开发出了 Node.js 从前端转到后端，拓展了更加广阔的应用领域，AS 在可以预见的未来，还是逃脱不了“写点小动画”的命运。

　　6、Stage 3D 不是救世主。不要忘记“low-level”这个定语，如果你直接使用 Stage 3D APIs 来编写程序，你知道那得多么痛苦。选择 A3D、Away3D 能够减轻一定的工作量，但使用开源引擎支持较差、特性较少。客观地说，写 3D 应用现在应该选择 Unity3D 或 Unrel Engine 3，反正它们也能编译成 swf 了。

　　7、2012 年，网页游戏的冬天不来，起码也是秋天。网页游戏的增长将会放缓，其实从 2011 年第四季度可以看到各大公司都开始压缩产品线，开始不再大量招工，而是转向消化之前已经招到的技术人员。在 2012 年，将会有更多的页游创业公司倒闭或转向移动设备游戏开发，AS 开发人员将会过剩，薪资下降。如果你在 2012 年上半年开始进入 AS 领域，那么下半年刚有所成的时候，就会遇到一大批刚下岗的竞争者，高薪梦肯定要落空。

　　8、移动设备应用或游戏开发在 2012 年还会受到资本的热捧，但 AS 在这个领域的竞争力我心存疑虑。Flash 优势就是跨平台，而 Unity3D 和 UDK 同样可以跨平台，同样可以使用脚本语言开发，而且性能、效果都更加优秀。随着 Unity3D 和 UDK 可以编译成 swf 在 Flash Player 上运行，学习 AS 的必要性进一步降低。

　　综上 8 点，可以看到没有技术基因的 Adobe 公司引导下的 Flash 开发路线图缺乏方向，前景模糊，再加上 ActionScript 和 Flex SDK 本身的缺陷，又遇上 Unity3D 和 UDK 这样的强劲外敌，再加上网页游戏大盘下滑，内忧外患之下，实在不是明智之选。Adobe Flash 当然不会死掉，也不会在 2012 年大量失去市场份额，但 Flash 程序员的 2012 不好过，想活得轻松点，注意距离。

　　线程

　　线程是指进程中的一个单一顺序的控制流，是操作系统能够调度的最小单位，一个进程中可以有多条线程，分别执行不同的任务。线程有内核线程和用户线程之分，但在本文中仅指内核线程。在软件开发中，使用线程有以下好处：

　　1、在多核或多路 CPU 的机器上多线程程序能够并发执行，提高运算速度;

　　2、把 I/O，人机交互等与密集运算部分分离，提升 I/O 吞吐量和增进用户体验。

　　线程的缺点也很明显：

　　1、创建一条线程需要较大的内存开销，导致不能创建海量的线程;

　　2、线程由操作系统调度(分配时间片)，线程切换的 CPU 成本比较高，导致大量线程存在时大量 CPU 资源消耗在线程切换上;

　　3、同一进程的多条线程共享全部系统资源，在多线程间共享资源需要进入加锁，大量的锁开销不提，重要的是加大了编写程序的复杂性，这一点你看看有多少书名含有“多线程”三个字就明白写个多线程应用有多难了;

　　4、I/O 方面，多线程帮助有限，以 TCP Socket Server 为例，如果每一个 client connection 由一条专属的线程服务，那么这个 server 可能并发量很难超过 1000。为了进一步解决并发带来的问题，现代服务器都使用 event-driven i/o 了。

　　event-driven i/o 解决了并发量的问题，但引入了“代码被回调函数分割得零零碎碎”的问题。特别是当 event-driven i/o 跟 multi-threading 结合在一起的时候，麻烦就倍增了。解决这个问题的办法就使用绿色线程，绿色线程可以在同一个进程中成千上万地存在，从而可以在异步 I/O 上封装出同步的 APIs，典型的就是用基于 greenlet + libevent 开发的 python 库 gevent。绿色线程的缺陷在于操作系统不知道它的存在，需要用户进行调度，也就无法利用到多核或多路 CPU 了。为了解决这个问题，很多大牛都做出了巨大的努力，并且成果斐然，scala、google go 和 rust 都较好地解决了问题，下文以 rust 的并发模型为例讲一下。

　　rust 提出一个 Task 的概念，Task 有一个入口函数，也有自己的栈，并拥有进程堆内存的一部分，为方便理解，你可以把它看作一条绿色线程。rust 进程可以创建成千上万个 Tasks，它们由内建的调度器进行调度，因为 Tasks 之间并不共享数据，只通过 channels/ports 通信，所以它们是可并行程度很高。rust 程序启动时会生成若干条(数量由 CPU 核数决定或运行时指定)线程，这些线程并行执行 Tasks，从而利用多个 CPU 核心。

　　如上图，rust 应用程序不停地 spawn 出一个又一个 Tasks，它们由 tasks 调度器管理，在适当的时机，调度器会把某一个 Task 分配给原生线程执行，如果这个 Task 进入 I/O 等待或主动让出 CPU(sleep)，那么这个 Task 会被交回给调度器，而相应的原生线程会执行另一个新分派的 Task。尽管使用 rust 编程语言是不能创建线程的(直接调用 C 函数不算)，但 rust 应用程序实际上是多线程的(一般情况下)，它能够充分地利用多核或多路 CPU。

　　综上，类似 rust 的 Task 的概念是比线程更好的并发模型，更安全，编写的代码也更加容易维护(关于维护性，我相信写过 gevent 程度或 go 程序的同学会认同的)。线程当然不会消亡，但随着 scala/go/rust 的成熟，在可以预见的将来，线程会退到它呆着的角落：远离普通程序员，只有少数人需要了解它的细节。

　　C++

　　C++ 在 2011 年其实风头甚劲，C++2011 标准出台，gcc/msvc/clang 都很快速地支持了许多新特性，新兴的移动设备的性能较差，更是 C++ 的新舞台，在这个时候唱衰 C++，压力很大。我使用 C++ 年头不少，但除了在校的时候写过两个小游戏参加过两个比赛(分别是面向社会和面向大学生的)弄些证书好找工作以外，在工作中只用过大概不到一年半，做《斩魂》(http://zh.163.com)的早期版本，写了服务器端的几条进程和客户端的 GameAI 部分。经验少，而且写得不好，所以基本上有人在 weibo 上问我 C++ 的问题，我都是转发给 @bnu_chenshou 和 @miloyip 等真正的行家去回答的。所以实际上今天写这一篇，我底气很是不足，但是朋友们给前两篇很大面子，弄得我骑虎难下，只好硬着头皮写了。

　　前文提到 C++ 的新标准，很有必要提一下标准化对 C++ 的影响。首先我们要肯定标准定制对 C++ 的积极作用，但标准化过程中的超长流程，一次次将 C++ 推向深渊。C++ 的第一个标准是 1998 年的 ISO/IEC 14882:1998，距离整个 90 年代最流行的 C++ 程序库 MFC(Microsoft Foundation Class Library)的第一个版本发行时间已经整整 6 年。1998 年，MFC 版本号为 6.0，与其一起发布的 Visual C++ 6.0 占有了巨大的市场。因为 MFC 发布得标准制定的时间早，所以 MFC 内部实现了许多后来标准库里也有的组件，比如各种数据结构容器。VC6 的市场占有率让 windows 平台下开发的许多 C++ 程序员甚至不知道有 STL，同时也无视 C++98 标准，从更兼容标准的 VC2002/2003 的市场占有率就可以看出来，直到今天，我知道国内不少公司还是只用 VC6 的。

　　其实在 90 年代，计算机的运算能力有限，市场上非常需要一款性能较高、抽象较强的编程语言，C++ 获得了成功，但它标准化的时间过长，造成各种编译器有各自互不兼容的“方言”，成了它的第一个软肋。第一个瞄准这个软肋的就是 java，java 在 1995 年推出，虽然性能稍逊，但它有更高的抽象能力、也更安全，并且更容易跨平台，所以迅速获得了成功;第二个瞄准这个软肋的是 C#，微软不能推动 C++ 发展，又不愿 C++ 的市场被 java 鲸吞，于是在 2001 年推出了 C#，经过 10 年的发展和微软大量的金钱推广，C# 已经成功获得了它应有的江湖地位。

　　虽然 java/c# 都不是善类，但 C++ 在 21 世纪的第一个十年里仍然地位稳固，这是因为 Linux 和 MacOS X 大获成功，在这两个平台上 C++ 都是非常有竞争力的编程语言，C++ 自然水涨船高。但随着 web2.0 和 web app 概念的兴起，以及 CPU 的主频进一步提升，服务器端编程语言渐渐地对执行效率不再敏感，而是更在意程序员的开发效率，众多的脚本语言开始蚕食 C++ 的市场份额，从早期的 perl 到后期的 python/php/ruby，在 2005 年以后，C++/java/C# 等静态类型的编译型语言的市场份额都下降了，新兴的贵族是动态语言。面对动态语言在开发效率上的强劲挑战，C++ 社区除了在 2003 年对 C++98 做了小小的 patch，基本上睡着了，完全没有应对之策，哦不，连应用的姿态都没有。

　　进入 21 世纪的第二个十年，市场又发生了变化，云计算越走越近，也许我们中的大部分人今天还可以说只闻其声不见其形，但 The Data Center Is the Computer 这句话大家应该觉得很务实：完成一个用户操作，在服务器端的进程间通信次数前所未有地多。在这个十年，我们需要这样的编程语言：

　　1、能充分利用现代 CPU 的计算能力，不仅仅是多个核心，更是巨大的 L1/L2/L3 Cache、超线程等;

　　2、能够大量减小异步 I/O 的性能提升的同时带来的副作用：异步编程的复杂性以及对可维护性的伤害;

　　两句话其实也可以压缩为一句：需要有更好的并发模型的语言。一开始大家都在已有的编程语言中寻找，然后找到了 erlang，实践证明 erlang 自有其局限，所以 google go/scala/rust 等新语言如同雨后春笋般拨地而出。C++2011 标准努力降低 C++ 的编程难度，并提供了线程库以支持现代 CPU，如果在 2005 年，这个标准绝对有竞争力，但在今天，它只能成为新的编程语言的垫脚石。正如 IE 最大的用处是用来下载其它浏览器，不久之后，也许会流行新的冷笑话：C++ 最大的用处就是用来实现其它编程语言。

　　市场一直在寻找一门中间的高级语言，它上承 C 语言和汇编语言，下启脚本语言。C++ 最先抢占了高地，并在与 java/c# 的争斗中不落下风，但新的十年，它的对手又增加了 google go/scala/rust 等新锐，并且新的标准不可能在两三年内再次出台，两三年内新锐成长起来后，留给它的位置就不多了。

　　上文讨论的基本上都是服务器编程，有必要再来看一下桌面和移动设备领域。首先看桌面软件，rust 是 mozilla 基金会开发系统程序语言的，它的定位是部分取代 C++ 开发 firefox 的浏览器，所以 rust 会进入桌面开发，google go 肯定会顺道啃一口。移动设备方面，主要是 android、ios 和 windows phone，随着移动设备性能增强，编译型语言加脚本的模式就会占大头，编译型语言方面主要是 C++ 和 Objective-C 在竞争，C++ 会占上风(但需求量远远小于脚本，从 lua 在 2011 年的增长速度可以印证)，但是谁知道 rust 之类的会不会进入移动设备呢，毕竟移动设备的 CPU 核心也越来越多了呀，C++ 还是前景堪忧。

　　回首 C++ 的 30 年，展望它的未来，总结起来可能就是：标准化流程拖死人了。如果不是 15 年不能标准化，java/c# 的搅局可能不会出现;如果在 2005 年能够应对动态语言……如果云时代有更好的并发模型……

　　题外话：java/c# 不会有 C++ 的问题，因为它们有自己的平台，有巨大的财富支撑。特别是平台的作用非常巨大，你可以想像一下如果 Adobe 有自己的浏览器或手机操作系统 ActionScript/MXML 会不会是今天的境地;也可以想像一下 google go 的飞速发展动力是什么。