【編者按】近些年，跨領域、跨平臺、跨專業類似的詞常常被提起，程式設計領域也不例外。總有人說跨平臺程式設計有多好多好，然而事實真的是這樣的嗎？跨平臺程式設計真的有那麼方便嗎？

跨平臺號稱“利用同一套程式碼就可以為不同的平臺構建應用”，不僅可以節省時間和精力，還可以一勞永逸。這個概念聽起來很誘人，但實際上究竟如何呢？

近幾年，隨著 React Native、 Flutter 和 Xamarin 的興起，跨平臺的概念如火如荼。開發人員惶惶不可終日，彷彿不掌握跨平臺的技術，就要被淘汰了。

雖然有很多公司都決定嘗試跨平臺，但 React Native 的建立者 Facebook 宣佈將其 iOS 應用主頁（Newsfeed）換成 ComponentKit （一種創建於 Objective C 之上的框架）。他們大量借用了 React 的宣告式方法，然而在實現時卻採用了 Objective C，目的是為了發揮 iOS 架構的真正力量。為了做到這一點，他們甚至沒有采用 Swift。

2019 年，Airbnb 放棄了 React Native。這則新聞當時在工程界引起了轟動，同時人們也不得不重新考慮跨平臺。同年，蘋果釋出了 SwiftUI，這是一個宣告性的 UI 框架，旨在吸引新手開發人員再給 Swift 一次機會（Swift 現在已經很穩定了）。

如今，最常用的應用仍然依賴於 C++ 或其他相關語言，例如 Android 的 JNI 和 iOS 的Objective C。

跨平臺應用有其固有的缺點。如今，隨著市場的變化，跨平臺是時候需要展開自救了，否則將面臨消亡危機。而造成如今這個局面的主要原因有以下幾個。

一、iOS 和 Android 兩大應用市場的交叉需求沒有想象中多

首先，iOS 和 Android 兩大應用市場服務的是不同的使用者群體。蘋果主打高階市場，迎合的是高消費使用者的需求。而 Android 系統為很多平臺廠商所採用。

蘋果主要靠硬體銷售，蘋果應用開發人員的收入也主要來自應用本身以及應用內銷售。而服務於消費人群的 Android 應用則以廣告為主要收入。

其次，蘋果對作業系統和硬體的控制更加嚴格，同時蘋果非常注重個人隱私。近來人們越來越注重隱私，整個軟體生態系統的很大一部分推動力都來自安全與隱私，因此向來注重個人隱私的蘋果也將繼續在企業移動解決方案中佔據主導地位。蘋果要求應用必須獲得使用者許可才能傳送廣告資料。

然而，Google 和 Facebook 的主要收入都來自廣告。而恰恰是 Facebook 推出了 React Native，Google 推出了 Flutter。

對於應用開發人員來說，從一開始就要想清楚使用者定位。如果你不想靠廣告賺錢，那麼可以專心開發蘋果應用。在蘋果平臺上取得成功後，再考慮 Android。

再者，蘋果晶片進一步穩固了蘋果的地位。M1 晶片的成功將進一步引誘開發人員使用蘋果的工具（Xcode、Playground 等），以及蘋果晶片加持的 Mac 開發蘋果應用，因為他們可以全權控制底層的硬體。至少在最初階段，沒有人會考慮跨平臺的問題，而且開發人員和創業公司就不會錯失這樣的優勢。

雖然 Google 是一個強有力的競爭者，但其在移動領域的主要目的不是銷售軟體，而是使用者資料。人們開始逐步認清，如果不贏得硬體的支援，就很難得到進一步的發展。是否採用 Android 直接取決於底層的硬體製造商。

二、跨平臺並非創新

人們希望藉助跨平臺一勞永逸，從多家平臺同時攫取利潤。因此，人們一次又一次地嘗試各種跨平臺工具，希望透過某一款工具解決平臺之間的各種問題。然而，拋開底層的硬體，有關應用的討論只是紙上談兵罷了。例如，蘋果和 Windows 這兩家的消費群體之間本來就有著不可跨越的鴻溝。

此外，開發人員願意嘗試跨平臺的另一個原因，不是因為跨平臺能夠創造更好的體驗，而是開發人員對專有平臺非常不滿。

