點擊“開發者技術前線”，選擇“星標????”

讓一部分開發者看到未來

作者 | Pen Magnet 來自 前端之顛? 譯者 |?張健欣

2015 年時，我是一名自由職業的原生 iOS 開發者。我知道 Objective C——這是唯一我睡著都能寫的語言。Swift 還在努力解決 ABI 兼容性問題，而我還在觀望。

當我決定重新進入就業市場時，每個人都想要 React Native。

我是這個領域的新手。每個工程博客，主要 包括 Airbnb，都在鼓吹“一次編寫，隨處發布”的優勢。我的朋友們建議我轉向跨平臺，或者立即退休。

如果有人給我提供機會，相信我在 Windows + iOS 領域的工程技能，我可以在工作中學習原生安卓。

但是我猶豫要不要學習 RN。LinkedIn 在 2013 年放棄了其基于 HTML5 的 跨平臺 app，這在我的腦海中記憶猶新。盡管 React Native 在執行時是完全原生的，但是它沒有像 Objective C 或 Java 那樣暴露出原生的感覺。

我的猶豫很快得到了驗證：

我讀到了相關新聞，RN 的創造者 Facebook——宣布將其 iOS 主頁（新聞流）切換到 Kit 組件——一個基于 Objective C++ 創建的框架。他們大量借用了 React 的聲明式方案，但是 用 Objective C++ 實現了所有東西 來利用 iOS 架構的真正力量——甚至 Swift 現在還無法提供。

圖片來源:Reddit

現在大部分經常使用的應用程序依賴 C++ 或它的一些變種（對于安卓是 JNI，對于 iOS 是 Objective C++）。

快進到 2020 年。

Airbnb 早在 2019 年就 放棄了繼續使用 RN。這在工程界引起了足夠的轟動，迫使人們重新思考。在 2019 年的同一年，蘋果發布了 SwiftUI，一個聲明式的 UI 框架，旨在再次吸引新手開發者度過其 Swift 災難（盡管現在已經穩定了）。

什么敲響了跨平臺的喪鐘：

跨平臺的應用程序有其固有缺陷。隨著市場的不斷變化，現在市場已經成熟，它們要么改進要么消亡。

蘋果正在整合

在開發者收入方面，蘋果已經占據了主導地位

這是 公開的秘密，從未變過。盡管安卓的市場份額很大，但在應用程序收入方面，它遠遠落后于蘋果。這不僅僅是因為安卓在世界的低收入地區處于領先地位，還因為安卓的核心業務是授權，而不是硬件制造。

因此，iOS + iDevice 的更新更符合其高付費用戶的需求。

蘋果的系統在移動體驗方面已經非常成熟

盡管非蘋果制造商引領了許多智能手機創新。

由于蘋果對操作系統和硬件的控制更嚴格，蘋果在提供卓越 + 個性化的體驗方面做得更好，而這也是高價值用戶在移動設備上的追求。

由于蘋果最新致力于成為一個以隱私為中心的軟件生態系統，顯而易見，蘋果將繼續在企業移動解決方案領域占據主導地位。

對于開發者來說，蘋果和安卓之間的收入分成非常簡單：

蘋果開發 =>高價值付費用戶 =>應用程序銷售收入

安卓開發 =>低價值用戶 =>廣告收入

蘋果最近強制應用程序請求用戶權限來分享廣告數據。這對于那些以廣告數據為唯一資產的公司來說是一個直接的打擊——特別是 Facebook 和谷歌。

而 Facebook 和谷歌碰巧是 React Native 和 Flutter 的創造者，這應該不是個巧合。

你很容易看到這對于 App 開發者來說意味著什么：進一步搞明白你的理想的用戶基礎。盡早做出選擇，并選擇你相應的工具集。

例如，如果你不想做廣告，你最好先開發蘋果應用。經過驗證后，再開發安卓應用。這種比較零碎的方案幾乎沒有動力來進行跨平臺開發。只要團隊保持不變，通用代碼庫需求很容易得到滿足。

Apple Silicon 是蘋果在應用經濟領域的王牌

除非某家顛覆性的硬件公司從黑暗中走出來。

谷歌是一個規模相當大的挑戰者，但并不可怕。它在移動領域的主要目的不是銷售軟件，而是掌握用戶數據。如果不在硬件上取勝，正如 它所公開承認的那樣，谷歌很難打破這種平衡。安卓的采用直接取決于它許可的硬件制造商。

有了 Apple Silicon，蘋果就整合了它的開發者社區。它已經向開發者支付了更多?，F在有了 Apple Silicon，iOS 開發者可以輕松遷移到新的蘋果 Mac 上。

這一舉措使得 開發蘋果應用更有利可圖，使用它自己的工具：XCode、Playground 等等，使用 Apple Silicon 驅動的 Mac 電腦，因為它可以完全控制它的硬件。有更明確的動機讓所有人都投入到一個平臺上，至少在最初是這樣，而且沒有開發者或創業公司會錯過這個優勢。

跨平臺是一種漸進性改進，而不是創新

這是一種漸進性改進，告訴壟斷者：

