【引言】近年来随着移动设备类型的变多，操作系统的变多，用户需求的增加，对于每个项目启动前，大家都会考虑到的成本，团队成员，技术成熟度，时间，项目需求等一堆的因素。因此，开发App的方案已经变得越来越多了。曾经有一段HTML5的小浪潮，无数的人参与或者看到过一个讨论：原生开发还是混合开发，又或者是Web开发？到底最佳实践是怎样的，笔者认为只有实践过的人才会知道。尤其是在这个充满各种变数的移动互联网时代。
【摘要】笔者将从Hybrid App的开发现状出发，阐述Hybrid App的优缺点，同时对比Hybrid App与Native App的各自特性，最后探讨一下Hybrid App的新思想方向。
Hybrid App现状分析
Web App
毫无疑问Web App就是成本最低，最快速地解决方案了。尤其是近两年非常流行的响应式设计，Web App市场提供了非常好的实践场地。最近典型的Web App最佳案例是Sun天气应用了，其细节处理让人赞不绝口。
一般来说，拥有下面特点的就是一个Web App了：使用浏览器运行；纯Web前端架构，很多重要手机特性无法访问，例如联系人以及Push notification之类的；Single Page App；销售渠道多限于浏览器。
Hybrid App
所谓的Hybrid App其实会有不同的分支。而且会和Native应用有重合的地方。下面就说三种不同的解决方案。
方案一：使用PhoneGap、AppCan之类的中间件，以WebView作为用户界面层，以Javascript作为基本逻辑，以及和中间件通讯，再由中间件访问底层API的方式，进行应用开发。这种架构一般会非常依赖WebView层的性能。
方案二：使用Adobe Air、RubyMotion、Appcelerator或者是Xamarin这种非官方语言的工具，打包成原生应用的方式开发。为什么笔者会将它们定义为Hybrid App，主要是它们并没有很单纯地使用原生提供的语言进行开发，而是通过对开发者提供友好的开发工具，并折中地把这种开发语言转换成原生语言，最终打包出整个应用，所以也属于混合应用范畴。
方案三：在开发原生应用的基础上，嵌入WebView但是整体的架构使用原生应用提供，一般这样的开发由Native开发人员和Web前端开发人员组成。Native开发人员会写好基本的架构以及API让Web开发人员开发界面以及大部分的渲染。保证到交互设计，以及开发都有一个比较折中的效果出来，优化得好也会有很棒的效果。（当年Facebook Three20就使用该方案）
因此，Hybrid App有以下的特性：
- 开发时可能不采用或者大部分不采用原生语言，但是却有所有原生应用的特性；
- 架构方案会和原生有出入，基本由工具而定；
- 具有跨平台特性；
- 一般开发相对原生开发的方式要简单。
Native App
Native App毫无疑问是最可靠的方案。但是学习成本，人才成本，开发效率以及照顾不同平台的特性去考虑，都成为了开发人员心目中的一道坎。至于说这道坎是不可逾越的还是一道让你提高的坎，笔者觉得完全取决于你自己。基于种种因素的考虑，估计很多人就会选择折中的方案到了Hybrid App的开发行列当中，包括笔者自己也是这样过来的。
下面更多的内容都将围绕Hybrid App开发展开讨论。
Hybrid App在开发当中的优点和缺点
在Hybrid App的开发过程中，几种不同的方案笔者都有经历过。当然也经历到了Native App的开发阶段。在如此纠结复杂的过程中给了笔者不少的经验，下面笔者也会就自身的经验和大家分享这些方案当中的优缺点。对于初入行的朋友，笔者是从Web前端入行的，毕竟门槛较低，而且能够快速地培养自己的信心以及对代码的感觉。深入后就开始接触到移动开发这块了。所以会先从Hybrid App的第一种方案说起吧。
方案一（Web架构为重）
优点：
- 全Web开发，一定程度上有利于Web前端技术人员快速地构建页面样式；
- 有利于在不同的平台上面展示同一个交互层；
- 便于调试，开发的时候可以通过浏览器的方式进行调试，工具丰富。
缺点:
- 虽然说你可以专注在界面以及交互开发上了，但是这页会成为一个缺点，比如说要仿造一个iOS的默认设置界面，就需要大量的html以及css代码了，而且效果不一定和iPhone上面的界面一样好；
- 正因为这是跨平台的开发，所以还是这句话：兼容是前端的痛。了解过在Android机器上面的Web开发就知道这个痛了。比如前些年在Android设备上面写圆角，border-radius:10px，在Android的设备上面会出现毛边。
- 便于调试其实是在Web界面层的。但是实际上做Hybrid App开发的时候，你会遇到需求，进入手机的底层请求，做某些处理。比如说如果该应用有Push Notification服务的话，你就需要到底层，获取Push Notification发生时的数据，以及做相应的交互处理。当然类似PhoneGap这类框架，已经有很好的插件机制去帮助你解决类似的问题，当然还有Game Center之类的插件，具体的话可以到Github去关注PhoneGap官方的账户，资源非常丰富；
方案二（编译转换方式）
优点：
- 利用自己熟悉的语言，进行应用开发，比如RubyMotion，就是使用Ruby语言去做iOS开发，开发起来的话，代码量是数量级地下降啊。
- 部分开发工具提供跨平台的功能，让你的应用能够快速地发布到不同的平台上面。比如Mono社区的Xamarin，就是典型的例子了。使用C#语言，能够把你的应用发布到iOS，Android以及WinPhone市场上面；
- 开发出来的程序运行高效。大部分这种架构的应用，其实还是非常依赖底层的东西的，而且包括界面的东西，都是使用原生的API，效率就当然要比类似于PhoneGap这种架构要好了；
缺点：
严重依赖于其工具厂商提供的工具包，调试的时候就要有全套的工具。当然一般来说这些厂商都会以收费的形式发布他们的工具，相应的也有客服提供技术支持。遇到系统升级，第三方sdk升级，开发工具出现bug等，那么就要等待工具厂商解决了。相当于把风险压在对方身上了，自己却要承担责任。
方案三（Native架构为重）
优点：
- 这无疑是最稳定的Hybrid App开发方式了，交互层的效率上由Native的东西解决了，而且架构上基本就是在App内写网页，连App Store都是采用了该种方案；
- 开发时分工非常明确，底层的由iOS开发人员处理，上层的由Web前端开发人员处理；
- 有效的在线参数配置方式，以便于及时在线替换界面；
缺点：
- 团队至少需要两个工程师，一个是Web的，一个是iOS的。当然如果开发人员会两种技术也可独立承担；
- 还是运行效率，要权衡好多少界面采用Web来渲染，毕竟WebView的效率会相对降低，以前Facebook就是因为Web的渲染效率低下，把整个应用改为原生的解决方案。当然这里面可以通过优化来解决。但是优化也是有限度的，如Ruby创始人Matz所说优化要恰当（包括花的时间，技巧等），而且有时候的优化达到的回报率不一定达到你自己的期望。
Hybrid App和Native App开发对比
因为方案三中的思想基本上就是原生应用的开发思想了。这里要做的对比应该不算大，因此笔者不会做太多的阐述介绍两者的不同。但是如果是偏重Web架构的，或者是以方案二这种透过特殊工具开发的，就和原生开发有对比了。这次笔者暂时会以方案一拿来讨论。讨论中主要会以架构，代码管理上来讨论，当然也会说到部分细节。
架构讨论：
因为这是偏重于Web开发的应用，这里面就需要开发人员有很强烈的大型Web前端架构思想在里面。提到这里可能马上浮现在你脑海中的词语就是：angular.js，require.js，sea.js，backbone.js等。没错，这些工具都能够帮助你快速地梳理好思路，管理好你的Web应用。对开发者最友好的，发挥空间最大的非PhoneGap莫属了。所以笔者就会以PhoneGap应用展开讨论。（因为类似Sencha也有提供方案，但是Sencha本身是一个重量级的框架，而且有自己的思想在里头，加上他本身也提供开发工具，在这里就不适合讨论了。对于开发者来说可以根据自己的需求选择好工具）
从工具上看：
用于双向绑定，网络请求，视图管理等工作。
javascript模块化工具，在使用较多的交互对象，PhoneGap插件的时候，你就会发现一个强大的模块化工具会在开发的时候提供极好的帮助。能够帮助你把整体的代码，管理得井井有条。
模板引擎。笔者个人比较推荐使用Jade，而且笔者本人也在博客中多次写到Jade在不同场景下使用的技巧的有关文章。主要是jade的语法太简洁了，而且面向JS开发人员非常友好。如果你还没有开始使用模板引擎，赶紧加入这个队列吧，你已经落后了。
如果你暂时还没有一个设计师，但是又急于构造一个应用出来。jquery mobile就提供了多套不同风格的模板，供你使用，而且还含有不同的交互动画等。而且也是跨平台的。当然实际场景中，笔者觉得你会花很多时间在写css上面，因为设计总是天马行空的。当然你还有很多工具啦，例如sass，以及less.js等。
PhoneGap.js或者Cordova.js
做Phonegap开发必须使用的代码库，用于和PhoneGap框架通讯。现在这个库已经改名了，是Cordova。具体为什么改名，得问Adobe咯。
PhoneGap的插件能够帮助你快速地抵达手机的其他API上面，直接使用Javascript来操控这些底层的API。例如调用Push Notification的相应发生的事件。
从代码目录上面看混合应用中的Web层：
/js
mainView.js
settingView.js
networkObject.js
renderObject.js /lib
/PhoneGapPlugins
push-notification-plugin.js
pickerView.js
PhoneGap.js
zepto.js
jquerymobile.js
iscroll.js
angular.js
jade.js /css
/mainView
listItemTemplate.css
questionListTemplate.css
/settingView
/personView
/layout
navigationBar.css
tabButton.css
app.css /template
/mainView
listItemTemplate.txt
questionListTemplate.txt
/settingView
/personView
/layout
navigationBarTemplate.txt
tabButtonTemplate.txt index.html
app.js
require.js
从代码的目录上面看，就是经典的静态网页文件的目录，非常简单。下面就用一句话来说说整个应用的运作过程吧：
打开PhoneGap应用 ->进入 index.html ->运行require.js ->加载应用资源 -> app.js 控制整个应用 -> angular.js 进行事件绑定以及视图渲染 ->视图渲染的时候会将数据和加载好的视图模板（template目录下的代码）处理 ->经过jade模板引擎 ->渲染到相应的位置上
就是如此简单。
看完了简单的PhoneGap应用后，笔者们来看看简单iOS应用在开发时候的代码目录吧。思路上还是非常相似的。在这里面，笔者不会深入代码部分去讨论具体的实现以及细节上的东西。
demoApp
/Resource
navigationBar.png
navigationBar@2x.png
/demoApp
AppDelegate.h
AppDelegate.m
/SettingViewController
settingViewController.h
settingViewController.m
/MainViewController
mainViewController.h
mainViewController.m
/Supporting Files
demoApp-Info.plist
InfoPlist.strings
...
/plugin
/AFNetworking
AFHTTPClient.h
AFHTTPClient.m
AFHTTPRequestOperation.h
AFHTTPRequestOperation.m
...
/Frameworks
CoreData.framework
UIKit.framework
/Products
demoApp.app
Objective-C 是一种通用、高级、面向对象的编程语言。Objective-C是承自Smalltalk的信息传递模型（message passing）。Objective-C里，与其说对象互相调用方法，不如说对象之间互相传递信息更为精确。Objective-C强调面对对象编程，且Objective-C中强制要求将类的（interface）与实现（implementation）分为两个部分。类的定义文件遵循C语言之惯例以 .h 为后缀，实现文件以 .m 为后缀。所以你会看到大量的类文件在里头，整个工程就是有不同的类构成的。（当然可能这么描述不太准确，但是便于大家理解）
这就和丰富的Web前端有很大区别了，在Web前端开发里有HTML，CSS，JS三剑客，必须要用好这三个东西才可以把整个应用才可构建出来。但是在Native应用中，就很单一了。你只需要把握好Objective-C就可以了。因此对于原生应用来说，开发时只要遵守好规范，即使是一个新手参与开发，也可以快速地上手，看懂代码。因为模式已经定好，大家使用同一套的API。按着流程走就好了。当然学习Objective-C需要过程，但是对于拥有C语言，Java语言经验的开发者来说，是非常简单的事情。
当然，原生开发的缺点也很明显了，就是满足不了你的跨平台需求。
从代码目录上面看，其实也基本上看到笔者为什么使用多种JS库以及框架的原因了。主要的目的就是为了构建一个可维护的，具有规范性的Web应用。因为本身Javascript这门语言非常灵活，100个人可以具有100种风格，加上没有专门对于Javascript开设的课程，在过往都容易存在对这门语言的误解。基于种种的原因，就要约束好一个应用的代码风格，架构。此外，Javascript本身没有类的概念，所以在Javascript的面向对象编程中：Javascript的数据和成员封装很简单。没有类，完全是对象操作。这和Objective-C有很大不同。这个时候必须要有一种心态处理好整个Web应用：就是尽可能地抽象成对象，你的工作就是对象与对象之间存在交流。
另外有一些点是值得开发者注意的。对于原生应用来说，不管是iOS的，还是Android的，都会提供一套原生界面的库。以Objective-C为例子。如果笔者需要调用Alert，笔者只需要编写：UIAlertView * alertView = [[UIAlertViewalloc]init];，就把这个view声明好了。再去执行相应的方法，就可以了。但是对于Web应用来说，就需要编写<div id='alertView'><button>确定</button></div><script>$('#alertView').show();</script>
，一堆的css代码和html代码去实现。当然你会询问笔者，直接写 alert() 不就可以了吗？要是真这么简单的话，建议你在iOS的WebView中编写一下alert，实现：title 是提示，内容是：alert view，确定按钮的文字是：好的。你就知道WebView的限制在哪里了。
因此要完成JS在Web App开发当中的最佳实践，肯定要学习优秀的思想和实现方法了。在这篇文章里面，笔者们暂时先不去做这种深入的讨论。而是先把例子抛给大家，也许会在下一次讨论的时候，再详细深入以下这两个项目。
第一个是斯坦福的iOS开发公开课中的例子，使用objective-c实现，一个简单的卡牌游戏。这是经典的mvc开发了。项目地址如下：https://github.com/lbj96347/Stanford-W2013-CardGame，如果您正在使用Mac，那恭喜你，可以马上编译这个游戏进行测试以及代码浏览。
第二个是使用JavaScript编写的例子，实现同样的需求，做一个简单的卡牌游戏。但是使用的是HTML+CSS+JS开发。同样学习了继承以及mvc的思想。项目地址是：https://github.com/lbj96347/JSMatchismo ，再次恭喜你，不管使用什么电脑，都可以随时浏览代码以及运行该游戏。
Hybrid App的新思想
这两年多以来，因为市场的不同，也出现了不一样的需求，各个技术都有了新的发展。对于Hybrid App来说，其实都有了一些新的解决方案。为了解决问题其实最终思想都会被还原成以下几个点上：
- 根据需求，选择工具；
- 用适当的工具做适当的事情，有针对性地解决问题；
- 世界是平衡的，对于开发者来说，做的有用功越多，用户体验就越好，反之越差；
- 跨平台是一个"幌子"，什么都做得到不代表什么都做得好
这也是笔者体验最深的几个点。而且你会发现Hybrid技术也基本在跟随这几个点来走。
根据需求，选择工具
如果你使用过Jquery Mobile，你做过过场动画（就是从一个view去到另一个view），过场动画在iOS的navigationController中很常见，而且很简单，效果很好很流畅。在Jquery Mobile中使用ajax，css去实现了，核心代码可能就几十行。可能跟iOS里面的差不多（如果包含动画），但是实际出来的效果却差强人意。会出现类似的问题：页面抖动，感觉不连贯，在部分的设备下运行缓慢。如果你的应用要求的体验并不是很高，例如一些新闻展示类应用，更强调排版。这里小小的体验差距，就可以忽略了。（因为英国BBC就是这么干的），但是如果你的应用非常强调体验细节，这里的解决方案可能就不适合了。或许你要做优化，但是优化的时间可能足以够你去学习更多的东西了。这样的话，你是继续选择用一个不成熟的工具，还是选择去学习一种新的语言呢？所以还是根据需求而定吧。
另外一个例子。曾经有人跟笔者提及到，在使用HTML和CSS编写应用界面时确实很爽，但是效率不咋的。那为什么不尝试把应用内容直接搬到Canvas里面呢？构造一套足够强大的工具，一套足够彪悍的UI组件，把整个应用运行于Canvas中。这种想法是很好的，但是其实里面的短板页就出现了，Canvas的性能虽高，但是里面的元素组件多了你可以保证效果高？所有的东西都会依赖于JavaScript，这对于Javascript来说要构造足够强悍的面向对象的组件，也非简单之事，抛弃了CSS和HTML，意味着内部的设计组件能够高度定制，松耦合做得非常好。完全是实现了一套新的xcode和ui库啊。这就不是在解决一两个问题了。既然有这么一个工具，笔者为什么不选择更好的，例如Xamarin。
用适当的工具做适当的事情
做游戏的朋友估计就深有体会了。为了解决Canvas性能的问题，越来越多的人和应用厂商（尤其是浏览器厂商），提供一种解决方案就是希望将Canvas API和系统底层的API打通。意味着你只需要编写Canvas代码，实际做渲染的时候使用的是系统底层的东西，整体上提高了性能。例如Ejectahttp://impactjs.com/ejecta 这个东西。
对于开发人员来说用Javascript编写游戏逻辑以及做各种控制都非常舒服，而且因为用的API相同，放到PC上（放开性能问题），同样可以运行。这就真的做到了跨平台，但是又不缺乏效率。让笔者感触最深的就是@大城小胖在做混合应用（做游戏）时的做法，小胖的游戏架构。JS负责逻辑，引擎。JS Binding绑定原生OpenGL，让原生的来做复杂的渲染处理。HTML CSS可以处理UI（比如一些Button）。这就是典型的：让工具去做其擅长的事情。
跨平台是一个"幌子"
为什么这么说？笔者不是一直希望大家能够跨平台么？是的。但是要真的认清这个坎。从IE兼容，到目前多个浏览器的乱战，到iOS以及Android设备Web上的兼容，这不就是一个历史的例子嘛。跨平台不是不好，只是在一个时代里，你能够达到怎样的效果，真的是很难估量的。就好比你出国旅游，如果两国关系非常好，而且很多惯例法律一致，对你来说不会造成太多负担。但是如果语言不一样，生活习惯什么的都不同，你就很难适应。同样是人，你很难在不同的环境下生存。真正的跨平台，就意味着大家求同。这绝对不是一两天的事情，也非简单的事情。
那为什么还要跨平台。业务需求嘛。在这里必须就要遵守根据需求选择工具，用适当的工具做适当的事情，根据实际情况来作开发。如果可以，笔者觉得很有必要都了解一遍，这样的话各种开发的思想就会影响到你，你就能够分辨到什么是好什么是坏，做更好的选择。例如笔者刚刚说到的过场动画的例子。其实完全可以使用笔者说的混合应用中，方案三，去解决这个问题。你无非就是希望用navigationController做一个漂亮的过场动画嘛，在iOS中几句代码就实现了。
再说一个例子吧，如果你正在做一个todo-list的应用，其实无非就是简单存储数据以及做一些相关界面渲染。在使用原生的控件的话，有大堆的代码要写，而且还要处理好内存问题。但是其实如果使用Web的方式实现，比如backbone.js。总体代码可能100行左右。就把整个应用实现了，包括本地存储。你要做的事情就是把整个界面搭建得漂亮些。可能就1个小时的工作。但是如果用原生开发，很难保证到一个小时内完成，因为调试编译都需要时间吧？况且还有界面呢。
所以要认清跨平台这个"幌子"，并非所有的问题都用同一个方法处理。笔者们要融汇贯通嘛！
总结和笔者的感受
对于做Web App的坑，其实挺多的。这里无法一一表达。但是相信实践过就会知道如何更好地绕过这些坑（例如笔者说的过场动画的例子）。那么对于开发者来说要有坚强的毅力，努力去实践，满足自己永远不能满足的好奇心，因为最终的经验会给你带来不一样的感受，stay hungry。同时笔者们必须保持一颗学习的心，不断地吸收有营养的思想，学习新的知识，不要太容易满足，stay foolish。每一种语言都会有其中的思想，每一种工具都有自己解决问题的方法论。多尝试就能够给自己带来更优秀的架构，更优秀的应用，提供给用户更好的体验。当然，也会有更好的回报。
关于作者
李秉骏（@CashLee李秉骏），HTML5技术活跃分子，HTML5梦工场高级成员，投入Web开发多年。高中开始编写独立运营的电子商务网站。近年多进行移动应用前后端的开发，并尝试将混合应用开发技术运用于实践当中。
http://www.infoq.com/cn/articles/hybrid-app-development-combat