当前位置 : 主页 > 手机开发 > 其它 >

真正的Hybrid APP没你想的那么简单

来源:互联网 收集:自由互联 发布时间:2021-06-12
很多开发者在跨入移动应用开发领域都会选择Hybrid App为切入点,因为它介于web-app、native-app这两者之间,兼具“Native App良好用户交互体验的优势”和“Web App跨平台开发的优势”。这样

很多开发者在跨入移动应用开发领域都会选择Hybrid App为切入点,因为它介于web-app、native-app这两者之间,兼具“Native App良好用户交互体验的优势”和“Web App跨平台开发的优势”。这样的模式可以降低开发门槛,用较少的成本达到跨平台开发移动应用的目的。

  在移动应用开发盛行的今天,HTML5的问世让更多的人寄予厚望,这也就催生了PhoneGap这类移动应用开发Hybrid框架,它完全采用HTML5的界面布局,而本地能力通过Native桥接为JS函数在HTML5页面中调用,达到Hybrid App的效果。

  然而,Hybrid App的精髓在Hybrid,也就是混合上,既然是混合,就要考虑到混合比例,就像钢筋混凝土,如果混合比例不当就会让一个建筑摇摇欲坠。

  一般,Hybrid App的混合主要包含两部分,一部分是Native,一部分是Web。但不管是Native还是Web,都具有各自的UI和布局能力、数据交互能力和脚本调用能力等。所以,Hybrid App更是一种开发模式,如何有效混合使用是个很大的技巧。笔者经过多种Hybrid开发框架的使用,进行了一些总结,希望与开发者一起探讨和了解Hybrid。

  根据混合的程度,Hybrid App通常分为三种类型:Web主体型、多View混合型、单View混合型。

  Web主体型:

  移动应用的主体是Web View,即主要以网页语言编写界面,穿插Native功能的Hybrid App开发类型。appMobi、PhoneGap都属于Web主体型移动应用中间件。

  HTML5作为一个HTML 4.0.1和XHTML 1.0的升级版,基于旧版本有更强大的表现功能,并加入了Local Storage等技术,确实为Web页面提供了更大的想象空间和更多的可能性。但HTML 5处在目前的发展阶段,受到浏览器兼容性和手机硬件性能水平的影响,它所能提供的功能与Native仍然有很大差距。

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

  多View混合型:

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

  单View混合型:

  即在同一个View内,同时包括Native View和Web View。互相之间是覆盖(层叠)的关系。这种模式可以很好的让Native View和Web View和谐共存,充分发挥Native和HTML5的优势,最小可以达到控件级的Native界面交互体验。烽火星空的ExMobi和Titanium就是具有这种特性的框架,它们可以让开发者更加灵活的做出选择,而不需要考虑太多的成本因素。

  另外,不管是哪种类型的Hybrid框架,以HTML5为开发主体的做法可能导致的各种浏览器兼容性问题以及用户体验和界面性能问题,都让开发者需要思考,Native在Hybrid中的作用以及Native 的使用方式。

  在Hybrid App中,Native 的使用方式也有讲究,主要包括:纯原生程序方式调用、JS桥接类调用和标签库插件方式调用。

  纯原生程序方式调用:

  即完全编写纯原生程序来实现Native效果,比如AppCan、PhoneGap等,这种方式虽然可以完全调用原生的所有能力,由于结构化不强,需要开发者独立编写不同平台的原生程序,门槛很高,所以对于大部分开发者是不合适的。

  JS桥接类调用:

  这种方式通过把Native的能力统一封装为JS桥接类,通过编写JS即可绘制原生界面,达到Native效果,但是由于其封闭性和语法的特殊性,很多开发者很难适应这种写法,不仅JS的轻量级特性没有很好发挥,还无端增添了开发者的开发难度。就像拿篮球来当足球踢一样,不仅踢不出足球的灵活,反而降低了活动的趣味性。

  所以,JS桥接类一般更适合提供非界面的原生能力,对于绘制界面则显得有些力不从心。

  标签库插件方式调用:

  标签库是指跟HTML5标签类似一种标签语法,这种标签通过Native View方式来解析展示,而不是通过Web View方式展示,这就大大降低了开发者的调用难度,通过编写简单标签即可实现复杂的Native效果,并且这种方式的标签完全可以扩展,通过插件的方式运行在Hybrid App框架中,对于开发者有更多的灵活选择,而且很容易模块化,达到标签库的复用和扩展。比如烽火星空的ExMobi就是这样的方式调用Native界面的,它不仅可以不需要写原生程序,更是采用了比写JS还简单的标签库方式来让开发者调用,即可达到Native效果。

  笔者认为,真正的Hybrid App框架并不局限于PhoneGap、Appcan这样的传统开发框架那么简单,它既不是在HTML5的外表下套个壳,也不是HTML5和Native的各自为政。做为一种开发模式,Hybrid App框架技术也在不断变革,就像烽火星空的ExMobi那样具备强大的Native布局能力和HTML5的灵活展现能力,能够让Native和HTML5可以友好共存,并以标签化的方式更方便开发者的随意调用和扩展。选择具有强大技术实力的Hybrid App框架对开发者提供的不仅仅是便捷,而是一种先进的开发模式和思维方式。

  除此之外,ExMobi框架提供开发上的便捷,还包括对OFFICE文档的转换能力、推送的统一处理、数据的压缩和加密、应用的下载和更新、对不同数据的集成能力和统一的转换能力以及持续更新的本地能力调用。

  而且,在不少CIO看来,Hybrid App框架不仅仅是提供开发上的能力,它只是整体的企业移动战略中的一部分,应用的管理、设备的管理、应用不同层面的安全需要以及灵活的部署模式也都是企业移动战略中的核心部分,如果开发者全部自己实现将是很大的工作量,所以选择一个平台型的Hybrid App框架是很有必要的。烽火星空的ExMobi就是这样的一个基于Hybrid App的移动应用平台,它从开发(IDE环境)、集成(IT系统对接、云服务)、打包(各个操作系统的应用打包)、发布(应用的运行)、管理(日志管理,更新管理)上提供了一套完整的移动化应用解决方案。所以,建议开发者根据自己的实际情况,选择合适的Hybrid App框架

网友评论