前端开发者的跨平台移动应用开发策略及工具

愉悦的周五，早些回到家，冲澡吃饭照顾猫咪家务完毕已然超过九点的样子。登录博客后台，进入编辑页面，才觉得些许轻松安逸。不坏，一天里能有这么一会沉浸在这样的感觉里，足够了。

在之前的一篇文章中，我们曾经讨论过，对于交互和视觉设计相关职能的从业人员来说，从传统Web行业向移动应用领域转型的过程中需要学习和注意的问题。这篇文章中提到过“混合型应用”的概念，以及与之相关的两本开发指导书籍。今天这篇文章的英文原文，就是来自这两本书的作者——移动应用开发者Jonathan Stark。

本文中，他将站在传统Web前端开发人员的角度，为我们介绍一些在实际项目案例中总结出来的移动应用开发方法策略，以及几类具有代表性的用于打造跨平台移动应用的前端开发工具。

各位前端开发相关职能的同行们，扩展视野、提升技能、随“机”应变的时机已然成熟；衷心希望本文可以成为推动大家事业进步发展的一个催化点。不多说了，我们来看正文。

无论站在怎样的角度去衡量，移动互联网及客户端应用的发展势头都是非常迅猛的。日均使用量、智能手机的普及率、来自移动设备的订阅量、搜索引擎流量、广告呈现、应用售卖...所有这些都处于迅速上升的状态。可以预计，在不久的将来，移动设备将拥有足够的成熟度与普及率，并跻身于传统桌面电脑、笔记本等硬件平台的行列，成为我们日常生活的主要设备。

巨大的移动市场为传统Web设计开发人员带来了新的机遇与挑战。各类移动设备在爆发式增长的同时，也带来了前所未有的分裂与混乱的状况。如果需要同时为多平台设备进行客户端应用的开发、测试和维护，势必会消耗大量的资源与成本。

本文中，我们首先会对几种移动化解决方案进行比较和分析，然后将重点放在一些常见的用于跨平台移动应用开发的前端框架工具上；不过我不会在最后选出一个所谓的最优方案——开发方式的选择最终会取决于你的项目本身，包括业务模式、需求、目标市场、开发资源等多方面因素。本文的主要目标是提供一些有用的信息，帮助各位读者在实际项目中选择最合适的方法与工具。

Web应用 (Web App) 与原生客户端应用 (Native App)

关于这两种移动化方案孰优孰劣的辩论已然有不少了。

我相信，如果你能以Web应用的方式打造移动化产品，那么你确实应该这样做；反之则不应该...另外一种情况则介于两者之间，即通过HTML、CSS、JavaScript等前端技术，结合移动设备原生开发方式，打造所谓的混合型应用。

看似废话，但重点在于“能”或“不能”。这里我们主要指具体的项目需求，而非技术开发能力。我所在的团队，做过的多数案例，都来自于企业级的客户。大公司，顾名思义，在人员、产品及服务等方面都具有相当的规模，他们所需要的移动化解决方案在跨平台方面的需求都很高。

当接手一个新的企业级移动化项目时，我会将Web App作为默认的首选方式，同时结合以下三个问题进行进一步评估：

1. 功能方面，是否涉及那些只有本地应用才能利用的设备硬件资源？

比如，一款有条形码扫描功能的应用，必须配合设备的摄像头进行工作，而摄像头是浏览器无法获取的硬件资源，所以这款应用不能以Web App的形式存在；类似的功能还包括影像音频的录制传输、后台运行、消息推送等。如果该产品确实必须基于这些功能才能被正常使用，那么原生客户端应用便是不二之选。

2. 该产品的用户是谁？

如果产品拥有大规模的公众用户群，那么原生或Web应用的方式都是可选的，前者可以通过平台官方的App Store或应用市场进行推广，后者的跨平台性更好。如果产品属于公司或组织内部使用的管理信息系统等类型，那么Ad hoc、类似Apperian这样的第三方App Store或Web App都是可选的。

3. 该应用在系统资源消耗等方面的敏感度如何？

很多方面的因素会使移动设备浏览器占用过多的内存资源，从而影响Web App的执行效率及用户体验。这些因素包括半透明视觉效果及动画效果、大量的内容数据、文件加密和解码、基于地图的复杂交互方式等。

回答了这三个问题之后，对解决方案的选择便容易多了。举例说，比如我收到的需求是为企业员工设计开发一款B2E应用，用来管理他们的个人信息及收益情况，并且不需要使用移动设备提供的高级硬件功能，那么Web App的方式是最恰当的选择。另外一方面，如果需求是开发一款面向大众的虚拟地图应用，并需要配合手机的陀螺仪功能才可以工作，那么我们必须选择本地客户端的方式进行开发。

不过，正如我们之前提到的，在这两者之间，还有另外一种混血方案可以去考虑，也就是混合型客户端应用。

原生客户端应用 (Native App) 与混合型客户端应用 (Hybrid App)

