永恒的问题，什么或什么时候更好？本地移动？混合移动？
继续（这些是我个人的看法，不一定是“普遍论据”）：
语言
Native Mobile ：使用 Swift (iOS) 或 Java (Android) 等“严肃的语言”构建。严肃的意思是：静态类型，良好的 OOP 和速度。
混合移动 ：基于可怕的 JavaScript（弱类型、糟糕的 OOP、不如本地语言快），不幸的是，如果你的应用程序 UI 很复杂，你必须准备好大量笨拙的 JS。在纯 Web 中，你有 GWT、Dart... 来生成 JS，在移动 Web 中，JS 很难避免。
UI 对平台的保真度
Native Mobile ：准备就绪。只需使用默认的原生组件，您就可以获得完美的原生 UI 外观和感觉。
混合移动 ：您必须使用模拟本机 UI 的移动工具包，并为您的应用程序的各个部分制作两个可视化版本（iOS/Android）。
访问本机 API
本机移动 ：直接和无限制访问（仅应用应用程序的安全限制）。
混合移动 ：您必须使用移动工具包，因为来自 JavaScript 的本机访问不是无限的，例如在 Android 中，JS 代码调用的本机（Java）方法必须在接口中定义，这是移动工具包 API 的工作.如果您需要更强大的集成，请准备好使用本机 Java 进行编程。事实上，使用术语“混合”是因为许多混合应用程序实际上是混合原生网络，也就是说，一些架构元素是原生的（菜单等）而其他部分是网络呈现的。有些事情很烦人，比如 JS 和 native 代码之间必要的异步调用（例如，在 Android 中，JS 代码在不同于主线程的独占线程中执行）。
发展业绩
也许这是本次分析中最自以为是的项目。
在我看来，由于语言、工具、自然的原生集成，原生开发比混合开发更有效率……是的，你必须制作两个 (iOS/Android) 应用程序，通常是两个团队。两个团队的表现在质量和开发性能上都超过了“一个混合团队”。有些东西可以像谷歌那样使用 Java-Objective C 生成工具进行数据管理等重用。我承认，如果您需要支持 Windows Mobile，优势就不是那么大了。
调试/测试
原生移动 ：原生工具就足够了。
Hybrid Mobile ：调试工具有所改进，但与原生不在同一级别。
版本管理
在本主题中，我们必须区分两种类型的混合应用程序：
-
行为/UI（HTML/JS）主要是本地的。本质上，混合应用程序是独立的，与本机应用程序没有什么不同。
-
Behavior/UI主要是远程下发。从本质上讲，混合应用程序就像一个打包到本机应用程序中的移动网站。
如果您的应用程序是类型 2，那么您很幸运，版本管理比原生应用程序容易得多，在原生应用程序中，微小的 UI 更改和行为需要新版本，并且您必须保持与旧版本的兼容性，因为升级是最终用户。这就是混合开发大放异彩的地方。
我怀疑 Amazon Shop 应用属于这种类型 2：
http://www.theserverside.com/news/2240174316/How-Amazon-discovered-hybrid-HTML5-Java-Android-app-development
“将 HTML5 整合到您的移动应用程序中的最令人信服的理由是获得更新应用程序的能力，而无需在设备用户端进行升级。这种能力使得管理应用程序既容易又安全——允许开发人员推出或根据需要撤回更新。在持续部署和实时测试的美丽新世界中，这是一个巨大的优势”
顺便说一下，这种类型 2 是
ItsNat Droid
开发的原因。
ItsNat Droid：远程交付的本机 UI（和可选行为）。
享受！
