移动混合应用Hybrid App开发实战

移动开发
近年来随着移动设备类型的变多,操作系统的变多,用户需求的增加,对于每个项目启动前,大家都会考虑到的成本,团队成员,技术成熟度,时 间,项目需求等一堆的因素。因此,开发App的方案已经变得越来越多了。曾经有一段HTML5的小浪潮,无数的人参与或者看到过一个讨论:原生开发还是混 合开发,又或者是Web开发?到底最佳实践是怎样的,笔者认为只有实践过的人才会知道。尤其是在这个充满各种变数的移动互联网时代。

【引言】近年来随着移动设备类型的变多,操作系统的变多,用户需求的增加,对于每个项目启动前,大家都会考虑到的成本,团队成员,技术成熟度,时 间,项目需求等一堆的因素。因此,开发App的方案已经变得越来越多了。曾经有一段HTML5的小浪潮,无数的人参与或者看到过一个讨论:原生开发还是混 合开发,又或者是Web开发?到底***实践是怎样的,笔者认为只有实践过的人才会知道。尤其是在这个充满各种变数的移动互联网时代。

【摘要】笔者将从Hybrid App的开发现状出发,阐述Hybrid App的优缺点,同时对比Hybrid App与Native App的各自特性,***探讨一下Hybrid App的新思想方向。

Hybrid App现状分析

Web App

毫无疑问Web App就是成本***,最快速地解决方案了。尤其是近两年非常流行的响应式设计,Web App市场提供了非常好的实践场地。最近典型的Web App***案例是Sun天气应用了,其细节处理让人赞不绝口。

一般来说,拥有下面特点的就是一个Web App了:使用浏览器运行;纯Web前端架构,很多重要手机特性无法访问,例如联系人以及Push notification之类的;Single Page App;销售渠道多限于浏览器。

Hybrid App

所谓的Hybrid App其实会有不同的分支。而且会和Native应用有重合的地方。下面就说三种不同的解决方案。

方案一:使用PhoneGapAppCan之类的中间件,以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. 一般开发相对原生开发的方式要简单。

Native App

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

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

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所说优化要恰当(包括花的时间,技 巧等),而且有时候的优化达到的回报率不一定达到你自己的期望。

Hybrid App和Native App开发对比

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

架构讨论:

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

从工具上看:

Angular.js

用于双向绑定,网络请求,视图管理等工作。

Require.js

javascript模块化工具,在使用较多的交互对象,PhoneGap插件的时候,你就会发现一个强大的模块化工具会在开发的时候提供极好的帮助。能够帮助你把整体的代码,管理得井井有条。

Jade Template Engine

模板引擎。笔者个人比较推荐使用Jade,而且笔者本人也在博客中多次写到Jade在不同场景下使用的技巧的有关文章。主要是jade的语法太简洁了,而且面向JS开发人员非常友好。如果你还没有开始使用模板引擎,赶紧加入这个队列吧,你已经落后了。

Jquery Mobile

如果你暂时还没有一个设计师,但是又急于构造一个应用出来。jquery mobile就提供了多套不同风格的模板,供你使用,而且还含有不同的交互动画等。而且也是跨平台的。当然实际场景中,笔者觉得你会花很多时间在写css 上面,因为设计总是天马行空的。当然你还有很多工具啦,例如sass,以及less.js等。

PhoneGap.js或者Cordova.js

做Phonegap开发必须使用的代码库,用于和PhoneGap框架通讯。现在这个库已经改名了,是Cordova。具体为什么改名,得问Adobe咯。

PhoneGap Plugins

PhoneGap的插件能够帮助你快速地抵达手机的其他API上面,直接使用Javascript来操控这些底层的API。例如调用Push Notification的相应发生的事件。

从代码目录上面看混合应用中的Web层:

  1. /js 
  2.           mainView.js 
  3.           settingView.js 
  4.           networkObject.js 
  5.           renderObject.js 
  6.  
  7.      /lib 
  8.           /PhoneGapPlugins 
  9.                push-notification-plugin.js 
  10.                pickerView.js 
  11.           PhoneGap.js 
  12.           zepto.js 
  13.           jquerymobile.js 
  14.           iscroll.js 
  15.           angular.js 
  16.           jade.js 
  17.  
  18.      /css 
  19.           /mainView 
  20.                listItemTemplate.css 
  21.                questionListTemplate.css 
  22.           /settingView 
  23.           /personView 
  24.           /layout 
  25.                navigationBar.css 
  26.                tabButton.css 
  27.           app.css 
  28.  
  29.      /template 
  30.           /mainView 
  31.                listItemTemplate.txt 
  32.                questionListTemplate.txt 
  33.           /settingView 
  34.           /personView 
  35.           /layout 
  36.                navigationBarTemplate.txt 
  37.                tabButtonTemplate.txt 
  38.  
  39.      index.html 
  40.      app.js 
  41.      require.js 

