BT

Hybrid App开发实战

作者 李秉骏 发布于 2013年9月4日 |

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

【摘要】笔者将从Hybrid App的开发现状出发,阐述Hybrid App的优缺点,同时对比Hybrid AppNative 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层:

 /js
          mainView.js
          settingView.js
          networkObject.js
          renderObject.js

     /lib
          /PhoneGapPlugins
               push-notification-plugin.js
               pickerView.js
          PhoneGap.js
          zepto.js
          jquerymobile.js
          iscroll.js
          angular.js
          jade.js

     /css
          /mainView
               listItemTemplate.css
               questionListTemplate.css
          /settingView
          /personView
          /layout
               navigationBar.css
               tabButton.css
          app.css

     /template
          /mainView
               listItemTemplate.txt
               questionListTemplate.txt
          /settingView
          /personView
          /layout
               navigationBarTemplate.txt
               tabButtonTemplate.txt

     index.html
     app.js
     require.js

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

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

就是如此简单。

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

 demoApp
          /Resource
               navigationBar.png
               navigationBar@2x.png 
         /demoApp
               AppDelegate.h
               AppDelegate.m
               /SettingViewController
                    settingViewController.h
                    settingViewController.m
               /MainViewController
                    mainViewController.h
                    mainViewController.m
               /Supporting Files
                    demoApp-Info.plist
                    InfoPlist.strings
                    ...
          /plugin
               /AFNetworking
                    AFHTTPClient.h
                    AFHTTPClient.m
                    AFHTTPRequestOperation.h
                    AFHTTPRequestOperation.m
                    ...
          /Frameworks
               CoreData.framework
               UIKit.framework
          /Products
               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>$('#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。每一种语言都会有其中的思想,每一种工具都有自己解决问题的方法论。多尝试就能够给自己带来更优秀的架构,更优秀的应用,提供给用户更好的体验。当然,也会有更好的回报。

关于作者

李秉骏(@CashLee李秉骏),HTML5技术活跃分子,HTML5梦工场高级成员,投入Web开发多年。高中开始编写独立运营的电子商务网站。近年多进行移动应用前后端的开发,并尝试将混合应用开发技术运用于实践当中。

关注IT趋势,承载前沿、深入、有温度的内容。感兴趣的读者可以搜索ID:laocuixiabian,或者扫描下方二维码加关注。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

挻好,继续努力 by 林 冲

这章文件挻好的,期待作者后续可以分享自己专业领域范围内的一些经验。

感觉缺了很多东西 by Huang Guan

Titanium Mobile
Sencha Touch
像jquery mobile和angularjs只能做做webapp,做hybrid app跟原生一比就废了。

我们使用Hybrid开发,一年多了 by Lai Mead

一年多了,终于出了几个产品.哈哈

web app 或hybrid app体验确实是有大问题 by gan zhu

web app 或hybrid app体验确实是有大问题。ios据说是限制了浏览器的功能导致慢。有得有失,看具体环境选择恰当的工具。

的确是这样 by Zeng Shuyan

最近在学习和尝试跨平台的东西,作者提到的很多问题都遇到了。
看完这篇文,觉得自己至少可以少走点弯路吧,谢谢作者!

很棒 by Jincheng LI

很理性~

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

6 讨论
提供反馈
错误报告
商务合作
内容合作
Marketing
InfoQ.com及所有内容,版权所有 © 2006-2016 C4Media Inc. InfoQ.com 服务器由 Contegix提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司 京ICP备09022563号-7 隐私政策
BT