Hybrid App—Hybrid App开发模式介绍和各类开发模式对比

什么是Hybrid App

最开的App开发只有原生开发这个概念,但自从H5普遍流行后,一种效率更高的开发模式Hybrid应运而生,它就是"Hybrid模式"

Hybrid APP是目前普遍流行的一种APP开发模式

H5渗入APP开发

咱们都知道,原生APP开发中有一个webview的组件(Android中是webview,iOS7如下有UIWebview,7以上有WKWebview),这个组件能够加载Html文件。

在Html5没有兴盛以前,加载的Html每每只能用来作一些简单的静态资源显示,可是H5大行其道之后,Html5中有不少新增的功能,炫酷的效果,特别是iOS中H5支持一直都很良好,Android 4.4以上支持也足够

因此这时候发现能够将一些主要的逻辑都用H5页面来编写,而后原生直接用webview加载显示,这样大大提升了开发效率,并且体验也很不错

Hybrid的兴盛

所谓Hybrid,即混合开发,意味着半原生半Web,其实在H5兴盛以前,Hybrid模式就已经比较成熟了,可是一直不愠不火(由于系统的一些如今以及html自己功能的限制)

可是自从H5兴盛以后,你们发现原来不少功能均可以用web来实现,而后原生做为容器显示

因此为了提升开发效率,愈来愈多的人使用Hybrid模式进行开发,愈来愈多的Hybrid开发框架,愈来愈多的前端专职成为Hybrid开发，也就是说Hybrid也随之兴盛起来了

 

 

Hybrid定义

怎么样的开发模式才算是Hybrid模式呢?

Hybrid是半Native半web开发模式

Hybrid模式中,底层功能API均由原生容器经过某种方式提供,而后业务逻辑由H5页面完成,最终原生容器加载H5页面,完成整个App

成熟的Hybrid模式意味着业务逻辑均由H5实现

一款成熟的Hybrid框架,意味着各类类型的api都很完善,那么这时候几乎全部与业务相关的逻辑都是放在H5页面中的,原生只做为容器存在

成熟的Hybrid模式可复用性很是高,能够跨平台开发

成熟的Hybrid框架,那么原生只会提供底层API,也就是说全部的业务是H5完成,无论是什么项目,业务只由H5实现

这时候就能够发现,业务代码是能够跨平台的,也就是说,开发一次,就能够和各自原生容器结合,组成两种原生安装包了,达到了跨平台开发效果

 

 

 

Hybrid App的类型划分

上面提到过Hybrid的定义,但实际上,根据Native和web的混合程度,Hybrid也能够再次细分为多种类型

多View混合型

这种模式主要特色是将webview做为Native中的一个view组件,当须要的时候在独立运行显示,也就是说主体是Native,web技术只是起来一些补充做用

这种模式几乎就是原生开发,没有下降什么难度,到了16年几乎已经没人使用了

单View混合型

这种模式是在同一个view内,同时包括Native view和webview(互相之间是层叠的关系),好比一些应用会用H5来加载百度地图做为整个页面的主体内容,而后再webview之上覆盖一些原生的view,好比搜索什么的

这种模式开发完成后体验较好,可是开发成本较大,通常适合一些原生人员使用

Web主体型

这种模式算是传统意义上的Hybrid开发,不少Hybrid框架都是基于这种模式的,好比PhoneGap,AppCan,Html5+等

这种模式的一个最大特色是,Hybrid框架已经提供各类api,打包工具,调试工具,而后实际开发时不会使用到任何原生技术,实际上只会使用H5和js来编写,而后js能够调用原生提供的api来实现一些拓展功能

每每程序从入口页面,到每个功能都是h5和js完成的。理论上来讲,这种模式应该是最佳的一种模式(由于用H5和js编写最为快速,可以调用原生api,功可以完善)

可是因为一些webview自身的限制,致使了这种模式在性能上损耗不小,包括在一些内存控制上的不足,因此致使体验要逊色于原生很多。固然了,若是能解决体验差问题,这种模式应当是最优的(好比因为iOS对H5支持很好,iOS上的体验就很不错)