从代码的目录上面看,就是经典的静态网页文件的目录,非常简单。下面就用一句话来说说整个应用的运作过程吧:

打开PhoneGap应用 ->进入 index.html ->运行require.js ->加载应用资源 -> app.js 控制整个应用 -> angular.js 进行事件绑定以及视图渲染 ->视图渲染的时候会将数据和加载好的视图模板(template目录下的代码)处理 ->经过jade模板引擎 ->渲染到相应的位置上

就是如此简单。

看完了简单的PhoneGap应用后,笔者们来看看简单iOS应用在开发时候的代码目录吧。思路上还是非常相似的。在这里面,笔者不会深入代码部分去讨论具体的实现以及细节上的东西。

  1. demoApp 
  2.           /Resource 
  3.                navigationBar.png 
  4.                navigationBar@2x.png  
  5.          /demoApp 
  6.                AppDelegate.h 
  7.                AppDelegate.m 
  8.                /SettingViewController 
  9.                     settingViewController.h 
  10.                     settingViewController.m 
  11.                /MainViewController 
  12.                     mainViewController.h 
  13.                     mainViewController.m 
  14.                /Supporting Files 
  15.                     demoApp-Info.plist 
  16.                     InfoPlist.strings 
  17.                     ... 
  18.           /plugin 
  19.                /AFNetworking 
  20.                     AFHTTPClient.h 
  21.                     AFHTTPClient.m 
  22.                     AFHTTPRequestOperation.h 
  23.                     AFHTTPRequestOperation.m 
  24.                     ... 
  25.           /Frameworks 
  26.                CoreData.framework 
  27.                UIKit.framework 
  28.           /Products 
  29.                demoApp.app 

Objective-C 是一种通用、高级、面向对象的编程语言。Objective-C是承自Smalltalk的信息传递模型(message passing)。Objective-C里,与其说对象互相调用方法,不如说对象之间互相传递信息更为精确。Objective-C强调面对对象编程, 且Objective-C中强制要求将类的(interface)与实现(implementation)分为两个部分。类的定义文件遵循C语言之惯例以 .h 为后缀,实现文件以 .m 为后缀。所以你会看到大量的类文件在里头,整个工程就是有不同的类构成的。(当然可能这么描述不太准确,但是便于大家理解)

这就和丰富的Web前端有很大区别了,在Web前端开发里有HTML,CSS,JS三剑客,必须要用好这三个东西才可以把整个应用才可构建出来。但 是在Native应用中,就很单一了。你只需要把握好Objective-C就可以了。因此对于原生应用来说,开发时只要遵守好规范,即使是一个新手参与 开发,也可以快速地上手,看懂代码。因为模式已经定好,大家使用同一套的API。按着流程走就好了。当然学习Objective-C需要过程,但是对于拥 有C语言,Java语言经验的开发者来说,是非常简单的事情。

当然,原生开发的缺点也很明显了,就是满足不了你的跨平台需求。

从代码目录上面看,其实也基本上看到笔者为什么使用多种JS库以及框架的原因了。主要的目的就是为了构建一个可维护的,具有规范性的Web应用。因 为本身Javascript这门语言非常灵活,100个人可以具有100种风格,加上没有专门对于Javascript开设的课程,在过往都容易存在对这 门语言的误解。基于种种的原因,就要约束好一个应用的代码风格,架构。此外,Javascript本身没有类的概念,所以在Javascript的面向对 象编程中:Javascript的数据和成员封装很简单。没有类,完全是对象操作。这和Objective-C有很大不同。这个时候必须要有一种心态处理 好整个Web应用:就是尽可能地抽象成对象,你的工作就是对象与对象之间存在交流。

另外有一些点是值得开发者注意的。对于原生应用来说,不管是iOS的,还是Android的,都会提供一套原生界面的库。以Objective-C 为例子。如果笔者需要调用Alert,笔者只需要编写:UIAlertView * alertView = [[UIAlertViewalloc]init];,就把这个view声明好了。再去执行相应的方法,就可以了。但是对于Web应用来说,就需要编 写<div id='alertView'><button>确定</button></div><script& gt;$('#alertView').show();</script>