跨平臺就像開源一樣唾手可得，專案的啟動速度非常快，你只需要看一段入門教程，或花一百塊錢買一個模板，開發人員就可以開始構建跨平臺應用了，而且還有一大堆不可思議的功能：

跨平臺應用可以輕易實現原生應用很難做到的功能！（5 行程式碼就可以實現原生的 3 個類！）然而，別忘了原生應用擁有大量的定製潛力，更不用說你根本不知道跨平臺的 5 行程式碼後面隱藏著什麼。

跨平臺具有通用業務邏輯的獨特優勢，這是任何一家創業公司都無法抗拒的優勢。許多收入超過 1000 萬美元的創業公司中，實際上負責維護通用程式碼庫的移動開發人員都只有一人，最終該程式碼庫只能依賴於 GitHub 的貢獻者的支援。然而這些公司沒有意識到的是，通用的業務邏輯必須透過清晰的文件和簡明的規範來維護。

如果這些創業公司足夠幸運，收入超過某個點，就會開始考慮增長戰略，再加上應用商店/遊戲商店的評級不斷下降、投資者的壓力，就會迫使創始人重新考慮他們的初衷，也就是當初那個快速而不堪一擊的解決方案。這就是為什麼後來 LinkedIn、Facebook、Airbnb 以及其他眾多應用重新採用了原生開發的原因。

然而，新興創業公司的數量從未減少，跨平臺開發人員的市場也不會枯竭。但是，我們需要認清現實：C++（或Objective C及其變體）或 Java 開發人員在未來幾十年內依然炙手可熱。但如果你要蹚跨平臺這趟渾水，那麼請做好心理準備每隔 3-5 年就面臨一次大洗底的危機。

三、跨平臺真的是捷徑嗎？

跨平臺帶來了各種混亂。

如今的跨平臺產品都聲稱能夠生成百分百的原生程式碼，例如 Xamarin、React Native 和 Flutter（可能 Flutter 並不能生成百分百的原生程式碼？） 都承諾可百分百在原生環境中執行。

它們與過去在瀏覽器和 HTML5 中執行的 PWA 不同。

人們被跨平臺工具所吸引的主要原因在於，這些工具提供了更容易被初學者理解的高層抽象。而且它們融合了不同底層原生 API 之間的差異。

假設跨平臺提供的某個函式 F 融合了原生 iOS 和 Android 中的以下兩個函式：

iOS: function f (int a, int b, int c)

Android: function f (int a, int b, intp, int q, int r)

該跨平臺提供的函式如下：function f (int a, int b)

如果你想同時兼顧這兩個平臺，則必須搞清楚原生程式碼如何處理 int c、int p、int q、int r。

曾經由於現有 Flutter notification 功能的不足，開發人員不得不開發了一系列外掛：

DartiOS pluginAndroid plugin

由於 Flutter 開發人員只熟悉 XCode / Android Studio，而並不熟悉 Objective C / Kotlin API，因此出現了很多錯誤。

雖然在移動應用開發中採用跨平臺可以節約大約 20% 的開發時間，然而軟體包管理的工作卻會吞噬維護人員 70% 以上的時間。

ReactNative 應用會遇到一些非常嚴重的功能與效能相關的問題，但這些問題往往需要等到開發後期才能被發現。

此外，與原生開發的 IPA 和 APK 相比，flutter 應用的規模往往過大。

有人曾為了解決 Flutter Equatable 實現的相容性問題，而修改了 70 多個 DART 檔案。直到後來才發現背後的真正原因：早期的雜湊演算法在遇到物件內可交換值的屬性時，產生了相同的雜湊！

具體來說，早期的實現有 bug，以下物件會產生相同的雜湊，除非你明確重寫 Equatable 雜湊函式，該函式在 1.0 之前從來不是強制性要求！

物件A：

x = 3，y = 4

物件B：

x = 4，y = 3

想象一下，你需要檢查 500 多個軟體包中是否存在相等性檢查漏洞……

當問及為什麼要在資料密集型應用中採用 Flutter 時，有架構師回答說：“管理層認為，敏捷的目標之一是儘量避免不會產生價值的工作，例如文件。通用程式碼庫就是我們的文件，以及唯一的可靠資訊源。”