現在，我挑戰你進行創新。我不能做一個更好的 IDE 或硬件，但是我可以剝奪你從中獲取的一些收益或開發者。

一次又一次，跨平臺工具將自己作為解決每個與平臺相關的問題的靈丹妙藥。

如果沒有底層硬件，它們會成為壟斷者的挑戰者，因為壟斷企業有很高的進入成本壁壘。Mac 機器 vs windows 機器的成本是被引用最多的標準。

它們迅速被采用的另一個原因，不是它們有能力創造更好的體驗，而是開發者對專有平臺的不滿。

每個超過千萬美元的初創公司都會雇傭一名移動開發人員來維護一個最終依賴于遠程 GitHub 貢獻者支持的代碼庫

它們可以是開源的?？焖偃腴T項目、Youtube 教程和價值 100 美元的模板充斥在開發人員的信息流中，但幾乎很難找到依據：

跨平臺 App 可以實現的東西用原生并不容易實現！（5 行代碼 vs 3 個類！）。不要看原生提供的定制可能性 vs 5 行代碼的底層機制。

它提供了 通用業務邏輯 的獨特優勢——這是任何初創公司都無法抗拒的。最后，每個 千萬美元 的初創公司都會雇傭一名移動開發人員來維護一個最終依賴于 GitHub 貢獻者支持的通用代碼庫。這些公司沒有意識到的是，通用業務邏輯必須通過清晰的文檔（嗯？那是什么）和簡潔的規范（但我們是敏捷開發！）維護。

幸運的是，如果這些初創公司能夠超過一個收入點，如果出現開發人員流失，增長策略就會介入，在 app store/play store 上排名退步 + 投資人的壓力會促使創始人重新考慮他們最初追求快速但雜亂的解決方案的決定。這也解釋了 LinkedIn、Facebook iOS 版、Airbnb 以及其它無數應用后期采用原生方案的原因。

然而，初露頭角的創業公司數量從未減少，跨平臺開發人員的市場也從未枯竭。反抗精神萬歲！但現實是這樣的：如果你知道 C++（或 Objective C 及其變種）或者 Java，你的技能將在幾十年后還不落伍。如果你用一個奇特的跨平臺開源工具集來修飾你的簡歷，那就要準備好每 3-5 年做一次徹底的調整。

跨平臺糟糕透了

它們被開發是為了發布，而不是維護。

在跨平臺應用中，困惑不斷。

如今的跨平臺產品能夠提供幾乎 100% 的原生代碼——這一點毫無疑問。Xamarin、React Native 和 Flutter——都承諾 100% 原生執行。

它們不同于以往運行在瀏覽器上和基于 HTML5 的 PWA 應用。

但在設計上，它與每一個代碼組織原則都相反。它們由 500 多個從完全不同的不受監控的源代碼（而不是本地庫）下載的包組成，模仿了 Web 開發方法。在移動開發中采用這種方法——其源代碼被視為公開的，而不是在由開發人員控制的服務器的邊界內，人們可以想象其風險。

跨平臺工具很容易被采用，因為它們提供了初學者更容易理解的更高級別的抽象。它們融合了不同底層原生 API 之間的差異。它們采用了最常用的功能，其余的定制工作留給了開發人員。

設想一個假設的 函數 F 在原生 iOS 和安卓中有如下實現：

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

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

一個典型的跨平臺包會提供如下函數：

function f (int a, int b)

如果你想要充分利用這兩個功能，你必須在原生代碼（即 Objective C 和 Java）中找出 c、p、q 和 r 的調整。

在我的上一個組織中，由于現有的 Flutter 通知包的缺點，開發人員必須在以下方面進行開發：

Dart

iOS 插件

安卓插件

因為 Flutter 開發人員只熟悉 XCode 或 Android Studio，并不精通 Objective C 或 Kotlin API，所以這被認為是一個缺陷。

大部分跨平臺愛好者都是大學生，他們在圖書館中創建了他們的第一個軟件，不能忘記他們的“初戀”。他們構建跨平臺 App 是用來發布，而不是維護。

但當你被迫下載一個包來實現一個簡單的功能，例如 設備信息，真正的痛苦就開始了。

大部分跨平臺愛好者都是大學生，他們在圖書館中創建了他們的第一個軟件，不能忘記他們的“初戀”。

平均而言，雖然一個移動應用開發人員開發一個單一代碼庫只節省了 20% 時間（而不是 50%，因為需求轉化 + 定制化），包管理占用了維護者 70% 多的時間。

一個 React Native 應用程序被一些 非常嚴重的功能 + 性能相關問題 困擾，這些問題會在開發周期的后期被發現。

相比于原生開發者的 IPA 和 APK，一個典型的 flutter app 的尺寸要大得多。

在我的上一個組織中，我修改了 70 多個文件，來處理 Flutter 的 Equatable 實現的兼容性中斷。

這并不痛苦，直到我了解了其背后的原因：早期的哈希算法對于一個對象內屬性值的交換產生相同的哈希值！

換句話說，以下對象將在舊的有缺陷的實現中產生相同的哈希值，除非你顯式地重寫 Equatable 哈希函數，在 1.0 之前，這從不是一個強制要求！

