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

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

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

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

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

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

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

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

该应用在系统资源消耗等方面的敏感度如何？
很多方面的因素会使移动设备浏览器占用过多的内存资源，从而影响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：这个问题的答案包括两方面：

商业需求：对于很多客户案例来说，将应用通过App Store或Market推广出去，是一种商业方面的需求。比如，客户也许会希望自己的产品是付费应用，或者开发前的用户研究表明他们的用户多数是通过App Store安装本地客户端的。

硬件功能需求：混合型应用的一个优势在于，虽然本地化的框架只是作为页面视图的容器，但它毕竟是本地化的，在需要的时候，仍可提供访问硬件设备及相关功能 的权限；这是单一的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的前端页面视图，以增大跨平台功能的比例。你需要担心的 跨平台方面的问题越少，用来打造优秀产品的精力及资源就相对越多。

出处:http://www.20ju.com/content/V185296.htm