摘要：原生应用和混合应用的争论愈演愈烈。在移动技术的世界，我们需要了解本地应用和混合应用的利弊。
【编者按】作者 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 生成的工具。在我看来，如果需要支持视窗移动化，那它的优势并不是很大。
调试/测试
原生应用：本地工具已经非常好用。
混合应用：调试工具有很大改进，但与本地工具不可同日而语。
版本管理
在这个部分中，我们必须分清两种类型的混合应用之间的区别：
- 行为/用户界面（HTML、JS）通常是在本地。本质上说混合应用是自带的，这一点不同于本地应用。
- 行为/ 用户界面主要靠远程传输。本质上，混合应用就像是将一个移动网站，打包进一个原生应用中。
如果你的应用程序是类型 2 就好说了，版本管理远比原生应用更容易。在原生应用中，任何细微的 UI 变化和行为都需要一个新版本，你还得保持与旧版本的兼容，毕竟更新最终依赖用户完成。所以这的确是混合应用发展的发光点。
我怀疑亚马逊商店的移动版就是类型 2：
「在移动应用中使用 HTML5 最重要的原因在于，在更新应用的过程中，无需依靠用户来升级。这种能力使得管理应用变得更容易、更安全——允许开发者根据需要进行更新。在移动技术世界的持续发展和现场测试中，这将是一个巨大的优势」。
原文地址：Native Mobile vs. Hybrid Mobile: The Eternal Question
本文系 OneAPM 工程师编译整理。OneAPM 是应用性能管理领域的新兴领军企业，能帮助企业用户和开发者轻松实现：缓慢的程序代码和 SQL 语句的实时抓取。想阅读更多技术文章，请访问 OneAPM 官方博客。