一篇文章,让你快速了解Hybrid App开发模式

作者:zhouxiaotian日期:2016-07-15 22:25:03 点击:2612 HTML5

Hybrid App(混合模式移动应用)是指介于web-app、native-app这两者之间的app,兼具“Native App良好用户交互体验的优势”和“Web App跨平台开发的优势”。

Native App

移动互联网刚开始兴起的时候,我们手机上的应用(App)都是通过Native App开发而成的;Native App的开发具备很多的优势:

  • ->开发出来的产品具备良好的用户体验,动画和运行的速度非常的流畅。
  • ->能够对手机的内部软件或者硬件进行直接的操作,例如:可以调取用户的通讯论、读取用户的短信(当然需要用户同意),可以调取用户的摄像头,调取手机的重力感应等
  • ...

但是Native App的开发也存在自己的很多不足:

  • ->首先是不能跨平台,针对目前最常用的IOS和安卓平台,需要用不同的技术来开发:IOS一般使用的是Object-c,而安卓平台使用的一般是Java-Native,这样就导致了开发一款App需要两队人马去做,随之而来的问题也会很多,比如:开发成本高,开发周期长,有的功能IOS有但是安卓没有(手Q就是这样的)等。
  • ->开发出来的产品需要用户自主性比较强:首先需要客户到应用商店安装,后期如果版本升级,用户想要看到最新的版本还需要重新的进行下载安装升级等。
  • ->在IOS平台上,开发出一款App上传到苹果App Store需要7天的审核期,在此期间如果审核失败,在此上传还需要七天,这样就有可能导致产品不能按时发布等。
  • ...

Web App

而HTML5的出现让Web App露出曙光。HTML5基本上不需要考虑是IOS还是安卓,两个平台一套代码基本上都是支持的;更新版本只需要在自己的服务器上更新了即可,这样用户再次访问的时候看到的就已经是最新版本的了;不需要经过漫长审核...这些优势让开发者们大为心动,但是HTML5的本质是运行在浏览器中的页面(App是直接运行在操作系统中的),由于浏览器的差异以及对一些特殊功能支持力度的不够,导致HTML5开发存在一些局限性问题:

  • ->开发出来的产品性能和运行速度没有App的好,用户体验不是很好。
  • ->虽然安卓和IOS平台上的浏览器大部分都是webkit内核的,但是浏览器厂商为了自己的特殊化,移动设备上的浏览器兼容也不少,甚至一些兼容问题是无法解决的(例如:position:fixed的支持非常的不好)。
  • ->由于HTML5的本质是运行在浏览器中的,所以想要操作系统中的软件或者硬件都需要所在的浏览器支持,很遗憾大部分浏览器对于这方面的操作都支持的不好,所以也就导致了,H5的产品在调取通讯录、摄像头、读取短信等方面存在了很大的短板,基本上很少用H5去做这些事情的。
  • ...

Hybrid App

正是在这样是机缘巧合下,基于HTML5低成本跨平台开发优势又兼具Native App特质的Hybrid App技术杀入混战,并且很快吸引了众人的目光。Hybrid App是把Native App和Web App混合在一起的新兴模式(目前市场上的大部分App都是混合模式开发的)。利用各自的优势,去开发一款低成本、跨平台、更新快、性能好、功能丰富的App。

Hybrid App按网页语言与程序语言的混合,通常分为三种类型:多View混合型,单View混合型,Web主体型。

多View混合型(目前常用的)

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

单View混合型

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

Web主体型(目前比较新颖流行的方式)

即移动应用的主体是Web View,主要以网页语言编写,穿插Native功能的Hybrid App开发类型。这种类型开发的移动应用体验相对而言存在缺陷,但整体开发难度大幅降低,并且基本可以实现跨平台。通俗来说,就是App中的页面基本上都是H5完成的,我们使用一些技术框架封装一个App的壳子,框架中还提供一些操作系统级别功能的API供H5的调取,一般来说,都是由JS编写代码来完成App壳子搭建的,这样开发的App也就不会在使用JAVA或者Object-c了。

目前市面上比较流行的框架有:React Native、phoneGap、appcan、APICloud、ionicframework、appMobi、WeX5...(珠峰培训的C阶段课程会给大家讲解React Native)

接下来我们分享一下,关于多View混合型中的H5和Native App是如何的实现交互与通信的。

