横向浅谈移动技术------（原生，混合，web --- 谁能问鼎移动开发的明天）

目前移动互联网基本采用了NativeApp、WebApp、HybridApp三种开发模式，很难说这三种模式那种更优越，目前的情况可以说是三分天下吧，不同的开发者可以根据自己的实际情况选择不同的开发模式。谈论那种模式最好实际上事非常无聊的事情。

1.1. APP三种开发模式

智能手机之普及不用多说，手机APP渗投到各个行业：电商（淘宝、京东等）、金融（各手机行业、P2P借贷等）、医疗（智慧医疗）、交通（滴滴、Uber等）、教育（慕课网等）、餐饮（饿了吗、美团等）……反正只要是个企业，无论规模大小，都已经订制或将要订制自己的APP。这么多APP无外乎就三种模式：Native App、Web App、Hybrid App。

1、NativeApp

Native技术主要用于提供原生支持，要做到跨平台，就需要掌握部分Android和iOS的知识，除了多线程，文件存储等基础知识，Android需要非常熟练的掌握WebView、WebSettings、WebChromeClient、WebClient四大对象。iOS需要非常熟练掌握UIWebView对象。

Native App，原生APP，使用原生（即Android或iOS）开发的APP。

优点：

1，应用的性能好，体验好，适配起来相对容易。在APP竞争如此白热化的当下，体验是决定APP“生死”的必要因素。让用户感觉不爽了，只有一个下场，就是“卸载”，“卸载”，“卸载”。让APP常驻用户手机的梦想破灭。

2，技术成熟。

3，和原生平台API无缝对接，打造优质体验。

缺点：

1、无法跨平台：Android和iOS都需要开发各自平台的版本——开发成本高；

2、升级麻烦：每次升级都要下载安装包，Android还好，反正不需要审核，下载就下载吧，但iOS就麻烦了，发布每个版本还得经过App Store的审核，这导致第三个问题；

3、Android和iOS很难同步发布。

4，成本高。

2、WebApp

所谓的Web App，就是把手机当做一个浏览器（Android使用WebView，iOS使用UIWebView），做几个页面挂在服务器端，类似于一个小网站。这样说虽然不太贴切，但实际上给人的感觉就是这样的。虽然开发成本大大降低，但页面访问速度慢、操作体验差。于是第三种模式诞生了。

HTML5技术的兴起给Web App注入了新的生机。

Web App具有开发成本低、周期短、使用方便、维护简单等特点。

随着HTML5被过度热炒和实际开发中遇到的性能以及体验问题，WebApp逐渐势弱。

同样，以AppStore为首的App分发平台当然是不希望webapp破坏自己建立的生态系统的。

html5迟迟没有得不到一个公认的标准，也阻碍着webapp的发展。但是这些都不足以阻碍webapp的发展。

现在APP的数量已经达到数以百万计，实际上用户根本不需要这么多的App，很多App被用户下载后，一个月都不会被打开一次。
而webapp用户根本不需要安装，只需要打开手机浏览器，输入网址或搜索目标，点击即可到达想要的网页，基本和PC互联网的思路是一致的，这也说明百度同样在移动入口上有这很大的优势。在NativeApp上用户只有安装了App，才能浏览，而webapp是直接通过手机浏览器为入口，或者推送的信息为入口，这么看webapp在流量上是有很大的优势的。

但是目前webapp得不到很好的发展主要有以下几个方面的原因：

1、无有效且广泛的webapp发行渠道（NativeApp有AppStore等）；

2、webapp表现和体验不佳（这点算硬伤吧）；

3、适配难度（一套web很难兼容所有的手机，特别是国内某些自以为很牛B的手机，大可乐算一个吧，哈哈）；

4、配套的标准尚未成熟（主要指html5吧）。
网站移动化是必然的，目前知道webapp比较好的解决方案有如下几个：
1、云适配号称引入一段神奇的代码就能将PC网站移动化。陈本峰老师也是我学习的榜样，html5布道官。了解更多信息可以链接到http://www.yunshipei.com/
2、百度site App 网址：http://siteapp.baidu.com/
3、还知道个做微站的网站，号称把微信、微博入口都已打通，企业用户营销很好的平台：http://www.weizhan360.com/
当然有实力的公司也有许多都有自己的移动团队，重新开发一套自己的移动端网站。如：最近刚刚上市的58同城 http://m.58.com
这里说的几种解决方案，开发者也得根据自己的需要去选择，还是拿58同城举例子，58同城不可能去云适配，本来PC端的网页就够乱了，这也和58同城分类信息特征有关系，如果云适配，在手机端得不到很好的展示，只会更加的乱了。

