其实写这篇博客的想法在年前已经有了，但一直在犹豫要不要写，一是因为写出来肯定会有人骂的了，刚过完春节的，在自己地头找骂，实在是晦气；二是因为我对 行业趋势的眼光向来不准，估计今天的想法也是十有八九会错，错了日后自己的看着也不爽。但是又觉得如果心里有想法，不记录下来，思绪就飘远了，年代久了之 后，都忘记自己曾经也有过“看法”，应该会为自己的庸碌后悔吧？所以还是写了。写了归写了，请各位看官往下读之前，先整理好心情，做到：一是自己对世界有 自己的看法；二是认同别人的看法可以跟自己不同；三是对别人的看法跟自己不同时不要生气因为气的是你自己别人替不了。如果做到了这三点，再往下读，因为下 文的观点会很偏激、很有态度，我欢迎你留言讨论、发表不同的见解，如果纯粹是谩骂（或有很多脏词），建议你自己开一篇博客或发到你的微博，不要评论本文， 因为我会删除“纯粹是谩骂（或有很多脏词）”的评论。
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_chenshuo 和 @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 的飞速发展动力是什么。
两点解释
1、 我觉得有必要解释“不宜进入”一下这四个字，我想要表达的意思就是如果你现在不是这三个技术点的专家，并且手上没有使用这三个技术点的项目，进入这三个技 术点仅为技术储备，那么就“不宜进入”。另外我不是说用了这三个技术点的项目就死，学了这三个技术点的人就找不到工作，或者这三个技术点明天或明年就 game over，渣都没得剩，不是这样的意思，它们还会存在很长一段时间。本文不是叫专家自废武功，也不是叫已经做好技术造型的项目赶紧儿换技术，举例说，如果 你选择了用 java 做服务器端，flash 做客户端开发一个 webgame，那你最好玩命儿地把 ActionScript/MXML 和 java 多线程编程（及异步 I/O）给钻透，不然可能随时掉陷阱里。
2、新年新气象，工作和家庭都有很重要的事情压在肩上，大家的评论我不逐条回复了，我会在一两个星期后再统一写一篇《2012 不宜进入的三个技术点（Q&A）》统一回答，还请见谅。
posted on 2012-02-04 23:19
todayx.org 阅读(189)
评论(0) 编辑 收藏