在这之前,我们首先需要知道,在多View混合型中,我们的HTML5页面主要运行在Native App提供的Web View中(你也可以把web view理解成为一个浏览器,因为他和浏览器基本上差不多)。但是我们知道H5是存在一些局限性的,比如我们想调取用户的摄像头拍照,这个H5解决不了,这样的话我们需要先用App把这个功能实现了,然后由H5在调取App的相关功能。这样就需要实现H5和App之间的通信交互。

第一种常用方式:jsBridge(微信平台的JS SDK就是基于这个开发的)

WebView有一个方法,叫setWebChromeClient,可以设置WebChromeClient对象,而这个对象中有三个方法,分别是onJsAlert,onJsConfirm,onJsPrompt,当js调用window对象的对应的方法,即window.alert,window.confirm,window.prompt,WebChromeClient对象中的三个方法对应的就会被触发,利用这个机制我们就可以做一些特殊的处理。但是在项目中我们一般对于alert和confirm使用的频率较高,如果我们使用onJsAlert,onJsConfirm,那么我们普通的弹框也会受到影响,所以目前市场上最长使用的是onJsPrompt。

以上的操作基本上都需要由App那边进行开发,我们主要讲的是H5,所以此处不对App的机制做过多的描述。大家只需要知道,只要App那边做了特殊的处理(就是在webView中注入一个对象,对象中包含了我们需要调取的方法),那么在H5的js中,我们就可以调取WebView中提供的方法。一般来说需要我们给方法传递一个callback进去,这样App就会在具体的某个阶段,把我们的callback执行,从而实现对应的通信效果。下面是我们使用JS调取微信接口的DEMO:

     //->首先需要引入微信提供好的一个JS:http://res.wx.qq.com/open/js/jweixin-1.0.0.js (其实App就是把这个JS中提供的方法注入到了web view中,所以我们只要引入这个JS进来就可以调用App的一些方法了)     wx.config({         debug: false,         appId: "你的AppID",         timestamp: '时间戳(需要后台生成)',         nonceStr: '字符串(需要后台生成)',         signature: '签名(需要后台生成)',         jsApiList: ['onMenuShareTimeline', 'onMenuShareAppMessage']//->功能列表,我们要使用JS-SDK的什么功能     });     //->首先调取ready方法,这里说明一下,web view中注入的对象其实就是wx,read就是提供的一个方法,此处的匿名函数就是我们传递进去的callback,当微信检测到已经准备就绪的时候就会把我们的callback执行     wx.ready(function () {         //获取“分享到朋友圈”按钮点击状态及自定义分享内容接口         wx.onMenuShareTimeline({             title: '分享标题',             link: "分享的url,以http或https开头",             imgUrl: "分享图标的url,以http或https开头"         });         //获取“分享给朋友”按钮点击状态及自定义分享内容接口         wx.onMenuShareAppMessage({             title: '分享标题',             desc: "分享描述",             link: "分享的url,以http或https开头",             imgUrl: "分享图标的url,以http或https开头",             type: 'link'         });     }); 

第二种常用方式:伪装的URL或者伪装的协议

相对于第一种jsBridge,第二种方式就比较的简单了。首先H5开发人员和App人员协商一套协议或者伪装的URL地址(也有可能是一放制定好,双方都按照执行即可)。然后App开发者开始实现对应的功能:第一个是实现具体业务操作的功能,例如调取摄像头拍照;第二个是劫持H5中所有发送的URL地址,然后把符合事先制定的规则的URL拦截下来,通过解析URL后面的参数值等调取对应的功能实现需求即可。下面是H5部分的代码样本:

     function fn(img){         //->打开摄像头拍照后执行的后续操作 img是拍下来的照片     }     window.location.href="zhufeng://phone?callback=fn";     //->zhufeng:// 就是我们事先制定的一个假协议,所有这种协议的都代表需要调取App的某个功能     //->phone 这个标识就是事先制定的需要调取拍照功能     //->callback=fn 把自己JS中的某一个方法传递给App,App可以在拍照完成后执行这个方法,并且把保存的照片传递给这个方法(类似于JSONP) 

目前移动市场还没有完全的成熟,技术也在不断的变革,但是我坚信HTML5和JS的市场份额会越来越大,逐渐的将会替代Native App,而是由Web App来引领移动市场的潮流...

(以上内容和观点只代表个人的想法,如有不同意见欢迎PK。)

上一篇: html5培训系列之检测浏览器的类型(PC端还是移动端)

下一篇: 让你快速进行web前端开发的途径-LESS学习:了解LESS和编译LESS