技术：

1、 HTML5

熟练掌握HTML5的各个标签，如何编写最优的文档结构。

2、 CSS

熟练掌握CSS2和CSS3的新特性，能按照效果图编写最高性能的样式。

使用SCSS生成CSS，将CSS可编程化。

3、 JavaScript

实现业务逻辑控制。个人理解JavaScript主要包含两大内容：DOM编程和面向对象编程。大部分JS开发人员就只掌握DOM编程，诸如document.getElementById()等，但面向对象是很重要的一个方面。

4、性能和开发

模块化编程：编写可复用的组建；

CSS渲染：了解浏览器的CSS渲染引擎才能编写更高效率的样式；

JS解析：了解浏览器的JS解析引擎才能优化JS脚本；

HTTP协议：熟练掌握HTTP请求的各个内容；

AJAX：和服务器端的交互大都采用AJAX。

3、HybridApp

Hybrid App发展现状

目前中国70%以上的Native APP都已经混合了Web技术，例如淘宝、大众点评、58同城、去哪儿等超级App都嵌入了大量的HTML5页面，尤其是内容页面中体现。让部分功能在WebView技术基础上缩短开发周期、实现灵活业务调整。然而很多中小技术团队嵌入的Html5部分，用户体验还是比较差、功能比较弱。让Native App开发团队开发出体验好和功能强的HTML5页面并不是简单的事情。

究其原因，Hybrid App的学习成本较高，需要同时掌握Native技术和Web技术，因此专业做Hybrid开发的程序猿并不多，学习资料自然也少，大家都是摸着石头过河，一点一点的摸索屏幕适配、UI响应速度以及如何使Native语言与Web语言在同一产品中得到很好的协调和配合。

开发一款高性能的Hybrid App，最终还是要将两种语言化为一体，；例如APICloud的半翻译式原理，将大量网页代码在运行时翻译成可调用原生的API，如此一来既获得了Hybrid App的优势，又不会产生两种语言协调不均造成的用户体验差的问题。Deep Engine强大的混合渲染引擎提供了更完善的性能体验。聚合API中拥有众多Native语言开发的功能模块，在开发中调用Native API无疑更增加产品整体用户体验。

混合APP的未来：

移动应用的大势已来，超级App即将诞生，此时无论是Native App还是Web App都将不能满足人们对于移动应用的需求，对于企业来说是开发快、成本低；

对于用户来说则是性能好、体验佳。Hybrid App的需求必然猛增，而此时我们应考虑的是如何将原有的App快速转成Hybrid模式。

汽车有混合动力Hybrid，移动应用同样也有混合模式。Hybrid App（混合模式移动应用）兼具“Native App良好用户交互体验的优势”和“Web App跨平台开发的优势”。很多人不知道市场上一些主流移动应用都是基于Hybrid App的方式开发，比如国外有Facebook、国内有百度搜索等。但究竟什么是Hybrid App？如何定义？

我们来拆解一下里面的含义：

1、mobile application：Hybrid App就是一个移动应用

2、both browser-supported language and computer language：同时使用网页语言与程序语言编写

3、available through application distribution platforms：通过应用商店进行分发

4、a target device：区分目标平台

5、install to run：用户需要安装使用

综合一下就是：“Hybrid App同时使用网页语言与程序语言开发，通过应用商店区分移动操作系统分发，用户需要安装使用的移动应用”。总体特性更接近Native App但是和Web App区别较大。只是因为同时使用了网页语言编码，所以开发成本和难度比Native App要小很多。因此说，Hybrid App兼具了Native App的所有优势，也兼具了Web App使用HTML5跨平台开发低成本的优势。

Hyrbid App为什么会兴起？

Hybrid App的兴起是现阶段移动互联网产业的一种偶然。移动互联网的热潮刮起后，众多公司前赴后继的进入。但是很快发现移动应用的开发人员太少，所以导致疯狂的人才争夺。市场机制下移动应用开发人才的待遇扶摇直上，最终变成众多企业无法负担养一个具备跨平台开发能力的专业移动应用开发团队。而HTML5的出现让Web App露出曙光，HTML5开发移动应用的跨平台和廉价优势让众多想进入移动互联网领域的公司开始心动。可是当下基于HTML5的Web App更是雾里看花，在用户入口习惯、分发渠道和应用体验这三个核心问题没解决之前，Web App也很难得以爆发。正是在这样是机缘巧合下，基于HTML5低成本跨平台开发优势又兼具Native App特质的Hybrid App技术杀入混战，并且很快吸引了众人的目光。大幅的降低了移动应用的开发成本，可以通过现有应用商店模式发行，在用户桌面形成独立入口等等这些，让Hybrid App成为解决移动应用开发困境不错的选择，也成为现阶段Web App的代言人。Hybrid App像刺客一样，在Native App和Web App混战之时，偶然间的在移动应用开发领域占有了一席之地。

