这种模式是在同一个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功能)
当然了,如果技术上没有问题,用这种方案开发出来的App体验是很好的,而且性能也不逊色原生,所以是一种很优的方案
Hybrid架构 基本原理如下图,痛过JSBridge,H5页面可以调用Native的api,Native也可调用H5页面的方法或者通知H5页面回调
知道了Hybrid的基本原理,那么Hybrid模式内部是如何实现的呢?H5和Native直接的通信又是如何实现的呢?
请参考 后续系列文章
Hybrid的未来 现行多种App开发模式以及分析比较现在的App开发,除了Hybrid,还有Native,纯web,React Native等方案,下面介绍下各种方案的分析对比
参考 Native、Hybrid、React Native、Web App方案的分析比较
Hybrid面临的挑战比如Facebook推出的React Native方案,这是Facebook在放弃h5后自行推出一个\'反H5方案\',一句话总结就是:里面可以用JS来完整的写一个原生应用
比如微信推出的小程序(16年9月份内测),这也是一个微信主导的\'反H5方案\',一句话总结就是:里面可以同JS+微信自制的UI方案来写一个类似于原生的应用,只不过这个应用不是发布到App Store中,而是发布到微信中
像以上技术都不断的在冲击着Hybrid模式(当然Native也会有影响),不过都很推崇JS(话说很多前端猿一直希望JS一统天下)
到现在为止,2016年已经快过去了,新的技术也不断的在涌出,各类的新技术都不断的在冲击着Hybrid模式的地位,正如一句话"长江后浪拍前浪,前浪*****",任何技术都会被时间无情的筛选,请不要奇怪,也许不久后的某天,你会突然发现Hybrid模式已经完全落伍了。