一次編寫，隨處部署：何時原生化？

一次編寫，隨處部署 (WODE)已成為過去十年中許多開發框架的承諾，其目標是減輕編寫多個本機應用程序的痛苦。 由於其高昂的啟動成本、對開發團隊的影響以及逆轉的潛在不可行性，確定採取哪條路徑是項目經理必須做出的最關鍵的決定之一。

Ionic 等混合解決方案利用 Web 技術跨平台呈現應用程序，但最終產品通常無法滿足用戶對原生外觀和感覺的期望。

然而，即使是“原生”一詞最近也被編譯為原生代碼的框架（例如，React Native、Xamarin 等）混淆了。

本文分解了各種移動開發路徑的優缺點，並將它們與團隊構成、成本和用戶體驗進行權衡，以使產品經理能夠做出更明智的決定。

一次編寫，到處部署

一次編寫，隨處部署的概念是指開發團隊編寫一次應用程序的能力——使用單個開發堆棧、應用程序將在其上部署的平台的抽象——但仍保持部署能力應用程序適用於所有需要的平台，例如 Android、iOS、Windows 等。理想情況下，這是在不犧牲可維護性、性能或用戶體驗 (UX) 的情況下完成的。

移動應用程序開發的替代方法和歷史方法涉及為每個平台簡單地編寫一個單獨的應用程序的簡單過程，當然，這會帶來其自身潛在的高時間和資源成本。

一般來說，選擇發展路徑時要考慮的因素包括：

• 項目年齡
• 開發團隊的組成和規模
• 所需的分發平台
• 上市所需的時間表
• 如果必須，可用帶寬更改到另一條路徑

不幸的是，將這些因素中的每一個應用於每個可用的路徑，以及涉足關於該主題的無數可用意見，可能會非常令人生畏。 此外，這個過程常常讓項目經理不確定哪條路徑最能滿足應用程序的要求。

在高層次上，不同的移動開發路徑可以分為兩類：native 或 WODE，即，native 或其他一切。 簡而言之，一個人要么編寫本機應用程序，要么不編寫。 WODE 類別進一步分為兩組：

• 混合框架——那些利用 Web 技術在多個平台上呈現應用程序的框架。
• 非混合框架——那些使用原生 UI 組件（例如，按鈕、文本字段，甚至佈局管理器）而不是像混合框架那樣在應用程序內部呈現 Web 視圖的框架。

大多數 WODE 框架是混合的； 然而，為了改善混合框架的性能和用戶體驗限制，同時仍然提供 WODE 框架的好處，目前的趨勢是朝著非混合框架發展。 由於這種趨勢，React Native、Xamarin 和 Appcelerator 等框架越來越受歡迎。

這些路徑中的每一種——原生、混合和非混合——都有不同的優勢和劣勢，因此，每一種都有最適合的不同用例。 在考慮團隊構成、項目成本和用戶體驗等競爭優先級時，本文的其餘部分將分解每種移動開發路徑的優缺點。 除了一些專門的用例之外，編寫原生應用程序可以以略高的成本最大限度地提高用戶體驗。

一般來說，“一分錢一分貨”的格言適用，所以如果成本比客戶體驗更重要，那麼原生可能不是正確的選擇。 然而，一旦 UX 變得至關重要，原生應用程序成為明確的選擇，因為為了改進 UX，基於 WODE 的應用程序會以時間或原生專業知識的形式產生相當大的成本，這違背了選擇非原生應用程序的目的首先是發展路徑。

此外，即使支付了這筆費用，與原生產品相比，基於 WODE 的最終產品也將始終提供較差的用戶體驗。 因此，對於大多數開發團隊和大多數項目來說，native 幾乎總是正確的選擇。

本機應用程序

本機應用程序是用給定平台的核心語言編寫的。 例如，Android 應用程序是用 Java 編寫的，而 iOS 應用程序是用 Obj-C 或 Swift 編寫的。 它們要求開發工程師了解語言以及特定於平台的細微差別，例如第三方包集成、佈局管理、操作系統 (OS) 交互等。

優點

高度可定制。 由於每個應用程序都是使用本機組件編寫的，因此定制的唯一限制是與底層框架的接口，有時甚至沒有。 正如大多數本地開發工程師所證明的那樣，儘管界面有限，但通常有一種方法可以完成給定的任務。