Hybrid App是如何实现网页语言与程序语言的混合？谁占主体？（这是关键，这个百分比很关键）

Hybrid App通常分为三种类型：多View混合型，单View混合型，Web主体型。

多View混合型：（目前常用的方法）

即Native View和Web View独立展示，交替出现。目前常见的Hybrid App是Native View与WebView交替的场景出现。这种应用混合逻辑相对简单。即在需要的时候，将WebView当成一个独立的View（Activity）运行起来，在WebView内完成相关的展示操作。这种移动应用主体通常是Native App，Web技术只是起到补充作用。

AppCan和Rexsee都属于多View混合型，它们可以在HTML5无法胜任的时候采用Native View来进行补充。这种方式虽然对HTML5做了一定性的弥补，但是一个界面中HTML5可能无法胜任的仅仅是其中一部分，却要把整个界面全部推翻，重新使用Native来实现，对于开发成本是极高的，所以实际使用中，很多开发者可能因为各种因素，特别是成本上的考虑会对HTML5的弊端进行妥协。这造成多View的混合型框架在实际应用中跟Web主体型并无太大的差异。这也是为什么有的开发者愿意选择其他框架而不选择多View混合型框架的原因，它的Native View有如鸡肋般的存在，让开发者无能为力。

集成难度小。开发难度和Native App基本相当。

代表APP产品：支付宝，陆金所，搜易贷，，

单View混合型：（体验与原始相当）

即在同一个View内，同时包括Native View和Web View。互相之间是覆盖（层叠）的关系。这种Hybrid App的开发成本较高，开发难度较大，但是体验较好。如百度搜索为代表的单View混合型移动应用，既可以实现充分的灵活性，又能实现较好的用户体验。

代表APP产品：手机百度

Web主体型：（体验较差）

即移动应用的主体是Web View，主要以网页语言编写，穿插Native功能的Hybrid App开发类型。这种类型开发的移动应用体验相对而言存在缺陷，但整体开发难度大幅降低，并且基本可以实现跨平台。

Web主体型的移动应用用户体验的好坏，主要取决于底层中间件的交互与跨平台的能力。

这种方式由于太过偏重于HTML5，用户体验性相对比较差，甚至会受困于浏览器之争。

从分析可见，Hybrid App中的Web主体型只要能够解决用户体验差的问题，就可以变成最佳Hybrid App解决方案类型。AppCan在技术架构上和PhoneGap类似是Web主体型中间件，但是通过结合了一些原生交互效果能够达到iOS、Android平台都比较一致的用户体验。此外，AppCan对引擎进行了独特处理，在分辨率及移动端的适配上更加出色。也有一些厂商，采用翻译的方式，将HTML标签解析成Native进行展示，完全受限于自身的解析能力，损失了HTML5技术的最大优势:灵活，在其基础上开发的App在基因上就带着适配性能差的硬伤。

AppCan的技术完全能够匹配政府及500强企业的需求，目前包括东方航空、国家电网等大企业都在使用AppCan的技术完成移动信息化的解决方案。投入标杆技术的建设证明，AppCan可以完成跨行业、跨领域的解决方案，那么开发者同样可以利用AppCan技术，实现移动创业并获得收入。

而与单纯提供移动开发能力的厂商相比，AppCan在应用管理及服务上也颇为用心，已经打造出涵盖开发工具、应用创新、技术培训、运营推广四大环节的AppCan.cn一站式移动开发服务平台。移动互联网的红利近在眼前，创业机会转瞬即逝，开发者唯有谨慎选择适合自己的技术、平台，才有望在激烈的竞争中崭露头角。

国外的appMobi、PhoneGap国内的AppCan和Rexsee都属于Web主体型移动应用中间件。其中Rexsee不支持跨平台开发。appMobi和PhoneGap除基础的底层能力更多是通过插件（Plugins）扩展的机制实现Hybrid。而AppCan除了插件机制，还提供了大量的单View混合型的接口来完善和弥补Web主体型Hybrid App体验差的问题，接近Native App的体验。

代表APP产品：平安银行APP。

多View混合型，单View混合型，Web主体型优劣势对比

	多View混合型	单View混合型	Web主体型