多主体共存型（灵活型）

这种模式的存在是为了解决web主体型的不足,这种模式的一个最大特色是,原生开发和h5开发共存,也就是说,对于一些性能要求很高的页面模块,用原生来完成,对于一些通用型模块,用h5和js来完成

这种模式通用有跨平台特性,并且用户体验号,性能高,不逊色与原生,可是有一个很大的限制就是,采用这种模式须要必定的技术前提

也就是说这种模式不一样于web主体型能够直接用第三方框架,这种模式通常是一些有技术支持的公司本身实现的,包括H5和原生的通讯,原生API提供,容器的一些处理所有由原生人员来完成

因此说,使用这种技术的前提是得有专业的原生人员(包括Android,iOS)以及业务开发人员(原生开发负责功能,前端解决简单通用h5功能)

 

 

Hybrid面临的挑战

好比Facebook推出的React Native方案,这是Facebook在放弃h5后自行推出一个'反H5方案',一句话总结就是:里面能够用JS来完整的写一个原生应用

好比微信推出的小程序(16年9月分内测),这也是一个微信主导的'反H5方案',一句话总结就是:里面能够同JS+微信自制的UI方案来写一个相似于原生的应用,只不过这个应用不是发布到App Store中,而是发布到微信中

 

 

 

Native、Hybrid、React Native、Web App方案的分析比较

目前的主流应用程序有四大类型:Native App、Hybrid App、React Native App、Web App。本文分别对这几种方案作一些分析对比

Native App

即传统的原生APP开发模式,Android基于Java语言,底层调用Google的 API;iOS基于OC或者Swift语言,底层调用App官方提供的API。体验最好

直接依托于操做系统,交互性最强,性能最好，相比于其它模式的交互,原生APP体验是最优的

功能最为强大,特别是在与系统交互中,几乎全部功能都能实现。得益于原生是直接依托于系统的,因此能够直接调用官方提供的api,功能最为全面(好比本地资源操做,通知,动画等)

开发成本高,没法跨平台,不一样平台Android和iOS上都要各自独立开发。Android上基于Java开发,iOS上基于OC或Swift开发,相互之间独立,必需要有各自的开发人员

门槛较高,原生人员有必定的入门门槛,相比广大的前端人员而言,较少。原生的一个很大特色就是独立,因此不太容易入门,不像web前端同样那么普遍,并且Android,iOS都须要独立学习

更新缓慢,特别是发布应用商店后,须要等到审核周期。原生应用更新是一个很大的问题,Android中还能直接下载整包APK进行更新,可是iOS中,若是是发布AppStore,必须经过AppStore地址更新,而每次更新都须要审核,因此没法达到及时更新

维护成本高。同开发同样,项目上线后,维护起来也很为麻烦

Web App

即移动端的网站,将页面部署在服务器上,而后用户使用各大浏览器访问。通常泛指 SPA(Single Page Application)模式开发出的网站。体验最差。不是独立APP,没法安装和发布

Web网站通常分两种,MPA(Multi-page Application)和SPA(Single-page Application)。而Web App通常泛指后面的SPA形式开发出的网站(由于能够模仿一些APP的特性),有以下优势和缺点

开发成本低,能够跨平台,调试方便。web app通常只须要一个前端人员开发出一套代码,而后便可应用于各大主流浏览器(特殊状况能够代码进行下兼容),没有新的学习成本,并且能够直接在浏览器中调试

维护成本低同上,若是代码合理,只须要一名前端就能够维护多个web app

更新最为快速。因为web app资源是直接部署在服务器端的,因此只须要替换服务器端的文件,用户访问是就已经更新了(固然须要解决一些缓存问题)

无需安装App,不会占用手机内存。经过浏览器便可访问,无需安装,用户就会比较愿意去用

性能低,用户体验差。因为是直接经过的浏览器访问,因此没法使用原生的API,操做体验很差

