Hybrid App 开发实战

阅读数:71433 2013 年 9 月 3 日

话题:语言 & 开发架构

【引言】近年来随着移动设备类型的变多,操作系统的变多,用户需求的增加,对于每个项目启动前,大家都会考虑到的成本,团队成员,技术成熟度,时间,项目需求等一堆的因素。因此,开发 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,或者扫描下方二维码加关注。