常见主体	Native	Native	Web
开发成本	中	高	低
用户体验	良	优	差

从分析可见，Hybrid App中的Web主体型只要能够解决用户体验差的问题，就可以变成最佳Hybrid App解决方案类型。

Hybrid App的瓶颈与未来

国内外Hybrid App的开发框架众多。如何选择又成为一个难题。下面对开发者比较关心的集中知名跨平台开发移动应用中间件进行列表和对比，以便选择最适合您的移动应用中间件。

PhoneGap是相对比较早进入公众视线的一种选择。但是，开发者简单的基于PhoneGap来开发移动应用肯定会发现结果和Web App比较差的用户体验类似。这也是为什么基于PhoneGap有实用性的移动应用主要集中在iOS上。可是PhoneGap这种现状弱化了HTML5的跨平台价值。

AppCan在技术架构上和PhoneGap类似是Web主体型中间件，但是通过结合了一些原生交互效果能够达到iOS、Android平台都比较一致的用户体验。但是相比PhoneGap的开源，AppCan相对封闭的路线显得过于谨慎。

Titanium是一种基于翻译机制的跨平台中间件，能够开发出具有Native体验的移动应用，但是因为翻译机制的限制导致移动应用开发不能像真正的HTML5开发一样灵活。哪怕一个按钮也不能像普通HTML一样来编写，而必须按照Titanium约定的特定格式。

Hybrid App这个领域虽然还处于比较初期的阶段，但是已经有很多优秀的公司和技术团队在致力于跨平台开发移动应用中间件技术的研究，给了开发者众多选择。开发者可以根据实际的项目需求来选择中间件。Web App虽被浏览器厂商和搜索引擎公司所推崇，但存在用户体验差、盈利模式不明确等现阶段无法解决的问题，或最终夭折。Hybrid App正在被越来越多的公司和开发者所认同，势必会成为新世界的王。

一些混合框架：

Cordova/PhoneGap：侧重于JS与原生的交互，开发简单，但性能差，如触摸时反应不灵敏。

AppCan：性能还行，使用简单，但要提交代码给AppCan的服务器才能打包，相信有追求的企业是不会把自己的代码提交给第三方，把打包权利交给第三方的。

Ionic Framework：在Cordova的基础上增加一些UI/JS方面的东西，样式还不错，但同样具有Cordova的不足。

MUI：缺点是工程大了，反应就迟钝了，不能和原生API很好的契合。资料少。出了bug都不知道去哪里找解决方法。

js UI 框架

jQuery Mobile：上手简单，组件丰富，但性能超级差，闪屏现象严重。

Senche Touch：简单看过，没有使用过，貌似UI很漂亮，学习成本高。

React Native：FB推出的，当年FB是最早尝试Hybrid的，但性能超差，于是APP放弃了Hybrid，走原生的道路。在大家都不看好H5时，FB暗中深入挖掘H5，三年之后推出了这个框架，非常推荐各位去学习其中的思想。

GMU：百度推出的，这个不错。

js库：

这个就多了，jQuery、Zepto、Swiper、iScroll、RequireJS、AngularJS……

Hybrid App，这种既有跨平台开发周期短、成本低的基因，又能发挥Native App体验和性能的优势，HybridApp混合式移动应用开发逐渐成为企业移动开发的首选。

Hybrid App通常是基于第三方跨平台移动应用引擎框架进行开发，在国内开发者中比较知名的有PhoneGap、Titanium和AppCan这些引擎框架一般使用HTML5和Javascript作为编程语言，调用引擎封装的底层功能如照相机、传感器、通讯录、二维码等。

HTML5和Javascript只是作为一种解析语言，真正调用的都是NativeApp一样封装的底层功能，这是和Web App的最大区别和不同。因为使用了浏览器技术，所以Hybrid App通常具有跨平台的特性，并且开发成本和WebApp接近，开发效率也远高于Native App。