依赖于网络,页面访问速度慢,耗费流量。Web App每次访问都须要去服务端加载资源访问,因此必须依赖于网络,并且网速慢时访问速度很不理想,特别是在移动端,若是网站优化很差会无端消耗大量流量

功能受限,大量功能没法实现。只能使用Html5的一些特殊api,没法调用原生API,因此不少功能存在没法实现状况

临时性入口,用户留存率低。这既是它的优势,也是缺点,优势是无需安装,肯定是用完后有时候很难再找到,或者说很难专门为某个web app留存一个入口,致使用户很难再次使用

Hybrid App

即混合开发,由Native经过JSBridge等方法提供统一的API,而后用Html5+JS来写实际的逻辑,调用API,这种模式下,因为Android,iOS的API通常有一致性,并且最终的页面也是在webview中显示,有有跨平台效果

开发成本较低,能够跨平台,调试方便Hybrid模式下,由原生提供统一的API给JS调用,实际的主要逻辑有Html和JS来完成,而因为最终是放在webview中显示的,因此只须要写一套代码便可,达到跨平台效果,另外也能够直接在浏览器中调试,很为方便

最重要的是只须要一个前端人员稍微学习下JS api的调用便可,无需两个独立的原生人员。通常Hybrid中的跨平台最少能够跨三个平台:Android App,iOS App,普通webkit浏览器

维护成本低,功能可复用。同上,若是代码合理,只须要一名前端就能够维护多个app,并且不少功能还能够互相复用

更新较为自由。虽然没有web app更新那么快速,可是Hybrid中也能够经过原生提供api,进行资源主动下载,达到只更新资源文件,不更新apk(ipa)的效果

针对新手友好,学习成本较低。这种开发模式下,只须要前端人员关注一些原生提供的API,具体的实现无需关心,没有新的学习内容,只须要前端人员便可开发

功能更加完善,性能和体验要比起web app好太多。由于能够调用原生api,因此不少功能只要原生提供出就能够实现,另外性能也比较接近原生了

部分性能要求的页面可用原生实现。这应该是Hybrid模式的最多一个好处了,由于这种模式是原生混合web,因此咱们彻底能够将交互强,性能要求高的页面用原生写,而后一些其它页面用JS写,嵌入webview中,达到最佳体验

相比原生,性能仍然有较大损耗。这种模式受限于webview的性能桎梏,相比原生而言有很多损耗,体验没法和原生相比

不适用于交互性较强的app。这种模式的主要应用是:一些新闻阅读类,信息展现类的app;可是不适用于一些交互较强或者性能要求较高的app(好比动画较多就不适合)

React Native App

Facebook发起的开源的一套新的APP开发方案,使用JS+部分原生语法来实现功能。初次学习成本较高,可是在入门后,通过良好的封装也可以实现大部分的跨平台。并且体验很好。

虽说开发成本大于Hybrid模式,可是小于原生模式,大部分代码可复用。相比于原生模式,这种模式是统一用JS写代码,因此每每只须要一名成员投入学习,便可完成跨平台app的开发,并且后续代码封装的好,不少功能可复用

性能体验高于Hybrid,不逊色与原生。这种模式和Hybrid不同,Hybrid中的view层实际上仍是dom,可是这种模式的view层是虚拟dom,因此性能要高于Hybrid,距离原生差距不大

这种模式能够认为是用JS写原生,即页面用JS写,而后原生经过Bridge技术分析JS,将JS内容单独渲染成原生Android和iOS,因此也就是为何性能不逊色原生

开发人员单一技术栈,一次学习,跨平台开发。这种模式是统一由JS编写,有着独特的语法,因此只须要学习一次,便可同时开发Android和iOS

社区繁荣,遇到问题容易解决。这应该是React Native的很大一个优点,不像Hybrid模式和原生模式同样各自为营,这种模式是Facebook统一发起的,因此有一个统一的社区,里面有大量资源和活跃的人员,对开发者很友好

虽然能够部分跨平台,但并非Hybrid中的一次编写,两次运行那种,而是不一样平台代码有所区别这种模式实际上仍是JS来写原生,因此Android和iOS中的原生代码会有所区别,若是须要跨平台,对开发人员有必定要求固然了,若是发展了有必定时间,组件库够丰富了,那么其实影响也就不大了,甚至会比Hybrid更快