造成這些混亂的主要原因，就是平臺之間的相容性問題。實際上，跨平臺框架試圖解決的不同平臺的相容性問題是本質上的問題，儘管跨平臺框架做出了大量努力試圖消弭不同平臺之間的差異，但一些本質上的差異是無法避免的。例如某些平臺的特有功能，以及一些嚴重依賴硬體實現的功能。

通常，跨平臺框架需要為每個平臺提供原生的外掛，而這些正是出現混亂的地方，也往往是各種錯誤層出不窮的地方。如果你的應用程式嚴重依賴於某個平臺特有的功能，或者嚴重依賴硬體實現，那麼顯然跨平臺並不是個好主意。

四、跨平臺的不可靠性

這不是跨平臺固有的問題，而是因為它是透過開原始碼共享實現的。

這個問題背後的原因有兩個：

GitHub（以及其他平臺）上的內容並沒有經過精挑細選，平臺本身也需要對當地法律負責，因此平臺會由於法規變動而刪除某些內容。無論程式碼庫的規模有多大，程式碼庫主人對貢獻的程式碼擁有無上的權利。例如在區塊鏈世界中，程式碼庫所有者早已聲名狼藉，因為建立程式碼庫的人在制定硬幣發行規則上擁有絕對的話語權。

因此，許多公司在使用開原始碼的時候，都需要修復很多 bug 。各個公司僱用了開發人員來維護整個社群，並根據受歡迎程度來發布功能。

然而，對於跨平臺提供商而言，情況並非如此。實際上，他們沒有精力去修復嚴重錯誤或關鍵性的提升請求，就算他們對 GitHub 上報告問題不聞不問，也不會造成任何後果。

如果 Flutter 出現重大 bug，Google 也不會面臨 Pixel 銷量或搜尋流量下滑。同理，如果 React Native 缺乏某個功能，Facebook 的廣告收入也不會縮水。

如果 Android 或 Kotlin 出現嚴重漏洞，那麼 Google 就會遭受損失，因為 Google 獲取了許可收入；同樣，如果 iOS 或 Swift 出現嚴重漏洞，蘋果的 iPhone 銷量也會下滑。

因此，與那些為釋出修補程式而奮戰到半夜的原生平臺所有者不同，**跨平臺開發商對開發人員的要求不屑一顧。**即便你填寫了問題，跨平臺開發商也只會忽視，並不會採取任何措施。此外，由於沒有文件，開發人員學習的唯一方法就是更深入地研究軟體包/庫程式碼，解決問題並交付應用。然而，對於寄希望於跨平臺之上的開發人員，最後卻需要花費大量時間來改 bug 和請求新增某個新功能。

五、該如何選擇？

想必現在你已經知道，跨平臺並不是解決一切問題的銀彈，也並沒有某些文章吹噓的那麼好。那麼在開發一個新的應用時，究竟該如何選擇呢？

先來總結一下跨平臺的優點和缺點。跨平臺的優點主要有：

開發週期短；開發費用低廉；開發人員容易招聘。

而缺點是：

很難找到精通框架的人；框架本身的不成熟；效能問題；難以處理平臺和硬體固有特性。

我們可以總結出幾條原則，供你在選擇開發框架時參考：

如果你的應用需要使用大量平臺固有特性，或者需要大量定製邏輯，那就不要考慮跨平臺。例如相機應用，需要依靠裝置上的感測器工作的應用，或者需要結合應用程式商店的應用等。老老實實選擇原生髮吧。如果你的應用有效能、功耗等要求，顯然跨平臺也不是好的選擇。如果你的應用程式希望長期發展，並且不想在規模擴大後重寫，那麼應該在能夠承受的範圍內，儘量從一開始就選擇原生開發，這樣可以有效避免跨平臺框架的不可靠性。

實際上，跨平臺只適合創業公司非硬體相關的應用程式（如社交應用），避免跨平臺的劣勢，同時利用其開發週期短、費用低廉、人員容易招聘的優勢，迅速建立原型並推出到市場進行驗證，然後快速迭代。而對於其他情況，個人認為選擇原生應用會更好。