转载来源: http://www.infoq.com/cn/articles/hybrid-app-development-combat

特性

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

解决方案

  • 方案一：使用 PhoneGap、AppCan 之类的中间件，以WebView作为用户界面层，以Javascript作为基本逻辑，以及和中间件通讯，再由中间件访问底层API的方式，进行应用开发。这种架构一般会非常依赖WebView层的性能。
  • 方案二：使用 Adobe Air、RubyMotion、Appcelerator 或者是 Xamarin 这种非官方语言的工具，打包成原生应用的方式开发。为什么笔者会将它们定义为 Hybrid App，主要是它们并没有很单纯地使用原生提供的语言进行开发，而是通过对开发者提供友好的开发工具，并折中地把这种开发语言转换成原生语言，最终打包出整个应用，所以也属于混合应用范畴。
  • 方案三：在开发原生应用的基础上，嵌入 WebView 但是整体的架构使用原生应用提供，一般这样的开发由Native开发人员和Web前端开发人员组成。Native 开发人员会写好基本的架构以及 API 让 Web 开发人员开发界面以及大部分的渲染。保证到交互设计，以及开发都有一个比较折中的效果出来，优化得好也会有很棒的效果。（当年 Facebook Three20 就使用该方案）

方案一（Web架构为重）

优点：

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

缺点:

  • 虽然说你可以专注在界面以及交互开发上了，但是这页会成为一个缺点，比如说要仿造一个 iOS 的默认设置界面，就需要大量的 html 以及 css 代码了，而且效果不一定和 iPhone 上面的界面一样好。
  • 正因为这是跨平台的开发，所以还是这句话：兼容是前端的痛。了解过在Android机器上面的Web开发就知道这个痛了。
  • 便于调试其实是在Web界面层的。但是实际上做 Hybrid App 开发的时候，你会遇到需求，进入手机的底层请求，做某些处理。

方案二（编译转换方式）

优点：

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

缺点：

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

方案三（Native 架构为重）

优点：

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

缺点：

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