通過瀏覽給定平台的支持社區可以找到這個想法的簡單證明。 儘管存在底層框架的限制，人們會發現許多關於如何完成一項可能“超出預定範圍”的任務的示例。

這種看似簡單的任務的具體 iOS 示例可能是在所有外部 UI 元素（例如選項卡欄、導航欄等）之上顯示全屏覆蓋。如圖 1所示，這通常超出了當前呈現的普通 UI 層。 因此，為了獲得全屏覆蓋，必須將其添加到視圖堆棧中選項卡欄上方的隱藏層。 這種定制通常只能在本機應用程序上進行。

最高性能。 正如預期的那樣，本機應用程序設置了性能基準。 由於大多數其他框架類型添加了一個或多個中間層，因此它們本質上比原生應用程序運行得更慢。

最可維護。 操作系統不斷變化。 時期。 當他們這樣做時，取決於是否進行了重大更改，應用程序必須及時更新，以免失去升級到較新操作系統的用戶群部分。 顯然，從用戶可以使用更改到更新應用程序之間的時間越短越好。 當沒有需要更新的依賴項來支持這個新的操作系統時，這個時間就會被最小化，在處理原生應用程序時就是這種情況。

缺點

附加資源。 在為多個平台編寫應用程序時，開發團隊通常由每個受支持平台的一名或多名移動軟件工程師組成。 當然，這本質上會增加開發團隊的規模和成本。 它還要求工程師團隊具有多種技能，而不是具有同質的技能基礎。 這有可能在支持和協作方面分散團隊。

開發週期較慢。 原生應用程序有可能具有較慢的開發週期，因為必須為每個所需平台編寫單獨的應用程序。 極端情況是團隊中只有一名移動開發工程師，因為每個應用程序基本上都是按順序編寫的。

性能低下。 既有優點又有缺點的表現似乎很奇怪。 一方面，本機應用程序為開發人員提供了足夠的空間來創建經過微調的高性能應用程序。 然而，另一方面，它們也給了開發者足夠的繩索來吊死自己。 如果他們不知道自己在做什麼，最後他們最多只能得到一個低於標準的應用程序。

注意：通常，這適用於所有框架路徑（本機、混合和非混合）。 如果開發應用程序的工程師對他們正在嘗試的事情沒有足夠的技能，那麼最終的應用程序可能既不能滿足設計要求，也不能被用戶很好地接受。

混合應用

混合應用程序通常使用 HTML/CSS/LESS 來設計用戶界面：MVC 設計模式中的“V”。 然後，“C”或控制器通常是用 JavaScript 編寫的——理想情況下，使用 JavaScript MVC 框架，例如 AngularJS。 與僅使用 jQuery 相比，使用 AngularJS 之類的框架可以更好地分離類和職責。

這種類型的混合框架堆棧的一個示例是由 AngularJS 支持的 Ionic 視圖層，它最終使用 PhoneGap 和 Cordova 在所需平台上轉換並呈現在 Web 視圖中。 顯然，這種類型的 WODE 框架是以增加複雜性為代價的。

此外，JavaScript 的使用帶來了其自身基於設計的限制和基於語言的問題。 本文的目的不是討論任何一種語言的優缺點； 然而，作為一名項目經理，在自己的移動技術堆棧中使用 JavaScript 的選擇不應該掉以輕心。 以下只是一些寫得很好的文章示例，說明為什麼應該盡可能避免使用 JavaScript：

• JavaScript 問題
  
• 為什麼我不是 React Native 開發者

優點

最小的開發團隊。 混合框架使小型開發團隊（尤其是主要知識庫是 Web 開發的團隊）能夠跨多個平台快速生成簡單的應用程序。 這允許項目經理保持團隊規模小，並消除團隊學習多個平台的本地語言和框架的需要。

更快的開發週期。 除了較小的團隊之外，混合框架在部署到多個平台時提供了更快的開發週期，因為只需要使用 Web 技術設計一個視圖層。

缺點

可能很差的用戶體驗。 只需要編寫一個視圖層的缺點是只剩下一個視圖層。 這可能會導致糟糕的用戶體驗，因為千篇一律的 UI 設計方法無法使應用程序的外觀和感覺在所有平台上的用戶都感到舒適和熟悉。 此外，由於混合應用程序本質上是嵌入在 UI 中的 webview，它可以給用戶一種他們實際上是在查看網頁而不是與原生應用程序交互的印象。 這種體驗幾乎總是對用戶滿意度產生負面影響，並最終影響留存率。

