引言

近年来随着移动设备类型的变多，操作系统的变多，用户需求的增加，对于每个项目启动前，大家都会考虑到的成本，团队成员，技术成熟度，时间，项目需求等一堆的因素。因此，开发App的方案已经变得越来越多了。曾经有一段HTML5的小浪潮，无数的人参与或者看到过一个讨论：原生开发还是混合开发，又或者是Web开发？到底最佳实践是怎样的，笔者认为只有实践过的人才会知道。尤其是在这个充满各种变数的移动互联网时代。

摘要

笔者将从混合应用的开发现状出发，阐述混合应用的优缺点，同时对比混合应用与本地应用的各自特性，最后探讨一下混合应用的新思想方向。

混合应用现状分析

Web App毫无疑问Web App就是成本最低，最快速地解决方案了。尤其是近两年非常流行的响应式设计，Web App市场提供了非常好的实践场地。最近典型的Web App最佳案例是Sun天气应用了，其细节处理让人赞不绝口。

一般来说，拥有下面特点的就是一个Web App了：使用浏览器运行；纯Web前端架构，很多重要手机特性无法访问，例如联系人以及Push notification之类的；Single Page App；销售渠道多限于浏览器。

混合应用

所谓的混合应用其实会有不同的分支。而且会和Native应用有重合的地方。下面就说三种不同的解决方案。

方案一：使用PhoneGap、AppCan之类的中间件，以WebView作为用户界面层，以Javascript作为基本逻辑，以及和中间件通讯，再由中间件访问底层API的方式，进行应用开发。这种架构一般会非常依赖WebView层的性能。

方案二：使用Adobe Air、RubyMotion、Appcelerator或者是Xamarin这种非官方语言的工具，打包成原生应用的方式开发。为什么笔者会将它们定义为混合应用，主要是它们并没有很单纯地使用原生提供的语言进行开发，而是通过对开发者提供友好的开发工具，并折中地把这种开发语言转换成原生语言，最终打包出整个应用，所以也属于混合应用范畴。

方案三：在开发原生应用的基础上，嵌入WebView但是整体的架构使用原生应用提供，一般这样的开发由Native开发人员和Web前端开发人员组成。Native开发人员会写好基本的架构以及API让Web开发人员开发界面以及大部分的渲染。保证到交互设计，以及开发都有一个比较折中的效果出来，优化得好也会有很棒的效果。（当年Facebook Three20就使用该方案）

因此，混合应用有以下的特性：

开发时可能不采用或者大部分不采用原生语言，但是却有所有原生应用的特性；
架构方案会和原生有出入，基本由工具而定；
具有跨平台特性；
一般开发相对原生开发的方式要简单。

本地应用

本地应用毫无疑问是最可靠的方案。但是学习成本，人才成本，开发效率以及照顾不同平台的特性去考虑，都成为了开发人员心目中的一道坎。至于说这道坎是不可逾越的还是一道让你提高的坎，笔者觉得完全取决于你自己。基于种种因素的考虑，估计很多人就会选择折中的方案到了混合应用的开发行列当中，包括笔者自己也是这样过来的。

下面更多的内容都将围绕混合应用开发展开讨论。

混合应用在开发当中的优点和缺点在混合应用的开发过程中，几种不同的方案笔者都有经历过。当然也经历到了Native App的开发阶段。在如此纠结复杂的过程中给了笔者不少的经验，下面笔者也会就自身的经验和大家分享这些方案当中的优缺点。对于初入行的朋友，笔者是从Web前端入行的，毕竟门槛较低，而且能够快速地培养自己的信心以及对代码的感觉。深入后就开始接触到移动开发这块了。所以会先从混合应用的第一种方案说起吧。

方案一（Web架构为重）

优点：

全Web开发，一定程度上有利于Web前端技术人员快速地构建页面样式；
有利于在不同的平台上面展示同一个交互层；
便于调试，开发的时候可以通过浏览器的方式进行调试，工具丰富。

缺点:

虽然说你可以专注在界面以及交互开发上了，但是这页会成为一个缺点，比如说要仿造一个iOS的默认设置界面，就需要大量的html以及css代码了，而且效果不一定和iPhone上面的界面一样好；
正因为这是跨平台的开发，所以还是这句话：兼容是前端的痛。了解过在Android机器上面的Web开发就知道这个痛了。比如前些年在Android设备上面写圆角，border-radius:10px，在Android的设备上面会出现毛边。
便于调试其实是在Web界面层的。但是实际上做混合应用开发的时候，你会遇到需求，进入手机的底层请求，做某些处理。比如说如果该应用有Push Notification服务的话，你就需要到底层，获取Push Notification发生时的数据，以及做相应的交互处理。当然类似PhoneGap这类框架，已经有很好的插件机制去帮助你解决类似的问题，当然还有Game Center之类的插件，具体的话可以到Github去关注PhoneGap官方的账户，资源非常丰富；

方案二（编译转换方式）

优点：

利用自己熟悉的语言，进行应用开发，比如RubyMotion，就是使用Ruby语言去做iOS开发，开发起来的话，代码量是数量级地下降啊。
部分开发工具提供跨平台的功能，让你的应用能够快速地发布到不同的平台上面。比如Mono社区的Xamarin，就是典型的例子了。使用C#语言，能够把你的应用发布到iOS，Android以及WinPhone市场上面；
开发出来的程序运行高效。大部分这种架构的应用，其实还是非常依赖底层的东西的，而且包括界面的东西，都是使用原生的API，效率就当然要比类似于PhoneGap这种架构要好了；

缺点：

严重依赖于其工具厂商提供的工具包，调试的时候就要有全套的工具。当然一般来说这些厂商都会以收费的形式发布他们的工具，相应的也有客服提供技术支持。遇到系统升级，第三方sdk升级，开发工具出现bug等，那么就要等待工具厂商解决了。相当于把风险压在对方身上了，自己却要承担责任。

方案三（Native架构为重）

优点：

这无疑是最稳定的混合应用开发方式了，交互层的效率上由Native的东西解决了，而且架构上基本就是在App内写网页，连App Store都是采用了该种方案；
开发时分工非常明确，底层的由iOS开发人员处理，上层的由Web前端开发人员处理；
有效的在线参数配置方式，以便于及时在线替换界面；

缺点：

团队至少需要两个工程师，一个是Web的，一个是iOS的。当然如果开发人员会两种技术也可独立承担；

还是运行效率，要权衡好多少界面采用Web来渲染，毕竟WebView的效率会相对降低，以前Facebook就是因为Web的渲染效率低下，把整个应用改为原生的解决方案。当然这里面可以通过优化来解决。但是优化也是有限度的，如Ruby创始人Matz所说优化要恰当（包括花的时间，技巧等），而且有时候的优化达到的回报率不一定达到你自己的期望。