说实在的，从表面上看的话，很难区分一个App到底是Native App还是Hybrid App，但实际上我们更多的是把Hybrid App当做是Webapp的一部分，因为他是一部分Native（比较少），绝大部分的web页面（html5页面）。通过手机抓包工具Fiddler是可以区分一个App到底是Native App还是Hybrid App的。Hybrid App和Native App一样都是需要用户在各种App分发渠道上下载并安装到手机上才能用的。Hybrid App的体验当然是没话说，比较棒的，有这Native App的全部优点。html5很好的解决了跨平台性的问题，也解决了开发成本过高的问题。网上有估计到2016年50%+的App将是Hybrid App。譬如现在也有许多不多的代表作，如：fb、掌上百度、以及刚上市的58客户端。
One Web more native 可以很好的形容Hybrid App这种开发模式。
作为一个有着1年多Hybrid App开发经验的屌丝攻城师来说，在这里想给Hybrid App这种开发模式泼一泼冷水，说一说开发过程中他的不足之处吧。
首先，一套web兼容n个Native是一件很难的事情，尤其是对一些App更新特别频繁的公司来说，更是苦难。Hybrid App中的js、css等静态资源的管理就是一个很头疼的问题。譬如我们1.0版本后，1.1版本html页面有修改变动，js、css资源文件就会有变动，那么我们的这些资源就得兼容以前的版本，那以前的版本要不要去加载最新版本的资源文件呢？是采用同步加载还是异步加载呢？资源加载的过程中如果加载的资源有一部分失败了呢？老版本的包升级更新到新版本资源下载原子性的问题？像这种静态资源文件需不需要内置到客户端里面呢？
当然Hybrid App作为一个新型的开发模式，谁也不能保证一开始就想清楚所有的事情，任何新兴事物都得在发展过程中，才能逐渐看清楚未来。
如果作为是完全新开发Hybrid App，关于资源问题可采用如下方案：首先，静态资源必须内置到客户端里面，包括一些重要的静态页面。这样能提高App的流畅性，在现在国内移动网络这么差的情况下，让用户去下载几十K的资源简直是灾难性的。资源都配置一个版本号，资源更新采用同步加载和异步加载并行，对于一些不影响用户功能使用的资源采用异步加载的方式实现，第一次进入页面的时候还是使用老的资源，异步去加载资源，如果资源加载完成，第二次进入的时候就使用新的资源文件。如果缺少了这个资源，功能有问题，或者样式有问题，那这些资源就要同步加载，同步加载可以放在启动客户端后加载或者加载进入页面时同步加载。还一个比较难的问题是老版本包资源更新的时候更新资源的原子性，如果某些资源加载失败了，要怎么处理？我的想法是只有资源完全加载成功后才将本地的版本号修改，标记为成功，那些失败的资源在进入引入改资源的页面或者启动客户端的时候会被再次的加载。

乍一看和Web App没啥差别，但涉及到的技术成本、开发成本、学习成本比Web App高，它综合了Web App的开发速度和Native App的高性能体验。之所以说学习成本高，是因为开发高性能的Hybrid App有难度，网络资料少。我是两年半前开始接触混合模式开发的，当时如何做好屏幕适配、提高UI响应速度、如何最大化使用原生功能等内容，网络几乎没有资料。网上能搜索到的都是很粗略的东西，或者就是Hello World级别的东西，涉及到稍微细节一点的东西几乎没有。由于本系列文章都只讲Hybrid，故在此不再啰嗦了。

三种开发模式各自的特点如下面的表格所示：

	Native App	Hybrid App	Web App
原生功能体验	优秀	接近优秀	差
性能	非常快	快	慢
跨平台开发成本	昂贵	合理	便宜
碎片化适配	非常严重	严重	严重
编程技术支持	短缺	非常短缺	通用人才
版本升级维护	保守	低延时	开放
安全	强	中	弱

由于移动端是一个重视性能和用户体验的终端，大量采用框架存在一些问题：

1、扩展、维护、定制成本，这个非常需要考虑，或许框架提供的UI风格和自己设计的UI风格差异大，导致设计围绕框架转，不符合产品的需求。

2、既然是框架，强调的是覆盖面广度和功能的全面，会有很多无用的东西，带来累赘；

3、框架本身存在BUG，或许需要开发人员面对一些能力之外的问题。

总之，如果只追求像山寨作坊一样快速产出、不计性能的开发产品，那使用现成的框架是不二选择。但如果追求性能和真正的产品，建议使用库，不要使用框架。但是很多框架的实现思想都很优秀，虽然不建议使用，但我们应该多接触学习其中的思想，才能写更好的代码。仅仅建议而已，不中听请忽略。

总结：

笔者认为，真正的Hybrid App框架并不局限于PhoneGap、Appcan这样的传统开发框架那么简单，它既不是在HTML5的外表下套个壳，也不是HTML5和Native的各自为政。

做为一种开发模式，Hybrid App框架技术也在不断变革，就像烽火星空的ExMobi那样具备强大的Native布局能力和HTML5的灵活展现能力，能够让Native和HTML5可以友好共存，并以标签化的方式更方便开发者的随意调用和扩展。选择具有强大技术实力的Hybrid App框架对开发者提供的不仅仅是便捷，而是一种先进的开发模式和思维方式。