转:从“富客户端”(RIA)说到 Flex AIR

转:从“富客户端”(RIA)说到 Flex AIR
2011年06月17日
　　本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/zhangking/archive/2008/10/04/ 3013132.aspx
　　这年头，“不是我不明白，这世界变化快”。客户端一会儿“瘦”(thin)了，一会儿又“胖”(rich)了。
　　当初从单机应用程序发展到网络应用程序后，C/S架构的设计和开发应运而生。然而随着应用向互联网上迁移，客户端数量剧增，维护和升级成为一件极其困难的事情。这个时候，人们想到了要给客户端“瘦身”，就是把业务层逻辑交给服务器端来完成，客户端仅仅完成人机交互界面和用于呈现运算结果。于是 B/S 模式诞生了，客户端被浏览器所代替。
　　然而，随着开发和应用的发展，人们又发现：B/S 应用因为有 HTML、CSS 和 Javascript 的支撑，又有 Flash 动画助阵(最初还有 Java 的 Applet 等，后来败下阵来)，其界面虽然可以做得无比华丽，然而华而不实的东西实在太多，浏览器上的应用程序，其人机交互的感觉和效果怎么也比不上C/S类型的桌面应用程序。原因很明显，“B”和“C”之间隔着一朵巨大的网络“云”，连接它们的交换机和路由器，谁都不知道什么时候、什么原因就会减速甚至停止工作。更糟糕的是，进入B/S时代后，一直没有一款像 B/S 时代的 Delphi 们那样的全能开发工具。所有开发工具，要么专注于服务器端忽视客户端，例如 Java、VS.NET；要么相反，例如 Dreameweaver、Flash。像过去逻辑编写和界面制作可以用同一个工具几乎同时完成的情况，在B/S开发中几乎见不到了，B/S开发最终多了个“整合”的工作，就是把程序逻辑和界面脚本进行嵌套和融合，使它们能协同工作。好点的，例如 Struts 和 PHP 等，强调“模板”的概念，通过 MVC 框架把业务逻辑和界面完美隔离。差点的，例如最初 ASP 的开发形式，HTML、CSS、Javascript 代码和后台 VBScript 脚本交合在一起，完全是一种肉搏的状态。
　　“瘦客户端”还有一个致命的缺点，就是对服务器端造成的巨大压力和对客户端计算资源的浪费。本来可以在客户端完成的运算非要送到网络另一头去完成，网络带宽和服务器资源同时被额外消耗了。
　　于是，客户端的技术空白就有了发展的必要和商机。首先是 Ajax 在 Web2.0 时代的突围。Ajax 确实在改善浏览器用户体验方面出手不凡，表现卓越。有了 Ajax 技术，在与 Web 服务器进行少量数据交换时，浏览器不必出现一段时间的“休克”状态。特别是类似“网页聊天室”的应用，完全不用浏览器自己不停的刷呀刷呀的刷新自己。
　　然而 Ajax 的力量还太单薄了。为了改善浏览器 Web 前端界面的交互性和提高开发效率，一些基于 Javascript 脚本的开发框架诞生了，例如 Ext 和 JQuery、Prototype 等。我们完全可以继续采用 Javascript 原生代码去编写自己的代码，甚至发誓建造我们自己的代码库直至形成另一个框架式的东西，但这些现有的、成熟的前端框架无疑提高了我们的开发效率，至少我们不必再去考虑浏览器的兼容性。
　　在 Javascript 如火如荼的时候(“如火如荼”的例证就是2008年网页游戏莫名其妙的转热)，另一个Web前端技术-Flash的新东家 Adobe 自然不甘心坐失良机。Adobe 当初收买 Macromedia 的时候可能正是看中这一块了。Dreameweaver 看起来没有多少油水可粘了，因为许多人写 Html 就是用记事本一类的纯文本编辑器去搞。而 Flash 就不是谁随便就能写个工具就能在上边搞二次、三次开发的了，尽管 Flash 的 API 和 SDK 号称是公开的。事实上，现在我们见到的优秀的 Flash 开发工具也不多，有个 Swish 软件是用来快速制作 Flash 动画的，被盗版得不成样子。PHP 4.0以后，后台提供一个 ming.dll 库，提供 Flash 的后台生成，但似乎用的人也不多。
　　于是，Adobe 在收购 Macromedia 后，加快了研发“富客户端”(RIA)开发工具的步伐。
　　Flex系列产品包括编译工具和IDE(Flex Builder)，通过编写MXML（一种类XML标记语言）和ActionScript（AS，Flex的脚本语言，从Flash移植过来）代码，用编译器来生成SWF文件，使用浏览器的Flash Player插件就可以进行观看。
　　随着 Flex3.0 的推出，Flash Player 升级到 9.0 版本，并号称包含一个真正的“虚拟机”。ActionScript 发布了3.0版本，开发工具也升级到 Flex Builder3.0。
　　特别是为了支持真正的客户端应用开发，Adobe 开发了被人赞为“激动人心”的 AIR(Adobe Integrated Runtime)平台，中文释义为“Adobe运行时环境”。Adobe 官方的解释是：
　　AIR 是一个跨操作系统运行时, 可以使开发人员能够使用熟悉的 Web 技术 (包括 HTML、Ajax、Adobe Flash 和Adobe Flex)来构建桌面上的丰富的互联网应用程序。借助 Adobe AIR, 开发人员可以使用他们的现有技能和工具来构建引人入胜的、视觉效果丰富的应用程序, 这些应用程序将本地资源的强大功能与 Web 的触及力结合到一起。
　　很明显，不像 Flash 主要是作为网络应用运行在浏览器里，AIR 程序是类似“计算器”一样的桌面程序。而且更像 Java 桌面程序是运行在 java 虚拟机里一样，AIR 应用正是运行在 AIR 这个虚拟机平台上。AIR 程序跨操作系统操作、网络通信等低级服务都由 AIR 来代劳，于是 AIR 应用也号称“平台无关”。
　　但是 Adobe AIR - 现在正式版是1.1版本，最新测试版是 1.5版 - 现在的功能还十分有限，FB3.0 开发工具只提供了 6 个组件，这 6 个组件离开发一个强大的桌面应用差的还很远。现有的6个组件，能实现一些基本功能，但离“好用”的目标还有距离，例如那个文件系统的 Tree 控件就很丑陋 - 不仅仅是界面丑陋，功能也停留在 Windows 早期的水平上，根本不能模拟到当前 Windows 资源管理器的样式，在里面根本找不到“桌面”“我的电脑”等样式。模拟可能不是根本办法，将来需要能够引用 ActiveX 等 Windows COM 组件才是根本出路。但是对于“跨平台”的 AIR 来说，Linux、MAC 平台怎么办？如果每个操作系统、每个文件系统都搞一套组件，那代价何其大呀！
　　最后说说写这个命题的来由：本人最近经常上一些 SNS，最常去的就是“海内网”(http://www.hainei.com)。最近“海内”改版后，上传相片里多了一个“高级上传工具”，本人最初以为是用 Flex AIR 技术开发的，然后用 FB3.0 去模仿，结果发现 FB3.0 的 AIR 组件很差劲，网络上也搜不到类似的第三方组件。后来才发现海内用的是 ActiveX 组件“ImageUploader5.ocx”。看来直到现在，如果想在 Windows 下开发一些高级的应用(例如浏览器插件)，还是离不开 COM 组件技术，尽管现在“.NET”很流行。同时可以看到，Adobe 公司要实现自己的宏图大业，还有很长的路要走（别忘了微软基于.NET的Silverlight现在已经奋起直追了）。但 Flash 精致的动画界面、丰富的感官呈现与桌面程序的完美结合，还是很值得我们期待。
　　作者：张庆(网眼)
　　更多文章：http://blog.why100000.com
　　2008-10-3
　　本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/zhangking/archive/2008/10/04/ 3013132.aspx