,一堆的css代码和html代码去实现。当然你会询问笔者,直接写 alert() 不就可以了吗?要是真这么简单的话,建议你在iOS的WebView中编写一下alert,实现:title 是提示,内容是:alert view,确定按钮的文字是:好的。你就知道WebView的限制在哪里了。

因此要完成JS在Web App开发当中的***实践,肯定要学习优秀的思想和实现方法了。在这篇文章里面,笔者们暂时先不去做这种深入的讨论。而是先把例子抛给大家,也许会在下一次讨论的时候,再详细深入以下这两个项目。

***个是斯坦福的iOS开发公开课中的例子,使用objective-c实现,一个简单的卡牌游戏。这是经典的mvc开发了。项目地址如下:https://github.com/lbj96347/Stanford-W2013-CardGame,如果您正在使用Mac,那恭喜你,可以马上编译这个游戏进行测试以及代码浏览。

第二个是使用JavaScript编写的例子,实现同样的需求,做一个简单的卡牌游戏。但是使用的是HTML+CSS+JS开发。同样学习了继承以及mvc的思想。项目地址是:https://github.com/lbj96347/JSMatchismo ,再次恭喜你,不管使用什么电脑,都可以随时浏览代码以及运行该游戏。

Hybrid App的新思想

这两年多以来,因为市场的不同,也出现了不一样的需求,各个技术都有了新的发展。对于Hybrid App来说,其实都有了一些新的解决方案。为了解决问题其实最终思想都会被还原成以下几个点上:

  1. 根据需求,选择工具;
  2. 用适当的工具做适当的事情,有针对性地解决问题;
  3. 世界是平衡的,对于开发者来说,做的有用功越多,用户体验就越好,反之越差;
  4. 跨平台是一个"幌子",什么都做得到不代表什么都做得好

这也是笔者体验最深的几个点。而且你会发现Hybrid技术也基本在跟随这几个点来走。

根据需求,选择工具

如果你使用过Jquery Mobile,你做过过场动画(就是从一个view去到另一个view),过场动画在iOS的navigationController中很常见,而且很 简单,效果很好很流畅。在Jquery Mobile中使用ajax,css去实现了,核心代码可能就几十行。可能跟iOS里面的差不多(如果包含动画),但是实际出来的效果却差强人意。会出现 类似的问题:页面抖动,感觉不连贯,在部分的设备下运行缓慢。如果你的应用要求的体验并不是很高,例如一些新闻展示类应用,更强调排版。这里小小的体验差 距,就可以忽略了。(因为英国BBC就是这么干的),但是如果你的应用非常强调体验细节,这里的解决方案可能就不适合了。或许你要做优化,但是优化的时间 可能足以够你去学习更多的东西了。这样的话,你是继续选择用一个不成熟的工具,还是选择去学习一种新的语言呢?所以还是根据需求而定吧。

另外一个例子。曾经有人跟笔者提及到,在使用HTML和CSS编写应用界面时确实很爽,但是效率不咋的。那为什么不尝试把应用内容直接搬到 Canvas里面呢?构造一套足够强大的工具,一套足够彪悍的UI组件,把整个应用运行于Canvas中。这种想法是很好的,但是其实里面的短板页就出现 了,Canvas的性能虽高,但是里面的元素组件多了你可以保证效果高?所有的东西都会依赖于JavaScript,这对于Javascript来说要构 造足够强悍的面向对象的组件,也非简单之事,抛弃了CSS和HTML,意味着内部的设计组件能够高度定制,松耦合做得非常好。完全是实现了一套新的 xcode和ui库啊。这就不是在解决一两个问题了。既然有这么一个工具,笔者为什么不选择更好的,例如Xamarin。

用适当的工具做适当的事情

做游戏的朋友估计就深有体会了。为了解决Canvas性能的问题,越来越多的人和应用厂商(尤其是浏览器厂商),提供一种解决方案就是希望将 Canvas API和系统底层的API打通。意味着你只需要编写Canvas代码,实际做渲染的时候使用的是系统底层的东西,整体上提高了性能。例如Ejecta http://impactjs.com/ejecta 这个东西。