定製成本高。 通過為每個平台設計定制的 UI 來改進 UX 會產生復雜而獨特的 UI 框架，這些框架的創建成本可能很高，並且隨著時間的推移難以維護。 此外，為了創建有助於使應用程序脫穎而出的 UI 元素（例如，動畫、自定義視圖等），必須創建自定義橋接組件以將高級 UI 設計轉化為低級框架的東西，如科爾多瓦，會明白的。 一般來說，定制和改進混合應用程序的用戶體驗越多，它就越會減少快速且廉價的設計週期所帶來的好處。

性能較低。 由於混合應用程序在 web 視圖中呈現應用程序的視圖，因此在處理 OS 框架（例如，網絡、藍牙、設備上的聯繫人等）時，很可能會出現實現錯誤，從而導致性能大大降低。 還值得注意的是，即使由於一切都通過 web 視圖顯示，所以在性能方面非常小心，混合應用程序的最大性能將始終略低於其原生應用程序。

非平凡的插件管理。 還記得設計團隊花了數週時間打磨這些自定義功能，然後開發團隊創建了必要的橋接組件，以便 Cordova 可以使用它們嗎？ 好吧，除非有一個支持 Cordova 插件來支持團隊正在努力實現的目標，否則它們將無法工作。 這意味著兩件事之一：要么團隊自己創建它，要么需要找到合適的第三方插件來完成這項工作。 不幸的是，通常情況下，選項二不存在。 因此，它需要額外的開發時間來創建自定義插件，然後隨著時間的推移構建支持工作以管理應用程序所需的不斷增長的 Cordova 插件庫。 當然，當 Cordova 更新時，這些插件很可能也需要更新。

操作系統支持滯後。 當操作系統更改核心功能時，前面提到的級聯橋組件/Cordova 插件問題會進一步加劇。 一旦 Cordova、PhoneGap 和 Ionic 更新以支持這些更改，自定義插件和橋接組件可能也需要更新。 無論這項工作需要多少數量級，它都會導致應用程序不支持已更新到新操作系統的最終用戶的額外時間。 當然，這是最壞的情況，Apple 或 Google 會做出破壞性的、非向後兼容的更改，但這種情況永遠不會發生……對吧？ 通常，任何不受開發人員控制且必須首先更新的中間框架只會延遲該過程。 最後，依賴中間框架對於項目經理來說可能是一個令人頭疼的計劃，因為這些框架的時間是未知的。

非混合應用

非混合應用程序就像它們的混合應用程序一樣開始生命 - 以非本機平台語言設計的 UI 層：React Native 使用由 JavaScript 或 Xamarin 支持的 HTML/CSS，由於其 .NET 根源而基於 C#。

然而，這就是相似性結束的地方。 非混合應用程序編譯為原生代碼並使用平台原生組件呈現應用程序，而不是通過 webview 呈現。 這導致了一個 WODE 框架，至少在表面上，它具有兩全其美的優點。

如前所述，選擇使用 JavaScript 不應該是一個輕率的決定，對於不想學習或對使用 JavaScript 沒有興趣的開發團隊來說，這可能會破壞交易。

優點

比混合動力車性能更高。 正如人們所預料的那樣，非混合應用程序本質上比混合應用程序具有更高的性能，因為它們能夠使用本機 UI 組件（按鈕、視圖、佈局管理器等）而不是依賴於嵌入式 Web 視圖來呈現應用程序。 當然，開發人員仍然可以自由地編寫性能出色或糟糕的應用程序。 與類似的混合應用程序相比，非混合應用程序的好處很簡單，​​它們具有更高的性能基準。

最小的開發團隊。 與混合框架類似，非混合框架使小型開發團隊（尤其是主要知識庫是 Web 開發的團隊）能夠跨多個平台快速生成簡單的應用程序。 這允許項目經理保持他們的團隊規模小，並阻止團隊學習用於多個平台的本地語言和框架。

更快的開發週期。 除了較小的團隊之外，非混合框架在部署到多個平台時提供了更快的開發週期，因為只需要設計一個視圖層。

