原生 or 混合 ? 關於應用永不停息的爭論

OneAPM官方技術部落格發表於2015-07-23

摘要：原生應用和混合應用的爭論愈演愈烈。在移動技術的世界，我們需要了解本地應用和混合應用的利弊。

【編者按】作者 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 官方部落格。

相關文章