跨平臺將終結

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

編譯 | 彎月 責編 | 張文
頭圖 | CSDN 下載自視覺中國
出品 | CSDN（ID：CSDNnews）

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

近幾年，隨著 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 不同，

然而，從設計的角度來看，每個跨平臺工具集都違背了代碼的基本組織原則，常見的跨平臺工具都由 500 多個軟體包組成，這些軟體包的來源并非完全可靠，而且很多都不在開發人員控制的服務器范圍內，因此在移動開發中采用這些跨平臺工具所承擔的風險可想而知，

人們被跨平臺工具所吸引的主要原因在于，這些工具提供了更容易被初學者理解的高層抽象，而且它們融合了不同底層原生 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 功能的不足，開發人員不得不開發了一系列插件：

• Dart
• iOS plugin
• Android 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 時，有架構師回答說：“管理層認為，敏捷的目標之一是盡量避免不會產生價值的作業，例如檔案，通用代碼庫就是我們的檔案，以及唯一的可靠資訊源，”

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

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

四、跨平臺的不可靠性

這不是跨平臺固有的問題，而是因為它是通過開源代碼共享實作的，

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

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

因此，許多公司在使用開源代碼的時候，都需要修復很多 bug ，各個公司雇用了開發人員來維護整個社區，并根據受歡迎程度來發布功能，

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

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

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

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

五、該如何選擇？

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

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

• 開發周期短；
• 開發費用低廉；
• 開發人員容易招聘，

而缺點是：

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

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

1. 如果你的應用需要使用大量平臺固有特性，或者需要大量定制邏輯，那就不要考慮跨平臺，例如相機應用，需要依靠設備上的傳感器作業的應用，或者需要結合應用程式商店的應用等，老老實實選擇原生發吧，
2. 如果你的應用有性能、功耗等要求，顯然跨平臺也不是好的選擇，
3. 如果你的應用程式希望長期發展，并且不想在規模擴大后重寫，那么應該在能夠承受的范圍內，盡量從一開始就選擇原生開發，這樣可以有效避免跨平臺框架的不可靠性，

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

參考鏈接：https://medium.com/swlh/the-end-of-cross-platform-as-we-know-it-dad658d96b8