所谓混合型应用，就是在原生客户端中嵌入基于前端技术构建的页面视图；这种方式其实已经很常见了。本质上讲，页面视图就是HTML页面，但它不需要另外调用移动设备中的浏览器进行查看和操作。

混合型应用的典型实例其实是我们非常熟悉的：iPhone、iPad等iOS设备的本地App Store或iTunes，以及Twitter和Facebook的客户端等。

在混合型应用中，原生的部分其实只相当于一个架子或容器，应用的核心是基于HTML、CSS、JavaScrit或前端框架打造的页面视图。页面的静态文件资源可以存储在服务器端，动态数据通过Ajax的方式在页面视图与移动应用中传输。

所以，虽然从技术上讲，混合型应用是设备本地化的，但它们显然拥有两种不同的运作方式。下面是两个很常见的问题，在需求评估时经常会遇到。

Q：如果我有技术及资源去开发一套纯粹的原生客户端应用，那么有什么必要使用HTML等Web前端开发方式去打造混合型应用呢？

A：混合性应用的解决方案最主要的目的是解决跨平台的问题；对于每个平台，只需开发和维护“容器”性质的本地应用部分，而实际的内容功能则可以统一由一套页面视图来担当。

Q：那么干脆只做一套Web App好了，为什么还要使用原生客户端作为容器呢？

A：这个问题的答案包括两方面：

1. 商业需求：对于很多客户案例来说，将应用通过App Store或Market推广出去，是一种商业方面的需求。比如，客户也许会希望自己的产品是付费应用，或者开发前的用户研究表明他们的用户多数是通过App Store安装本地客户端的。
2. 硬件功能需求：混合型应用的一个优势在于，虽然本地化的框架只是作为页面视图的容器，但它毕竟是本地化的，在需要的时候，仍可提供访问硬件设备及相关功能的权限；这是单一的Web App所无法做到的。技术方面，可以通过JavaScript经由本地应用框架，与硬件功能进行通讯，例如控制摄像头等。

我确信，通过这种需求梳理，多数人会倾向于混合型应用的方式。其实这也正是本文接下来的主线——我们一起来看看有哪些前端开发工具是可以帮助我们进行混合型应用的开发的。我将它们分为四大类，接下来会分别进行介绍，并对它们的适用情况进行简单的对比。

跨平台的前端开发工具

这是第一大类，主要包括一些在传统Web前端开发方面比较常见的JS框架。它们在混合型应用的页面视图中可以起到同样重要的作用。

jQuery

jQuery显然是最有群众基础的JS库之一，为各种常见的JS功能需求提供了统一的API，包括DOM操作、Ajax、事件绑定等。它通过了A、B、C全部三个级别浏览器(包括桌面与移动版本)的严格测试，拥有庞大的开发者社区以及优质的文档资源，并且是完全开源的。

凡事有利必有弊，jQuery在浏览器方面的优异表现，一定程度上取决于它包含了大量用于修正桌面浏览器兼容性问题的代码；对于移动应用方面的开发来说，这方面的代码是没什么意义的。这让jQuery看起来有些重了。

对我个人来说，如果需要开发一个传统的、主要用于桌面设备浏览的网站，那么jQuery会是我的主要选择。但是对于网站移动化方面的项目或是混合型应用的开发，我不会选择它。

Zepto

在移动化开发方面，作为一款更轻量的框架，Zepto是jQuery的一个不错的替代品。Zepto并没有被声明可以兼容旧浏览器，包括IE6等，同时，它在功能方面却几乎可以与jQuery媲美。如果你习惯于使用jQuery，那么你完全可以通过Zepto进行网站移动化或是混合型应用的开发。

XUI

作为一款轻量级JavaScript框架，XUI是特别为移动版本的浏览器打造的。XUI的侧重点是移动浏览器中最常见的功能需求，以最少的代码量实现最基本的功能。语法方面也很简单，不过与jQuery的风格有所区别，需要加以习惯。

Lawnchair

Lawnchair也是一款轻量级JS库，它最大的特色是，可以将客户端抽象为持久化的“无SQL”风格的数据存储空间。它采用适配器模式，支持多重回调机制。语法风格非常简单直白，支持简单的query查询。

在开发混合型应用或传统网站时，出于客户端持久化存储功能的需求，或是性能等方面的考虑，我会选择Lawnchair作为框架。

其他

可以辅助移动应用开发的JS框架还有不少，并且会时不时的冒出一些新的。值得一提的还有now.js、backbone.js和underscore.js等。

专门用于打造移动客户端的 JavaScript UI 框架

jQuery Mobile

某种程度上说，jQuery Mobile就相当于移动应用版本的jQuery UI；它是一个挂件库，用来将语义化的HTML标记语言转化成无论UI样式还是交互行为都更贴近移动设备原生风格的模式。

继承了jQuery的优点，jQuery Mobile对A、B、C三个等级的移动浏览器保持了全面兼容。它推出的时间不长，但目标很明确——为尽量多的移动浏览器打造用户体验最棒的移动应用。虽然略重了些，但jQuery Mobile绝对是打造移动应用的最佳框架之一。