更快的迭代（反應） 。 React 框架提供了一個強大的功能，允許實時呈現對應用程序的更改：無需重新編譯、重建等。因此，React 模擬器是一個非常強大的開發工具，可以顯著減少每個實現的持續時間循環。

缺點

定製成本高。 就像它的混合應用程序一樣，當非混合應用程序需要通過為每個平台設計自定義 UI 來改進 UX 時，它會導致創建複雜且獨特的 UI 組件，這些組件的創建成本可能很高，並且隨著時間的推移難以維護。 這也意味著編寫定制的橋接組件來補充框架原生元素支持方面的差距。 與混合一樣，這種成本降低了快速和廉價設計週期的好處，但與混合應用不同的是，橋組件是為每個所需平台以它們的母語編寫的。 這意味著非混合應用程序不是主要由 Web 開發人員組成的團隊的靈活替代方案，選擇非混合路徑的團隊不僅必須學習框架的特定語言（例如 JSX 或 C#），而且也是每個平台的本地語言（Java、Obj-C 或 Swift）。

第三方依賴。 這種限制有兩種不同的形式。 在 React Native 的情況下，它採用大量依賴項的形式，即大約 650 個。結果是，在任何特定時間，這些依賴項中的一個或多個已經過時的可能性很大。 這也意味著在操作系統級別發生較大更改的情況下，很可能需要更新大部分或所有這些依賴項。 潛在的可取之處在於 Facebook 使用 React，因此他們的角落裡會有 300 磅的大猩猩。

在 Xamarin 的情況下，第三方依賴問題很簡單，一開始就很難集成它們。 Xamarin 意識到了這個問題，並提供了一個名為 Sharpie 的實用工具。 該工具的目的是幫助進行一些集成，但不幸的是，Sharpie 經常嘗試編譯和鏈接不正確的資源，這迫使開發人員不得不承擔手動修改低級編譯參數的費時費力的任務才能成功完成整合。

操作系統支持滯後。 非混合應用程序受到與混合應用程序相同的問題的困擾。 任何不受開發人員控制且必須首先更新的中間框架只會延遲更新應用程序以支持尖端用戶的過程。 此外，如前所述，依賴中間框架對於項目經理來說可能是一個令人頭疼的計劃，因為這些框架的時間安排是未知的。

長期支持（React Native） 。 這個問題是 React Native 特有的，並且與一個奇怪的事實有關，即迄今為止，Facebook 還沒有承諾對其框架的長期支持計劃。 可以說這是一個低風險，因為該公司為其移動應用程序使用自己的框架，但任何項目經理都值得停下來考慮一下為什麼 Facebook 拒絕對此發表評論。

選擇正確的方法

當成本不是主要考慮因素時，圖 2表明，在根據應用程序的需求利用開發團隊的構成時，編寫本機應用程序幾乎總是最佳選擇。 當開發工程師的數量少於所需平台的數量時，它會變得更有趣。 在這種情況下，如果團隊的發布計劃非常緊張，那麼使用 React 是正確的選擇； 否則，去本地化仍然是最好的選擇。

當團隊主要是 Web 開發團隊，並且需要定制的 UX 時，最好讓一些團隊成員更換帽子或添加一些團隊成員，以使自己的應用程序原生化。 如果應用程序需要自定義元素（許多應用程序都需要），那麼確實沒有可行的、可維護的框架選項。

但是，如果不需要自定義 UX，那麼根據發佈時間表，使用 Ionic 或 React 可能會更好。 如果一個團隊沒有時間學習 JSX，那麼 Ionic 是正確的選擇。 否則，最好選擇 React，因為它已經需要許多第三方依賴項，並且添加更多不會影響一個人的開發週期。

一旦項目成本成為主要關注點，通常情況下，現有團隊的構成就不再那麼重要了，因為第一步是安排合適的團隊來執行項目計劃以應對預計成本。 如圖 3所示，與 WODE 對應的原生應用程序相比，原生應用程序的啟動成本更高，但潛在的用戶體驗也更高。 此外，無論項目投入了多少資金和資源，WODE 應用程序的用戶體驗都會受到限制。

我希望本文能夠闡明各種移動開發路徑的優缺點，並有助於權衡團隊構成與應用程序需求和項目成本。 它的信息不是要傳達 WODE 框架低劣且不應該被尋求，而是即使有有效的用例不使用原生，人們也應該充分理解這樣做的後果。