在本系列的第一篇文章（跨平台领域的淘金潮——为什么跨平台领域工具会改变现状）中，为大家介绍了跨平台工具产生的背景以及其粗略的介绍。
那么接下来，究竟选择Web App还是本机App，在众多的跨平台工具中又该何去何从？ 你也许能从本篇文章中得到你想要的答案。
一个跨平台工具由五部分组成，它们和app生命周期的五个阶段相对应，这五个阶段分别为开发阶段，集成阶段，发布阶段，部署阶段和管理阶段。
1.开发阶段：跨平台工具提供从低级到高级的各类开发语言，底层精简的语言比如LiveCode和Lua以及像HTML，CSS和JavaScript这样的web语言，中间层语言如Java、C#/.NET以及像C++这样的更底层的语言。
许多工具都提供可视化拖放环境，另外一些则只提供限制性的基于模板的app开发流程。一些工具只针对特定的开发人群，例如Impact JS和Lime JS Javascript 框架针对游戏开发者，而RhoMobile和Worklight则用于企业级开发。跨平台开发工具（CPTs）提供不同的语言来满足各类开发者的需求，无论你是脚本开发人员、经验丰富的web开发人员、有创造性的设计者还是核心软件开发人员。
开发阶段的核心部分包括集成开发环境（IDE）、仿真器以及调试器。Eclipse是当前最流行的开源IDE，作为跨平台的开发环境可以在PC、Mac以及Linux上使用。许多供应商在Eclipse之上提供额外的插件和仿真器。一些供应商会专门为企业级应用的开发人员和品牌设计人员提供免安装、基于web的开发环境。
开发阶段也包括源码控制，团队协作和工作流辅助工具。RhoMobile公司的 RhoHub开发平台使用Git套件进行源码管理和团队协作。Unity、Appcelerator、RunRev提供了一个组件交易市场，设计及开发人员可以通过此交易市场出售自己的组件，旨在利用这些现成的组件帮助他人缩短开发周期。Sencha在2011年11月也提供类似的组件出售市场，而Corana和Marmalade则分别推出了模板库和代码社区服务。
2.集成阶段：本阶段是有关如何与本地设备功能、云服务APIs及企业数据库进行集成的。
为了集成本地设备功能，通常的做法是使用JavaScript以及PhoneGap APIs和库，这些捆绑集成在一个称为混合-本地（hybrid-native）的应用程序中。Worklight、AppMobi、Feedhenry和BKrender在他们提供的工具中也包含PhoneGap功能。MoSync和Qt使用类似的方法，将本地APIs和平台无关的APIs抽象集合封装在一起。
开发者使用像JavaScript、Lua、LiveCode或者C++这样的编程语言提供的APIs，来与本地设备功能集成在一起。不同目标平台上功能相似的函数共享相同的工具级别API，这些API在业务逻辑层面上提供更高级别的代码复用，而在UI和特定硬件特性的支持方面的复用程度就没有那么充足。 例如，Mono Touch和Mono for Andriod就没有共享相同的UI APIs，所有与设备特性有关的APIs在不同设备上面的表现也不尽相同。Apps能够在运行时调用设备功能，调用要么在编译期被解释，要么通过运行时提供的桥接功能传递给底层平台。
集成阶段另一个主要部分是要连接到cloud APIs。Cloud APIs正在逐渐变成一个属于自己的细分市场。对于开发者来说，社交游戏网络显得越来越重要，这里不仅仅指Facebook或者LinkedIn。Apple Game Center、OpenFeint、Scoreloop、Skiller，Papaya Mobile和Swarm都为社交游戏提供基于云的APIs。
社交游戏APIs仅仅是其中的冰山一角。包括Bango、Social Gold和Paythru在内有超过14家供应商提供应用程序内计费以及虚拟物品交易平台。有超过27个像App Annie、Distimo和Flurry这样的销售分析工具。有超过8个像Bugsense和Testflight这样的app测试工具。VisionMobile的Atlas服务有这些提供商的详细列表。当然，这其中不乏合并的迹象。举个特殊例子来讲，Appcelerator虽然有自己的分析和货币平台，但还是通过收购Cocoafish来集成社交共享和消息推送功能。
针对企业级（B2B）开发者使用的应用平台通常会提供数据库连接管理服务。RhoMobile推出RhoConnect移动app集成服务，当后台有更新时该服务将更新推送给设备以实现数据同步。Antenna、Feedhenry和Worklight推出的跨平台工具（CPT）提供类似功能的集成中间件。其他专注于企业级应用程序开发的著名跨平台工具有Stackmob，Oracle（ADF），Aperra和Sybase（Unwired Plaform）等。
3.构建阶段：跨平台的“魔力”通常体现在构建阶段。构建应用程序有许多不同的方法。两种流行的方法：一种是将代码和UI模板直接编译成本地平台二进制码；另一种是将代码打包进本地shell然后在运行时解释执行，这种本地shell可以是一个只包含该代码的“简易浏览器”，也可以是设备自带的浏览器渲染引擎。下一章节我们将讨论构建跨平台apps的技术方法。
4.发布阶段：发布应用包含将app提交到Apple App Store或者Andriod Market这样的App Store，或者是内部发布并且可以选择是否将app托管到像Feedhenry，Antanna，RhoMobile或者Worklight这样的私有企业App Store。包括Sencha2.0，AppMobi的PhoneGap XDK和RhoMobile的RhoHub在内的许多跨平台工具（CPT）产品都在一定程度上协助管理app发布过程。包括Appcelerator LiveCode和Corona在内的一些提供商将在其网站上展示apps，而Unity则支持将app发布到其他平台上。
5.管理阶段：提供App管理功能是面向企业级的跨平台工具（CPTs）的特色，比如Worklight，RhoMobile，Antanna和Feedhenry。App管理包括消息推送，数据流管理，远程安装（卸载），策略管理和库存管理。商业Apps管理增加了业绩管理功能（即分析工具），该功能可以由工作方法商合作伙伴提供。例如Appcelerator就将自己的分析工具整合进Titanium，而Ansca Mobile将Flurry的分析APIs整合进自己的Corona SDK中。
#p#
跨平台工具（CPTs）的技术分类
在这份跨平台工具（CPTs）分析报告中，我们甄别出了五种不同的技术方法，即：JavaScript框架，app工厂，web-to-native框架，运行时以及源代码翻译。每种技术都针对特定的开发人群（从非技术人员到经验丰富的开发人员），并且可以满足不同的app用例。这些技术方法并不是相互孤立的，许多工具混合使用这些技术方法。例如一些基于运行时的跨平台开发工具（CPTs）解决方案都会增加一个网页视图组件，从而具有了创建混合web app 包装器的功能。
JavaScript frameworks：JavaScript框架由许多代码库组成，旨在加速复杂web任务（例如管理触摸屏交互，构架跨浏览器UI， 管理游戏画面等）的开发速度。主要提供商有jQuery Mobile，Sencha Touch， Cocos2D，DHTMLX Touch, Zepto JS, Impact.js, iUI以及Wink。JavaScript框架针对这样一类web开发人员，他们想要创建可触摸UIs，实现跨平台浏览器兼容，提供本地外观和感觉，或者是实现复杂的游戏功能。
App factories：App工厂是能够快速构建简单移动应用的开源可视化设计工具。它们由一个可安装或是基于云的开发环境构成，在此开发环境中开发人员可使用模板、拖拽、或者向导来生成app代码。利用App factories最简单的可以创建基于RSS的新闻阅读器或者经济型apps。在较高层面上，App factories提供基本的可拖拽设计功能。而在最高层面上，App factories提供无须编码的，基于组件的设计方法，包括与设备和云集成。
非开发人员也可以通过App factories创建他们自己的app。一些app工厂允许开发人员查看和修改自动生成的代码。其他的app工厂提供包括分析，消息推送和广告管理在内的一系列post-download服务。这些App工厂包括AppMkr，AppsGeyser，Wix Mobile，Tiggr，Mobile Nation HQ，Mobjectify，Red Foundry和Spot Specific。
Web-to-native wrappers：Web-to-native框架是使用web HTML5，CSS和JavaScript技术来生成本地apps的解决方案。web代码和其实现本地功能所需要的库文件被一起打包到本地app shell中。Apps使用web语言编写，能够访问设备上的webView组件（一种“chromeless”浏览器组件）以及JavaScript API扩展，JavaScript API扩展使得app能够使用通知、加速器、指南针、连接性、地理位置以及文件系统这样的平台功能，这些都是超乎浏览器通常所能提供的。
web-to-native框架主要有PhoneGap，Uxebu’s Apparat.io以及Sencha v2，Sencha v2还将这种包装功能引进到JavaScript框架中来。另外一个例子就是MoSync Wormhole，它可以提供比PhoneGap更强大的API功能集。web-to-native框架针对这样一类web开发人员，他们需要将web apps转换为本地apps并通过app商店进行分销、访问本地设备功能或者做一些优化工作。
Runtimes：运行时是本地操作系统之上的一种执行环境以及跨平台兼容层。运行时从本质上来说屏蔽了app在不同底层平台上的差异。不同的运行时有不同的大小和复杂性，并且使用不同的方法在设备上面执行代码，例如虚拟化，解释，及时编译或者提前编译。
Java ME，BREW，Flash Lite和Openwave MIDAS都是早期运行时的先驱。这些重量级的执行环境似乎介于浏览器和完整的操作系统之间。但这些工具在2009年前后就不再流行，原因是：开发者感觉很痛苦（平台分散、无直接市场渠道）；缺乏手机制造商的合作（集成复杂度）；与Aandriod、iOS、HTML5浏览器的竞争。
现在的跨平台运行时将设备软件层的复杂性转移到了设计阶段的开发工具中来。通常来讲，跨平台翻译部分发生在设计阶段（翻译成进制代码），部分发生在运行时（执行进制代码）。流行的运行时有Appcelerator，Adobe Flex，Corona，AppMobi，Antix和Unity等。运行时针对这样一些软件开发人员，他们需要更宽泛的跨（本地）平台或者跨屏幕（手机，电脑，游戏，电视等）功能。
Source code translators：源代码翻译器解决方案将源码交叉编译成中间字节码，本地语言（如C++，Objective-C，JavaScript）或者直接转化为更低级的机器码（如汇编语言）。源代码翻译器通常和运行时元素结合在一起使用。
举个例子来说，Metismo（现在的AG软件）将J2ME应用程序转换为C++，ActionScript和JavaScript，然后编译成能在ARM，MIPS，PowerPC和x86设备上执行的代码。类似的，Eqela将一个使用类C语言编写的app翻译成目标平台可运行的中间码，例如在web浏览器上执行的JavaScript，Java，C或者汇编语言。
Haxe/NME结合本地标准库把类似ActionScript的Haxe(具有类似Flash的API)源代码转换成Shockwave或C++代码。XMLVM使用Java，.NET或者Ruby源码，这些源码先被编译成字节码，然后再交叉编译成JavaScript，C++或者Objective C。其他的源代码翻译工具有MoSync，Marmalade和Xamarin’s Mono。这些翻译工具针对的是高级软件开发人员，他们需要创建逻辑复杂、性能优越的跨平台apps或者需要对app进行优化。
#p#
跨平台工具垂直发展
除以上五种技术手段外，跨平台工具提供商已经开始垂直分化，根据企业，游戏，媒体应用开发者的不同需求，为他们提供不同的解决方案。
企业级应用平台是跨平台的开发工具，它支持应用的整个生命周期（开发->集成->发布->管理），它具有数据连接器、中间件、云服务（如：应用托管、策略管理、信息推送等）。很多这样的平台是面向企业的，而不是面向消费者的应用。比较著名的移动应用开发平台有：Worklight, Kony, Antenna Mobility Platform, Application Craft, RhoMobile 以及Verivo等。
游戏开发工具是专门针对游戏开发者的完整的开发环境。游戏引擎是更为重量级的运行时组件；通常是由低级语言（如：C++语言）与用于编写游戏逻辑部分的脚本语言（如：Lua语言）相结合。Unreal 和Unity在高端3D游戏市场完全处于领先地位。他们提供了一系列的集成开发工具、工作流及协作管理工具。在类似的游戏工具市场上，还有Moai, SiO2, Antix 和 Shiva3D等。虽然Marmalade 和 Corona支持更多的功能（如：支持本机UI元素），但是它们毕竟还是由一个旧版的游戏引擎发展而来的。也有一些像GameSalad这样的稍微轻量级的游戏工具，GameSalad被称为“游戏缔造者”，它将app工厂提供的无须编码方法和游戏引擎工具结合在一起。像Impact JS 和 Lime JS 这样的轻量级JavaScript库被认为是HTML5的游戏框架。
The next table lists over 50 cross-platform tools by technology approach, authoring language and deployment format (web vs. native).
下表列出了50多种跨平台工具，从技术方法、开发语言及部署格式方面（网络或本机）进行了展示。
跨平台工具总表：我们的研究所关注的100种跨平台工具总表如下。
#p#
部署格式：Web还是本机？
是用web浏览器来部署移动应用程序还是创建本机应用？这是令许多开发人员长期困扰的问题。Web apps 具有广阔的市场前景，但只能在网络上部署，并且相对于本地apps的用户体验也不是那么好，本地apps具有更好的设备集成度并提供更优秀的用户体验，但是不能跨平台，其潜在市场只能限定于特定平台内。
使用跨平台工具可使这些区别模糊不清，Web程序员可以通过工具（如著名的Appcelerator）来开发本机应用程序。Web开发者可以使用诸如PhoneGap这样的Web-to-native框架在浏览器中动态调用本机设备的功能。
但是本机与web问题在部署时还是存在的。无论是web app还是本机应用，在分销渠道（网站或应用程序商店）和经验积累（肤浅或深入）上都会有很大的不同。
HTML5的确增强了web浏览器的功能，例如：允许精确的可视化布局（画布元素）和对视频、持久存储、地理定位、访问联系人名单、传感器和SQL数据库访问的固有支持。同时，由于各浏览器实现HTML规范的方式是不同的，web程序员必须对由此带来的巨大差异进行处理。在所有的移动浏览器当中，遵循HTML5规范方面做得最好的是Firefox Mobile，获得了最高分10分，紧随其后的是苹果的iOS5平台。与之相对的另一极端是Windows Phone7.5浏览器，它对HTML5规范的遵循程度大约只有苹果的一半。桌面浏览器和电视浏览器在对HTML5规范的遵循程度方面，也存在同样的多样化和两极化现象。上面的图表是移动平台对HTML5浏览器规范的遵循程度的得分情况。
这种“遵约分化”现象导致的后果是：web应用开发者为了使他们的应用能在各主流智能手机平台上实现最优运行，他们需要耗费大量的开发时间以及昂贵的成本。最典型的例子是“金融时报”广受欢迎的HTML5应用的开发商Assanka，该公司花了24人月来开发iPad平台上的HTML5应用—新闻阅读器（news reader），又花了12个月把这一应用移植到Android平台。
Web Hybrid apps弥补不足
开发人员应该选择web还是本地apps? 混合app方法致力于结合web和本地apps两者的优点。像PhoneGap，BKRender，Sencha v2， Worklight和Appcelerator等许多跨平台工具已经可以进行混合apps开发。
从用户的观点来看，混合apps跟本地apps很相似，人们可以通过本地平台app stores来寻找下载混合apps，同时使用相似的过程来安装混合apps。安装完成之后，混合apps可以从iOS这样的主屏幕或者从Android这样的app抽屉(drawer)中启动，并且经常可以在不需要数据连接的情况下正常运行。
从开发人员的角度来讲，开发混合apps和开发本地apps的工作流很相似，只有一点不同的是，开发人员可以使用HTML，CSS和JavaScript来编写混合apps的某些部分。由于混合app开发模型在所有主流移动平台上得到支持，使得不同平台版本的app可以复用HTML，CSS和JavaScript代码。
混合apps由一个包含HTML，CSS和JavaScript的本地代码shell（或者说是一个包装器）组成。当一个混合app运行在一台设备上，该包装器就会启动一个web视图的实例，同时加载其中的HTML，CSS和JavaScript代码。该web视图实例通常是“chromeless”，即它没有web浏览器控件，因此使得混合app看起来类似一个本地app。
下面的表格从技术和商业角度比较了本地，混合以及web app方法的异同。就像表格所显示地那样，混合apps将本地apps的特性和pure web apps的特性结合了起来。
容易发现和获取：用户可以像找本地apps一样找到他们需要的混合apps。为了支持多个移动平台的用户，需要开发不同版本的app。
更好的用户体验：混合apps提供良好的用户体验。他们允许HTML代码访问本地APIs（以此来提供更丰富的用户体验），当然这是以非本地UI为代价的，因为这涉及到web技术。
用户所有权和条款：就用户所有权和条款来讲，混合apps和本地apps完全一样。开发人员通过本地平台app stores来和客户进行交易，并且必须遵守app store强加的包括准许政策在内的各种条款和约束。
迎合用户：由于混合apps安装在设备上，并且显示在主屏幕或者app抽屉上面，他们在留住用户和重复使用方面和本地apps是完全一样的。用户可以像启动（launch）本地apps一样来启动混合apps，而不用去记住任何URLs，或者像pure web apps一样在主屏幕上显式生成一个捷径。
盈利模式：混合apps的开发者可以和本地apps开发者一样通过相同的方式盈利，这里面包括下载后付款或者应用程序内支付。
最后，对于一些UI信息丰富的app,混合apps允许显著的UI资源共享并且易于web开发。然而就像上面图表显示的那样, 在不同的移动平台上web浏览器的实现都千差万别。结果，充分使用web浏览器功能的高级apps需要自适应来完全支持不同平台的移动浏览器。
我该使用哪个工具？
我们追踪调查过超过100个跨平台开发工具，他们都各不相同。如果避开他们支持的编程语言和目标平台不谈，我们可以发现使用跨平台开发工具开发的app有一些收敛的类别（a convergence in the categories of apps）。开发者调查报告显示，如果不考虑主要的开发工具的话，35%的调查对象认为企业级apps是其首选。生产力，游戏，教育/参考和实用工具排名前五。
与此同时，这些开发工具不能被化为到具体的app类别中来，当然开发人员在决定使用哪个跨平台工具之前，应该考虑他们的应用背景以及需要。下面这个表格提供了一些指导意见。
原文链接：http://www.webapptrend.com/2012/05/2952.html
【编辑推荐】
