技术库 > Object-C

hybrid app

技术库:tec.5lulu.com

1 简介

“云”时代的来临正在改变App和运营团队之间的关系,一场不能避免的变革正在进行。鉴于移动终端的局限性,移动终端上的APP由本地化应用(Native App),到混合型应用(Hybrid APP),再到基于WEB的应用Web App,这一连串的变化都源于技术的更新和市场的需要。
Hybrid App是指介于web-app、native-app这两者之间的app,它虽然看上去是一个Native App,但只有一个UI WebView,里面访问的是一个Web App,比如街旁网最开始的应用就是包了个客户端的壳,其实里面是HTML5的网页,后来才推出真正的原生应用。  

2 兴起原因

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混战之时,偶然间的在移动应用开发领域占有了一席之地。

3 分类

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开发类型。这种类型开发的移动应用体验相对而言存在缺陷,但整体开发难度大幅降低,并且基本可以实现跨平台。Web主体型的移动应用用户体验的好坏,主要取决于底层中间件的交互与跨平台的能力。国外的appMobi、PhoneGap国内的AppCan和Rexsee都属于Web主体型移动应用中间件。其中Rexsee不支持跨平台开发。appMobi和PhoneGap除基础的底层能力更多是通过插件(Plugins)扩展的机制实现Hybrid。而AppCan除了插件机制,还提供了大量的单View混合型的接口来完善和弥补Web主体型Hybrid App体验差的问题,接近Native App的体验。

from:tec.5lulu.com

从分析可见,Hybrid App中的Web主体型只要能够解决用户体验差的问题,就可以变成最佳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有以下的特性:

  1. 开发时可能不采用或者大部分不采用原生语言,但是却有所有原生应用的特性;
  2. 架构方案会和原生有出入,基本由工具而定;
  3. 具有跨平台特性;
  4. 一般开发相对原生开发的方式要简单。

4 Native App

Native App毫无疑问是最可靠的方案。但是学习成本,人才成本,开发效率以及照顾不同平台的特性去考虑,都成为了开发人员心目中的一道坎。至于说这道坎是不可逾越的还是一道让你提高的坎,笔者觉得完全取决于你自己。基于种种因素的考虑,估计很多人就会选择折中的方案到了Hybrid App的开发行列当中,包括笔者自己也是这样过来的。

下面更多的内容都将围绕Hybrid App开发展开讨论。

5 Hybrid App在开发当中的优点和缺点

在Hybrid App的开发过程中,几种不同的方案笔者都有经历过。当然也经历到了Native App的开发阶段。在如此纠结复杂的过程中给了笔者不少的经验,下面笔者也会就自身的经验和大家分享这些方案当中的优缺点。对于初入行的朋友,笔者是从Web前端入行的,毕竟门槛较低,而且能够快速地培养自己的信心以及对代码的感觉。深入后就开始接触到移动开发这块了。所以会先从Hybrid App的第一种方案说起吧。

方案一(Web架构为重)

优点:

  1. 全Web开发,一定程度上有利于Web前端技术人员快速地构建页面样式;
  2. 有利于在不同的平台上面展示同一个交互层;
  3. 便于调试,开发的时候可以通过浏览器的方式进行调试,工具丰富。

缺点:

  1. 虽然说你可以专注在界面以及交互开发上了,但是这页会成为一个缺点,比如说要仿造一个iOS的默认设置界面,就需要大量的html以及css代码了,而且效果不一定和iPhone上面的界面一样好;
  2. 正因为这是跨平台的开发,所以还是这句话:兼容是前端的痛。了解过在Android机器上面的Web开发就知道这个痛了。比如前些年在Android设备上面写圆角,border-radius:10px,在Android的设备上面会出现毛边。
  3. 便于调试其实是在Web界面层的。但是实际上做Hybrid App开发的时候,你会遇到需求,进入手机的底层请求,做某些处理。比如说如果该应用有Push Notification服务的话,你就需要到底层,获取Push Notification发生时的数据,以及做相应的交互处理。当然类似PhoneGap这类框架,已经有很好的插件机制去帮助你解决类似的问题,当然还有Game Center之类的插件,具体的话可以到Github去关注PhoneGap官方的账户,资源非常丰富;