對象 A:

x = 3, y = 4

對象 B:

x = 4, y = 3

想象一下，檢查所有 500 多個包是否存在 equality 檢查漏洞...????

我問我的架構師，為什么像我們這樣的數據密集型應用程序首先采用了 Flutter。

他的回答非常經典：

“管理人員常說：敏捷的目標之一，就是避免無價值的操作，例如文檔。通用代碼庫就是我們的文檔和唯一信源。”

跨平臺是一種不依賴的依賴關系

這個問題不是跨平臺固有的。但這個問題通過開源共享與跨平臺緊緊綁定在了一起。

庫所有人具有不可思議的權力

這個問題的存在有兩個原因。

首先，GitHub（和它的競品）是未評級的，但要對國家法律負責。它可以在任何時候通過合法的改組來 摧毀任何東西。

其次，庫所有人對于貢獻者的工作具有不可思議的權力，無論這個庫有多大。

庫所有者的暴政 已經在區塊鏈領域臭名昭著，創始貢獻者在制定鏈幣發行規則方面占據上風。

所有頭部公司（包括 FAAMG）都已經在利用開源，來使他們的 SDK 可以被獲取 + 對 bug 修復開放。公司雇傭開發者來維護社區意識，關注開發者的興趣，并根據大眾需求來發布特性。

如果他們不這么做，他們的核心產品就會受損。

對于跨平臺供應商則不是這樣。事實上，他們對嚴重的 bugs 或關鍵的增強請求沒有任何反映。因此，錯誤處理 GitHub 問題不會對他們造成任何后果。

如果 Flutter 有嚴重的 bugs，谷歌在已經微不足道的 Pixel 銷量或龐大的搜索流量方面不會有任何減少。

如果 React Native 缺少一個功能，Facebook 的廣告收入不會縮減。

但是，如果 Android/Kotlin 或 iOS/Swift 有嚴重的漏洞，谷歌和蘋果肯定會遭受損失——谷歌在授權收入方面受損，蘋果在 iPhone 銷量方面受損。開發者會削減 30% 收入。

因此，與那些在午夜發布修補程序的原生平臺所有者不同，跨平臺開發者對開發人員的請求置若罔聞。

稍好點的回應者會對問題寫一個正式的回應，并單方面關閉它們，而不進行后續處理。在沒有適當文檔的情況下，開發人員的唯一辦法就是深入研究包 / 庫代碼，修復問題，然后發布他們的應用程序。

有時，他們被庫開發者誘導回饋，而這也沒有任何激勵措施，這一切都是基于開源精神。

對于一個被承諾了高效跨平臺實現的開發者來說，這是 2 個缺點：花在 bug 上的時間更多 + 特性請求是開源的。

但還有更糟糕的。

雪上加霜的是，他們的 PR 有時候會被庫所有者拒絕或忽視，理由是為了保證他們的記錄簿干凈。

除非高薪的跨平臺庫所有者平等對待他們的低薪同行創新者，否則情況只會惡化。

隨著有經驗的開發人員轉向更好的平臺原生的解決方案，跨平臺項目注定會是一個偽裝成創新的巨大漸進改動。

? ? 結論? ??

跨平臺開發將很快意味著對于多種設備的單平臺開發

在所有的移動開發廠商中，蘋果是唯一一家真正的業務線是硬件的公司。隨著他們平臺的統一，它向開發者發出了一個明確的信息：你對我們的服務業務至關重要，我們關心你們的增長。

現在預測其長期市場主導地位還為時過早。谷歌有足夠的財力來為其原生安卓平臺提供燃料，使其對開發者更有吸引力。

雖然單靠蘋果無法撼動整個跨平臺社區，但它肯定能夠迫使其競爭對手采用一種更結構化更易于維護且更不易出現故障的移動開發方案。

跨平臺開發領域將很快意味著對多種設備的單平臺開發，就像.NET 早期那樣。

創業公司最好不要跨平臺。公共代碼庫的誘惑必須被良好的老文檔取代，這樣才能在開發人員心中培養真正的通用商業邏輯。

你的客戶值得原生平臺提供的最佳統一體驗。

你的開發者？休息（不是雙關語） + 尊敬。

作者介紹

Pen Magnet 創業作家、程序員、科技職業博主、教育愛好者。

延伸閱讀

https://medium.com/swlh/the-end-of-cross-platform-as-we-know-it-dad658d96b8

END前線推出學習交流群，加群一定要備注：研究/工作方向+地點+學校/公司+昵稱（如前端+上海+上交+可可）根據格式備注，可更快被通過且邀請進群，領取一份專屬學習禮包掃碼加我微信進群，內推和技術交流，大佬們零距離歷史推薦網易云音樂的消息隊列改造，到底做了啥？ 5個常用的大數據可視化分析工具 VS Code竟然能約會談戀愛，找對象不看臉，主要看編程水平 為什么 Google 的技術這么牛？ 好文點個在看吧！

總結

以上是生活随笔為你收集整理的跨平台应用即将死亡！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。