开发人员学习有必定成本。虽然社区已经比较成熟了,可是一个新的普通前端学习起来仍是有必定学习成本的,没法像Hybrid模式同样平滑

各大开发模式直观对比

	Native App	Web App	Hybrid App	React Native App
原生功能体验	优秀	差	良好	接近优秀
渲染性能	很是快	慢	接近快	快
是否支持设备底层访问	支持	不支持	支持	支持
网络要求	支持离线	依赖网络	支持离线(资源存本地状况)	支持离线
更新复杂度	高(几乎老是经过应用商店更新)	低(服务器端直接更新)	较低(能够进行资源包更新)	较低(能够进行资源包更新)
编程语言	Android(Java),iOS(OC/Swift)	js+html+css3	js+html+css3	主要使用JS编写,语法规则JSX
社区资源	丰富(Android,iOS单独学习)	丰富(大量前端资源)	有局限(不一样的Hybrid相互独立)	丰富(统一的活跃社区)
上手难度	难(不一样平台须要单独学习)	简单(写一次,支持不一样平台访问)	简单(写一次,运行任何平台)	中等(学习一次,写任何平台)
开发周期	长	短	较短	中等
开发成本	昂贵	便宜	较为便宜	中等
跨平台	不跨平台	全部H5浏览器	Android,iOS,h5浏览器	Android,iOS
APP发布	App Store	Web服务器	App Store	App Store

 

 

 

如何选择开发模式

目前有多种开发模式,那么咱们平时开发时如何选择用哪一种模式呢？以下

选择纯Native App模式的状况

性能要求极高,体验要求极好,不追求开发效率。通常属于吹毛求疵的那种级别了,由于正常来讲若是要求不是特别高,会有Hybrid

选择Web App模式的状况

不追求用户体验和性能,对离线访问没要求。正常来讲,若是追求性能和体验,都不会选用web app

没有额外功能,只有一些信息展现。由于web有限制,不少功能都没法实现,因此有额外功能就只能弃用这种方案了

选择Hybrid App模式的状况

大部分状况下的App都推荐采用这种模式这种模式能够用原生来实现要求高的界面,对于一些比较通用型,展现型的页面彻底能够用web来实现,达到跨平台效果,提高效率

固然了,通常好一点的Hybrid方案,都会把资源放在本地的,能够减小网络流量消耗

选择React Native App模式的状况

追求性能,体验,同时追求开发效率,并且有必定的技术资本,舍得前期投入

React Native这种模式学习成本较高,因此须要前期投入很多时间才能达到较好水平,可是有了必定水准后,开发起来它的优点就体现出来了,性能不逊色原生,并且开发速度也很快

 

 

另类的app方案

除了以上的几种常见app开发模式,其实还有一些其它的相似方案

微网页

好比在进行微信网页开发时,能够调用一些微信的特殊api,这其实就是算是微信的Hybrid模式,实质上仍然是在浏览器中(只不过是腾讯的X5内核)

固然了,微信在这方面作了不少限制,好比权限认证等等,因此致使开发起来效果不是很完美。这里再也不赘述其功能

微信小程序

微信小程序是微信新推出的一种新的app方案,2016年9月开始进行内测,2016年11月准备全面面向开发者

须要注意的是,这种模式是“反HTML5”的,至关因而微信提供的一套封闭开发模式,有本身的语法和IDE,有的相似于iOS开发的感受。

 

 

 

Hybrid APP之Native和H5页面交互原理

Hybrid APP的关键是原生页面与H5页面直接的交互，以下图,痛过JSBridge,H5页面能够调用Native的api,Native也可调用H5页面的方法或者通知H5页面回调

在Hybrid APP中,原生与H5的交互方式在Android和iOS上的实现是有异同的,缘由是Android、iOS的通讯机制有所区别,下面介绍原生和H5相互调用的方法

Native与H5交互的两种方式