方案二(编译转换方式)

优点:

  1. 利用自己熟悉的语言,进行应用开发,比如RubyMotion,就是使用Ruby语言去做iOS开发,开发起来的话,代码量是数量级地下降啊。
  2. 部分开发工具提供跨平台的功能,让你的应用能够快速地发布到不同的平台上面。比如Mono社区的Xamarin,就是典型的例子了。使用C#语言,能够把你的应用发布到iOS,Android以及WinPhone市场上面;
  3. 开发出来的程序运行高效。大部分这种架构的应用,其实还是非常依赖底层的东西的,而且包括界面的东西,都是使用原生的API,效率就当然要比类似于PhoneGap这种架构要好了;

缺点:

严重依赖于其工具厂商提供的工具包,调试的时候就要有全套的工具。当然一般来说这些厂商都会以收费的形式发布他们的工具,相应的也有客服提供技术支持。遇到系统升级,第三方sdk升级,开发工具出现bug等,那么就要等待工具厂商解决了。相当于把风险压在对方身上了,自己却要承担责任。

方案三(Native架构为重)

优点:

  1. 这无疑是最稳定的Hybrid App开发方式了,交互层的效率上由Native的东西解决了,而且架构上基本就是在App内写网页,连App Store都是采用了该种方案;
  2. 开发时分工非常明确,底层的由iOS开发人员处理,上层的由Web前端开发人员处理;
  3. 有效的在线参数配置方式,以便于及时在线替换界面;

缺点:

  1. 团队至少需要两个工程师,一个是Web的,一个是iOS的。当然如果开发人员会两种技术也可独立承担;
  2. 还是运行效率,要权衡好多少界面采用Web来渲染,毕竟WebView的效率会相对降低,以前Facebook就是因为Web的渲染效率低下,把整个应用改为原生的解决方案。当然这里面可以通过优化来解决。但是优化也是有限度的,如Ruby创始人Matz所说优化要恰当(包括花的时间,技巧等),而且有时候的优化达到的回报率不一定达到你自己的期望。

6 Hybrid App和Native App开发对比

因为方案三中的思想基本上就是原生应用的开发思想了。这里要做的对比应该不算大,因此笔者不会做太多的阐述介绍两者的不同。但是如果是偏重Web架构的,或者是以方案二这种透过特殊工具开发的,就和原生开发有对比了。这次笔者暂时会以方案一拿来讨论。讨论中主要会以架构,代码管理上来讨论,当然也会说到部分细节。

架构讨论:

因为这是偏重于Web开发的应用,这里面就需要开发人员有很强烈的大型Web前端架构思想在里面。提到这里可能马上浮现在你脑海中的词语就是:angular.js,require.js,sea.js,backbone.js等。没错,这些工具都能够帮助你快速地梳理好思路,管理好你的Web应用。对开发者最友好的,发挥空间最大的非PhoneGap莫属了。所以笔者就会以PhoneGap应用展开讨论。(因为类似Sencha也有提供方案,但是Sencha本身是一个重量级的框架,而且有自己的思想在里头,加上他本身也提供开发工具,在这里就不适合讨论了。对于开发者来说可以根据自己的需求选择好工具)

1)Native APP:Native Code编程,代码编译之后以2进制或者字节码的形式运行在OS上,直接调用OS的Device API;

2)Web APP,以HTML+JS+CSS等WEB技术编程,代码运行在浏览器中,通过浏览器来调用Device API(取决于HTML5未来的支持能力):

3)Hybrid APP,部分代码以WEB技术编程,部分代码由某些Native Container承担(例如PhonGAP插件,BAE插件),其目的是在HTML5尚未完全支持Device API和Network API的目前阶段,承担这部分职责。

 

 

hybrid app,by 5lulu.com


hybrid app


本文链接 http://tec.5lulu.com/detail/108aan4wm61sz8sa0.html

我来评分 :6.1
0

转载注明:转自5lulu技术库

本站遵循:署名-非商业性使用-禁止演绎 3.0 共享协议

www.5lulu.com

相关文章
1hybrid app