对于开发人员来说用Javascript编写游戏逻辑以及做各种控制都非常舒服,而且因为用的API相同,放到PC上(放开性能问题),同样可以运 行。这就真的做到了跨平台,但是又不缺乏效率。让笔者感触最深的就是@大城小胖在做混合应用(做游戏)时的做法,小胖的游戏架构。JS负责逻辑,引擎。 JS Binding绑定原生OpenGL,让原生的来做复杂的渲染处理。HTML CSS可以处理UI(比如一些Button)。这就是典型的:让工具去做其擅长的事情。

跨平台是一个"幌子"

为什么这么说?笔者不是一直希望大家能够跨平台么?是的。但是要真的认清这个坎。从IE兼容,到目前多个浏览器的乱战,到iOS以及Android 设备Web上的兼容,这不就是一个历史的例子嘛。跨平台不是不好,只是在一个时代里,你能够达到怎样的效果,真的是很难估量的。就好比你出国旅游,如果两 国关系非常好,而且很多惯例法律一致,对你来说不会造成太多负担。但是如果语言不一样,生活习惯什么的都不同,你就很难适应。同样是人,你很难在不同的环 境下生存。真正的跨平台,就意味着大家求同。这绝对不是一两天的事情,也非简单的事情。

那为什么还要跨平台。业务需求嘛。在这里必须就要遵守根据需求选择工具,用适当的工具做适当的事情,根据实际情况来作开发。如果可以,笔者觉得很有 必要都了解一遍,这样的话各种开发的思想就会影响到你,你就能够分辨到什么是好什么是坏,做更好的选择。例如笔者刚刚说到的过场动画的例子。其实完全可以 使用笔者说的混合应用中,方案三,去解决这个问题。你无非就是希望用navigationController做一个漂亮的过场动画嘛,在iOS中几句代 码就实现了。

再说一个例子吧,如果你正在做一个todo-list的应用,其实无非就是简单存储数据以及做一些相关界面渲染。在使用原生的控件的话,有大堆的代码要写,而且还要处理好内存问题。但是其实如果使用Web的方式实现,比如backbone.js。总体代码可能100行左右。就把整个应用实现了,包括本地存储。你要做的事情就是把整个界面搭建得漂亮些。可能就1个小时的工作。但是如果用原生开发,很难保证到一个小时内完成,因为调试编译都需要时间吧?况且还有界面呢。

所以要认清跨平台这个"幌子",并非所有的问题都用同一个方法处理。笔者们要融汇贯通嘛!

总结和笔者的感受

对于做Web App的坑,其实挺多的。这里无法一一表达。但是相信实践过就会知道如何更好地绕过这些坑(例如笔者说的过场动画的例子)。那么对于开发者来说要有坚强的 毅力,努力去实践,满足自己永远不能满足的好奇心,因为最终的经验会给你带来不一样的感受,stay hungry。同时笔者们必须保持一颗学习的心,不断地吸收有营养的思想,学习新的知识,不要太容易满足,stay foolish。每一种语言都会有其中的思想,每一种工具都有自己解决问题的方法论。多尝试就能够给自己带来更优秀的架构,更优秀的应用,提供给用户更好 的体验。当然,也会有更好的回报。

责任编辑:闫佳明 来源: infoq
相关推荐

2013-03-19 09:08:42

Hybrid App

2013-12-16 15:07:59

NativeHybrid开发移动

2014-12-25 16:07:32

DHH混合移动应用Hybrid App

2013-09-04 15:07:06

移动应用设计

2013-10-09 09:10:28

移动应用开发NativeHybrid

2014-12-17 10:12:06

HybridAppFramewor页面布局

2014-12-08 10:03:47

IonicHybrid混合应用

2014-12-17 11:09:39

Hybrid AppWebView装载页面

2015-10-08 20:06:30

AppCanHybrid混合开发

2013-01-24 09:16:23

移动开发者移动应用开发

2017-02-15 10:22:23

移动应用开发

2017-11-20 20:06:59

APP移动Web

2014-12-17 10:43:01

Hybrid App平台开发

2011-12-12 10:08:39

jQuery MobiHTML5

2015-05-30 10:04:24

线下公开课51CTO沙龙MDSA

2014-12-18 13:40:16

Web AppHybrid AppNative App

2021-08-13 07:56:11

App移动应用

2013-09-13 13:16:05

2016-05-13 15:39:34

混合开发移动

2014-05-21 15:13:40

AppCanHybrid
点赞
收藏

51CTO技术栈公众号