jQTouch

与jQuery Mobile类似，jQTouch同样是一款将语义化HTML标记转化为移动设备原生风格页面视图的挂件库。这两者之间的区别是，jQTouch是特别为A级WebKit内核的移动浏览器打造的。这意味着jQTouch可以使用WebKit内核浏览器的专有功能渲染页面，相比于JM，所需的代码更少。所以，当我手头项目的目标用户多数为WebKit内核浏览器使用者的时候，我会选择jQTouch进行开发。

很快，jQTouch将支持Zepto，届时，jQuery就不再是打造页面视图本身功能的唯一选项了。这个改变将会有效的减小文件尺寸，降低运算处理时的系统资源开销。

Sencha Touch

Sencha Touch是一个基于ExtJS的全功能挂件库。与jQTouch相同，Sencha Touch也是面向A级WebKit内核的移动浏览器的。基于ST打造的移动应用具有很强的健壮性，在UI方面的自适应性也很出色，例如，在平板电脑中，页面视图会切换至大屏幕规格，包括结构和元素的布局等。

与jQuery Mobile或jQTouch不同的是，Sencha Touch不是基于HTML标记语言的，开发者必须采用客户端MVC风格直接书写JS代码，所以学习曲线略微陡峭。

Sencha Touch比较适合开发那些主要运行在WebKit内核移动浏览器里的中到大型的Web应用。

SproutCore

SproutCore同样是一款开源JS框架，最初的目的是帮助Web开发人员创建运行在桌面浏览器中的Web应用。实际上，它的功能太强大了，以至于苹果公司使用它来构建了最初版本的MobileMe.

不过，源于它桌面应用的初始需求，SproutCore在尺寸方面对于真正的移动化解决方案来说还是略大了些，至少我最后一次用到它的时候是这样的情况。

跨平台的本地应用开发工具

PhoneGap

PhoneGap可以将基于标准HTML、CSS和JS打造的页面视图封装为本地客户端应用，目前支持10种移动平台。在数据资源传输方面，可以采用普通Web App所使用的Ajax等方式。PhoneGap在页面视图与本地应用之间提供了一个桥梁，允许开发者通过JavaScript访问并使用移动设备的硬件功能，比如摄像头、联系人信息、麦克风等；这是单纯依靠移动浏览器运行的Web App类应用所无法实现的。

PhoneGap不属于挂件库，它也不会将HTML编译为原生客户端代码。通过PhoneGap封装的移动应用，只能在运行的过程中即时执行JavaScript，所以它无法像前面介绍的几种JS UI框架那样提供一套完整的移动化UI方案。但是PhoneGap的侧重点很显然是在本地化封装这方面；我开发过的每一个混合型应用都会用到PhoneGap。

Titanium Mobile

Titanium Mobile可以直接将JavaScript编译为iOS或Android平台的本地应用代码。开发者们经常将它与PhoneGap做比较，其实它们的机制是截然不同的。在Titanium中，开发者需要按照它规定的语法书写应用代码，而无法使用原生JS；从这个角度讲，Titanium与前面提到的的Sencha Touch类似。对于资深JS开发者来说，这种方式不会带来很大困难，而新手则需要学习和适应。

Corona

Corona是一款商业SDK，使用Lua构建。开发者可以通过Corona为iOS和Android两大平台开发原生UI效果真实饱满的移动应用。它拥有一个完整的图形和动画库，渲染引擎可以充分利用GPU的功能。这让Corana非常适合移动游戏的开发，不过它在普通移动应用开发方面的表现同样不错。

企业级移动应用开发平台 (Mobile Enterprise Application Platforms, MEAPs )

MEAP一种整合性的开发平台，通过一个后台，对跨平台移动应用的开发项目进行全周期的管理；涉及到的细节已经超出本文范围。之所以把这类放进来，是因为其中RhoMobile曾经被视为PhoneGap的竞争对手，但实际上它们根本不是一回事。典型的MEAPs平台有：

• Antenna Softwware
• Pyxis Mobile
• RhoMobile
• Sybase Unwired Platform(SUP)

总结

我个人从不会将Web应用与本地原生应用看作非此即彼的两个独立命题，它们更像是一个范围的两个极值。很多时候，要考虑的不是选择哪种方式的问题，而是要根据需求，评估基于HTML、CSS和JS打造的Web App页面视图部分与原生应用的比例问题。

使用前文提到的一些方法对需求进行评估，确认可以使用混合型应用的模式开发产品项目，接下来，我建议将目标放在对页面视图部分的比例控制上。根据产品的具体需求和设计情况，在保证不会对用户体验等方面起到负面影响的前提下，可以尽量多的使用基于HTML的前端页面视图，以增大跨平台功能的比例。你需要担心的跨平台方面的问题越少，用来打造优秀产品的精力及资源就相对越多。