摘要:原生应用和混合应用的争论愈演愈烈。在移动技术的世界,我们需要了解本地应用和混合应用的利弊。

【编者按】作者 Jose Maria Arranz是 ItsNat AJAX Java web 、ItsNat Droid Android framework 等的网站的创始人,本篇文章中,Jose 通过对比原生应用和混合应用的诸多利弊,让更多的人了解到两者之间的区别,根据需求选择更适合的类型应用。

混合还是本地?这是一个问题。针对这一问题我也来说两句(以下纯属个人观点)。

语言

原生应用:使用「严肃的语言」,比如 Swift(iOS)或 Java(Android)。「严肃」意味着:静态类型、良好地面向对象技术和快速。

混合应用:基于可怕的 JavaScript 语言(弱类型,不够好的 OOP,没本地语言那么快),不幸的是,如果你的应用界面相当复杂,你就须要做好准备来堆积大量笨拙的 JavaScript 语言。在纯 Web 下你有 GWT、Dart......来生成 JavaScript,在移动网络中避免使用 JavaScript 是件很困难的事。

与平台统一的用户界面

原生应用:触手可及、方便使用。只需使用默认的本地组件,就能得到一个完美的本地界面外观和感觉。

混合应用:必须使用移动工具来模拟本地用户界面,同时需要生成两个视觉版本(iOS / Android)。

访问本地 API

原生应用:直接且无限制的访问(仅适用于应用程序的安全限制)。

混合应用:必须使用移动工具,因为从 JavaScript 本地访问并非无限制,比如在 Android 中,由 JavaScript 代码调用的原生(Java)方法,必须在接口中定义好,这是移动工具包 API 的工作。如果你想要更强大的整合,需在本地 Java 语言下完成编程。事实上,所谓「混合」是因为许多混合应用是真正的混合本机网络,也就是一些基础元素是本机的(menues等),其他部分则由 Web 呈现。有些事情的确麻烦,比如 JavaScript 和本地代码之间必要的异步调用(例如,在 Android 上的 JavaScript 代码,在不同的主线程的线程独享执行)。

性能开发

这也许是本文主观性最强的部分。

在我看来,原生应用的发展远远超过了混合型,比如语言、工具、自然的原生整合等。是的,你必须做两款(iOS / Android)的应用程序,通常需要两个团队。两个团队在质量和发展方面的表现,都远远优于「一个混合队」。某些部分可以重复利用,比如数据管理使用的一个类似 Google 的 Java-Objective C 生成的工具。在我看来,如果需要支持视窗移动化,那它的优势并不是很大。

调试/测试

原生应用:本地工具已经非常好用。

混合应用:调试工具有很大改进,但与本地工具不可同日而语。

版本管理

在这个部分中,我们必须分清两种类型的混合应用之间的区别:

  1. 行为/用户界面(HTML、JS)通常是在本地。本质上说混合应用是自带的,这一点不同于本地应用。
  2. 行为/ 用户界面主要靠远程传输。本质上,混合应用就像是将一个移动网站,打包进一个原生应用中。

如果你的应用程序是类型 2 就好说了,版本管理远比原生应用更容易。在原生应用中,任何细微的 UI 变化和行为都需要一个新版本,你还得保持与旧版本的兼容,毕竟更新最终依赖用户完成。所以这的确是混合应用发展的发光点。

我怀疑亚马逊商店的移动版就是类型 2:

http://www.theserverside.com/news/2240174316/How-Amazon-discovered-hybrid-HTML5-Java-Android-app-development

「在移动应用中使用 HTML5 最重要的原因在于,在更新应用的过程中,无需依靠用户来升级。这种能力使得管理应用变得更容易、更安全——允许开发者根据需要进行更新。在移动技术世界的持续发展和现场测试中,这将是一个巨大的优势」。

原文地址:Native Mobile vs. Hybrid Mobile: The Eternal Question

本文系 OneAPM 工程师编译整理。OneAPM 是应用性能管理领域的新兴领军企业,能帮助企业用户和开发者轻松实现:缓慢的程序代码和 SQL 语句的实时抓取。想阅读更多技术文章,请访问 OneAPM 官方博客