Adobe®Flash® Builder™ 4.5 新特性 – 对 PHP、Java 和 .NET 开发人员的影响

引言

移动应用市场正在改变软件开发行业的面貌。所有主要的移动操作系统制造商都在向开发人员推销他们的系统，试图让他们加入自己的开发阵营，从而巩固地盘以保证未来的增长。主要参与者及其各自的系统是：

• Apple (iOS)
• Google (Android)
• RIM (Blackberry/Playbook)
• Microsoft (Windows Phone)

每个操作系统都有其独特性；它对特定的编程语言有要求，并提供大量的 SDK、API 和各种增值服务。这些操作系统环境支持的编程语言是：

• iOS – Objective-C
• Android – Java
• Blackberry/Playbook – Java/ActionScript
• Windows Phone – C#/VB.NET（或任何可编译到 CLR 的语言）

当您设定目标要在所有设备上开发应用程序，无论其运行何种操作系统，这种多样性都会迅速变成一场噩梦。用三四种不同的语言重写应用程序的想法并不吸引人，而 Java 在 20 世纪 90 年代提出的“一次开发，到处运行”的承诺仍然像以往一样及时。有人可能会争辩说 Java 是这种愿景的一个很好的实现。确实如此，但不是在客户端。在移动设备上情况会有所不同吗？

Adobe 正在致力于向我们所有人证明这一点。请欢迎 Adobe Flash Builder 4.5，一个基于 Eclipse 的 IDE，它能够实现（除其他功能外）针对 Android、Blackberry Playbook 和 iOS 设备进行单源移动应用程序开发。

文章概述

本文概述了 Adobe 的新技术。重点关注使用 Flash Builder 进行快速跨平台开发的方面，并使移动应用程序开发人员能够更快地推向市场。文章特别关注使用 Flash Builder 开发的移动应用程序与 Java、.NET 和 PHP 服务器端环境之间的客户端-服务器集成主题。

如前所述，Flash Builder 是一个基于 Eclipse 的 IDE。大多数可用的 Eclipse 扩展，如源代码管理插件和调试工具，都可用于移动开发并直接适用。开发模型基于 ActionScript 语言，并使用 MXML 标记语言来表示用户界面布局和自定义组件。

优点和缺点

Flash Builder 4.5 新版本最大的优点之一是能够开发一个应用程序，然后在所有主要的移动设备上都能获得相同的显示效果。Flash Builder 具有预定义的平台目标设置，因此开发人员可以轻松选择目标平台进行构建。即使相同的应用程序可以部署到不同的移动环境，但了解平台和设备之间的差异也很重要。例如，即使在相同的目标环境（例如 Android）内，Motorola Droid 2 和 Google Nexus 也会有不同的显示规格。因此，应用程序需要了解其渲染方式的差异，或者应为目标设备/平台创建不同的应用程序“配置文件”。

另一个非常显著的优势是集成的所见即所得（WYSIWYG）UI 编辑器，它大大简化了用户界面的设计和布局过程。由于开发工作量的减少，这一定会成为跨平台移动开发的主要省时工具。

在权衡 Flash Builder 的优点时，了解其局限性也很重要。虽然 AIR SDK 支持许多本机 UI 组件，但主要的本机 Android 和 iOS 组件和服务尚未提供，因此，在整合至关重要的本机 UI 组件方面，AIR 平台可能会显得笨拙。作为一种变通方法，AIR SDK 支持自定义 UI 组件，因此应该可以模拟缺失的元素。

除了 UI 组件之外，移动应用程序还依赖于操作系统提供的各种服务。这些通常包括访问摄像头和麦克风、地理定位、蓝牙、通知服务、应用内支付等。不幸的是，并非所有核心 API 和服务都得到 AIR 的支持。在某些情况下，开发人员只有一种方法可以实现他们的目标，那就是开发一个运行在特定移动平台上的原生应用程序（或者根据他们想要支持的平台数量来多次重复造轮子）。在其他情况下，通过认真的风险评估，应该能够确定采用非原生、跨平台的方法是否是更好的选择。

客户端-服务器集成

除非您的目标是构建另一个“放屁”应用程序，否则您的应用程序很可能需要客户端-服务器集成。幸运的是，移动 AIR 提供了多种选择。客户端提供了 API 和支持：

• SOAP Web 服务
• 纯 HTTP GET/POST 请求和响应
• 基于套接字的连接
• 二进制（通过 HTTP）远程过程调用（AMF）
• 用于数据消息传递和媒体流传输的实时协议（RTMP）实现。 

使用这些方法的集成复杂度、性能和成本差异很大。通常，二进制通信机制（AMF/RTMP）通过提供更好的跨语言绑定和客户端与服务器环境之间的面向对象数据流，来实现更高的性能和更紧密的集成。

任何客户端-服务器集成都需要客户端和服务器都提供集成功能。从服务器端的角度来看，它可以像设置 Web 服务器来处理 HTTP 请求或部署 Web 服务堆栈来托管服务一样简单。其他集成技术可能需要一些额外的软件组件来实现集成。大多数后端环境都通过原生支持或第三方工具支持 AIR 中包含的集成技术。下表说明了集成兼容性矩阵。

前三种选项对于开发人员来说更熟悉和理解。对于不熟悉 Flash/Flex 的人来说，AMF 和 RTMP 选项可能比较新。AMF 协议和支持的 API 在概念上与 SOAP Web 服务非常相似。主要区别在于远程过程调用（RPC）数据在网络上传输的表示形式。运行在移动设备上的 AIR 客户端可以轻松调用远程方法并在对象级别接收结果。对象序列化和反序列化的所有复杂性都对开发人员隐藏了。RTMP 协议更适合数据消息传递场景，特别是需要发布/订阅功能的应用程序。此外，该协议支持从设备进行视频/音频流传输，以便后续广播以及在服务器端录制媒体流。如上表所示，AMF 和 RTMP 方法都需要服务器端的第三方解决方案。幸运的是，有很多选择可供选择。下表说明了可用选项。

对上述产品进行简要概述

• FluorineFX – 免费，开源
• WebORB for .NET – 免费（社区版），商业许可证（企业版）
• WebORB for Java - 免费（社区版），商业许可证（企业版）
• WebORB for PHP – 免费，开源
• Adobe BlazeDS – 免费，开源
• Adobe LCDS – 需要商业许可证
• ZendAMF – 免费，开源
• AMFPHP – 免费，开源
• Red5 – 免费，开源
• Wowza Media Server – 需要商业许可证

所有主要服务器端环境的多种选项为各种不同的业务场景提供了良好的选择。本文不深入分析选择合适的服务器端工具，因为它侧重于 Flex 对移动平台的价值，以及它与服务器端开发人员的关系。

使用 Flex/AIR SDK 构建移动应用程序的最大优势之一是客户端 API 的统一性和通用性。事实上，相同的 API 实现了所有支持的移动操作系统与各种服务器端环境之间的客户端-服务器集成。现成的 API 包括对以下用例的支持：

• 远程方法调用 – 可以通过至少三种不同的方法实现：使用 HttpService、WebService 或 RemoteObject 类。
• 使用 Producer/Consumer 类进行发布/订阅消息传递。
• 使用 NetConnection/NetStream 和 Camera 类从设备的摄像头进行视频广播。
• 使用与“视频广播”用例相同的类在服务器上录制设备摄像头的视频。
• 使用远程共享对象通过 SharedObject API 在并发连接的客户端之间交换数据。

这些 API 的具体应用示例将在以后的文章中介绍。然而，关键在于证明 Flex/AIR 可以成为许多“单源”移动开发策略的可行替代方案。