跨平臺(tái)應(yīng)用即將死亡！
點(diǎn)擊“開(kāi)發(fā)者技術(shù)前線”，選擇“星標(biāo)?”
讓一部分開(kāi)發(fā)者看到未來(lái)
2015 年時(shí)，我是一名自由職業(yè)的原生 iOS 開(kāi)發(fā)者。我知道 Objective C——這是唯一我睡著都能寫(xiě)的語(yǔ)言。Swift 還在努力解決 ABI 兼容性問(wèn)題，而我還在觀望。
當(dāng)我決定重新進(jìn)入就業(yè)市場(chǎng)時(shí)，每個(gè)人都想要 React Native。
我是這個(gè)領(lǐng)域的新手。每個(gè)工程博客，主要 包括 Airbnb，都在鼓吹“一次編寫(xiě)，隨處發(fā)布”的優(yōu)勢(shì)。我的朋友們建議我轉(zhuǎn)向跨平臺(tái)，或者立即退休。
如果有人給我提供機(jī)會(huì)，相信我在 Windows + iOS 領(lǐng)域的工程技能，我可以在工作中學(xué)習(xí)原生安卓。
但是我猶豫要不要學(xué)習(xí) RN。LinkedIn 在 2013 年放棄了其基于 HTML5 的 跨平臺(tái) app，這在我的腦海中記憶猶新。盡管 React Native 在執(zhí)行時(shí)是完全原生的，但是它沒(méi)有像 Objective C 或 Java 那樣暴露出原生的感覺(jué)。
我的猶豫很快得到了驗(yàn)證：
我讀到了相關(guān)新聞，RN 的創(chuàng)造者 Facebook——宣布將其 iOS 主頁(yè)（新聞流）切換到 Kit 組件——一個(gè)基于 Objective C++ 創(chuàng)建的框架。他們大量借用了 React 的聲明式方案，但是 用 Objective C++ 實(shí)現(xiàn)了所有東西 來(lái)利用 iOS 架構(gòu)的真正力量——甚至 Swift 現(xiàn)在還無(wú)法提供。
圖片來(lái)源:Reddit
現(xiàn)在大部分經(jīng)常使用的應(yīng)用程序依賴 C++ 或它的一些變種（對(duì)于安卓是 JNI，對(duì)于 iOS 是 Objective C++）。
快進(jìn)到 2020 年。
Airbnb 早在 2019 年就 放棄了繼續(xù)使用 RN。這在工程界引起了足夠的轟動(dòng)，迫使人們重新思考。在 2019 年的同一年，蘋(píng)果發(fā)布了 SwiftUI，一個(gè)聲明式的 UI 框架，旨在再次吸引新手開(kāi)發(fā)者度過(guò)其 Swift 災(zāi)難（盡管現(xiàn)在已經(jīng)穩(wěn)定了）。
跨平臺(tái)的應(yīng)用程序有其固有缺陷。隨著市場(chǎng)的不斷變化，現(xiàn)在市場(chǎng)已經(jīng)成熟，它們要么改進(jìn)要么消亡。
這是 公開(kāi)的秘密，從未變過(guò)。盡管安卓的市場(chǎng)份額很大，但在應(yīng)用程序收入方面，它遠(yuǎn)遠(yuǎn)落后于蘋(píng)果。這不僅僅是因?yàn)榘沧吭谑澜绲牡褪杖氲貐^(qū)處于領(lǐng)先地位，還因?yàn)榘沧康暮诵臉I(yè)務(wù)是授權(quán)，而不是硬件制造。
因此，iOS + iDevice 的更新更符合其高付費(fèi)用戶的需求。
盡管非蘋(píng)果制造商引領(lǐng)了許多智能手機(jī)創(chuàng)新。
由于蘋(píng)果對(duì)操作系統(tǒng)和硬件的控制更嚴(yán)格，蘋(píng)果在提供卓越 + 個(gè)性化的體驗(yàn)方面做得更好，而這也是高價(jià)值用戶在移動(dòng)設(shè)備上的追求。
由于蘋(píng)果最新致力于成為一個(gè)以隱私為中心的軟件生態(tài)系統(tǒng)，顯而易見(jiàn)，蘋(píng)果將繼續(xù)在企業(yè)移動(dòng)解決方案領(lǐng)域占據(jù)主導(dǎo)地位。
對(duì)于開(kāi)發(fā)者來(lái)說(shuō)，蘋(píng)果和安卓之間的收入分成非常簡(jiǎn)單：
蘋(píng)果開(kāi)發(fā) =>高價(jià)值付費(fèi)用戶 =>應(yīng)用程序銷售收入
安卓開(kāi)發(fā) =>低價(jià)值用戶 =>廣告收入
蘋(píng)果最近強(qiáng)制應(yīng)用程序請(qǐng)求用戶權(quán)限來(lái)分享廣告數(shù)據(jù)。這對(duì)于那些以廣告數(shù)據(jù)為唯一資產(chǎn)的公司來(lái)說(shuō)是一個(gè)直接的打擊——特別是 Facebook 和谷歌。
而 Facebook 和谷歌碰巧是 React Native 和 Flutter 的創(chuàng)造者，這應(yīng)該不是個(gè)巧合。
你很容易看到這對(duì)于 App 開(kāi)發(fā)者來(lái)說(shuō)意味著什么：進(jìn)一步搞明白你的理想的用戶基礎(chǔ)。盡早做出選擇，并選擇你相應(yīng)的工具集。
例如，如果你不想做廣告，你最好先開(kāi)發(fā)蘋(píng)果應(yīng)用。經(jīng)過(guò)驗(yàn)證后，再開(kāi)發(fā)安卓應(yīng)用。這種比較零碎的方案幾乎沒(méi)有動(dòng)力來(lái)進(jìn)行跨平臺(tái)開(kāi)發(fā)。只要團(tuán)隊(duì)保持不變，通用代碼庫(kù)需求很容易得到滿足。
除非某家顛覆性的硬件公司從黑暗中走出來(lái)。
谷歌是一個(gè)規(guī)模相當(dāng)大的挑戰(zhàn)者，但并不可怕。它在移動(dòng)領(lǐng)域的主要目的不是銷售軟件，而是掌握用戶數(shù)據(jù)。如果不在硬件上取勝，正如 它所公開(kāi)承認(rèn)的那樣，谷歌很難打破這種平衡。安卓的采用直接取決于它許可的硬件制造商。
有了 Apple Silicon，蘋(píng)果就整合了它的開(kāi)發(fā)者社區(qū)。它已經(jīng)向開(kāi)發(fā)者支付了更多。現(xiàn)在有了 Apple Silicon，iOS 開(kāi)發(fā)者可以輕松遷移到新的蘋(píng)果 Mac 上。
這一舉措使得 開(kāi)發(fā)蘋(píng)果應(yīng)用更有利可圖，使用它自己的工具：XCode、Playground 等等，使用 Apple Silicon 驅(qū)動(dòng)的 Mac 電腦，因?yàn)樗梢酝耆刂扑挠布Ｓ懈鞔_的動(dòng)機(jī)讓所有人都投入到一個(gè)平臺(tái)上，至少在最初是這樣，而且沒(méi)有開(kāi)發(fā)者或創(chuàng)業(yè)公司會(huì)錯(cuò)過(guò)這個(gè)優(yōu)勢(shì)。
這是一種漸進(jìn)性改進(jìn)，告訴壟斷者：
現(xiàn)在，我挑戰(zhàn)你進(jìn)行創(chuàng)新。我不能做一個(gè)更好的 IDE 或硬件，但是我可以剝奪你從中獲取的一些收益或開(kāi)發(fā)者。
一次又一次，跨平臺(tái)工具將自己作為解決每個(gè)與平臺(tái)相關(guān)的問(wèn)題的靈丹妙藥。
如果沒(méi)有底層硬件，它們會(huì)成為壟斷者的挑戰(zhàn)者，因?yàn)閴艛嗥髽I(yè)有很高的進(jìn)入成本壁壘。Mac 機(jī)器 vs windows 機(jī)器的成本是被引用最多的標(biāo)準(zhǔn)。
它們迅速被采用的另一個(gè)原因，不是它們有能力創(chuàng)造更好的體驗(yàn)，而是開(kāi)發(fā)者對(duì)專有平臺(tái)的不滿。
每個(gè)超過(guò)千萬(wàn)美元的初創(chuàng)公司都會(huì)雇傭一名移動(dòng)開(kāi)發(fā)人員來(lái)維護(hù)一個(gè)最終依賴于遠(yuǎn)程 GitHub 貢獻(xiàn)者支持的代碼庫(kù)
它們可以是開(kāi)源的?？焖偃腴T項(xiàng)目、Youtube 教程和價(jià)值 100 美元的模板充斥在開(kāi)發(fā)人員的信息流中，但幾乎很難找到依據(jù)：
跨平臺(tái) App 可以實(shí)現(xiàn)的東西用原生并不容易實(shí)現(xiàn)?。? 行代碼 vs 3 個(gè)類?。?。不要看原生提供的定制可能性 vs 5 行代碼的底層機(jī)制。
它提供了 通用業(yè)務(wù)邏輯 的獨(dú)特優(yōu)勢(shì)——這是任何初創(chuàng)公司都無(wú)法抗拒的。最后，每個(gè) 千萬(wàn)美元 的初創(chuàng)公司都會(huì)雇傭一名移動(dòng)開(kāi)發(fā)人員來(lái)維護(hù)一個(gè)最終依賴于 GitHub 貢獻(xiàn)者支持的通用代碼庫(kù)。這些公司沒(méi)有意識(shí)到的是，通用業(yè)務(wù)邏輯必須通過(guò)清晰的文檔（嗯？那是什么）和簡(jiǎn)潔的規(guī)范（但我們是敏捷開(kāi)發(fā)?。┚S護(hù)。
幸運(yùn)的是，如果這些初創(chuàng)公司能夠超過(guò)一個(gè)收入點(diǎn)，如果出現(xiàn)開(kāi)發(fā)人員流失，增長(zhǎng)策略就會(huì)介入，在 app store/play store 上排名退步 + 投資人的壓力會(huì)促使創(chuàng)始人重新考慮他們最初追求快速但雜亂的解決方案的決定。這也解釋了 LinkedIn、Facebook iOS 版、Airbnb 以及其它無(wú)數(shù)應(yīng)用后期采用原生方案的原因。
然而，初露頭角的創(chuàng)業(yè)公司數(shù)量從未減少，跨平臺(tái)開(kāi)發(fā)人員的市場(chǎng)也從未枯竭。反抗精神萬(wàn)歲！但現(xiàn)實(shí)是這樣的：如果你知道 C++（或 Objective C 及其變種）或者 Java，你的技能將在幾十年后還不落伍。如果你用一個(gè)奇特的跨平臺(tái)開(kāi)源工具集來(lái)修飾你的簡(jiǎn)歷，那就要準(zhǔn)備好每 3-5 年做一次徹底的調(diào)整。
它們被開(kāi)發(fā)是為了發(fā)布，而不是維護(hù)。
在跨平臺(tái)應(yīng)用中，困惑不斷。
如今的跨平臺(tái)產(chǎn)品能夠提供幾乎 100% 的原生代碼——這一點(diǎn)毫無(wú)疑問(wèn)。Xamarin、React Native 和 Flutter——都承諾 100% 原生執(zhí)行。
它們不同于以往運(yùn)行在瀏覽器上和基于 HTML5 的 PWA 應(yīng)用。
但在設(shè)計(jì)上，它與每一個(gè)代碼組織原則都相反。它們由 500 多個(gè)從完全不同的不受監(jiān)控的源代碼（而不是本地庫(kù)）下載的包組成，模仿了 Web 開(kāi)發(fā)方法。在移動(dòng)開(kāi)發(fā)中采用這種方法——其源代碼被視為公開(kāi)的，而不是在由開(kāi)發(fā)人員控制的服務(wù)器的邊界內(nèi)，人們可以想象其風(fēng)險(xiǎn)。
跨平臺(tái)工具很容易被采用，因?yàn)樗鼈兲峁┝顺鯇W(xué)者更容易理解的更高級(jí)別的抽象。它們?nèi)诤狭瞬煌讓釉?API 之間的差異。它們采用了最常用的功能，其余的定制工作留給了開(kāi)發(fā)人員。
設(shè)想一個(gè)假設(shè)的 函數(shù) F 在原生 iOS 和安卓中有如下實(shí)現(xiàn)：
iOS: function f (int a, int b, int c)
Android: function f (int a, int b, int p, int q, int r)
一個(gè)典型的跨平臺(tái)包會(huì)提供如下函數(shù)：
function f (int a, int b)
如果你想要充分利用這兩個(gè)功能，你必須在原生代碼（即 Objective C 和 Java）中找出 c、p、q 和 r 的調(diào)整。
在我的上一個(gè)組織中，由于現(xiàn)有的 Flutter 通知包的缺點(diǎn)，開(kāi)發(fā)人員必須在以下方面進(jìn)行開(kāi)發(fā)：
Dart
iOS 插件
安卓插件
因?yàn)?Flutter 開(kāi)發(fā)人員只熟悉 XCode 或 Android Studio，并不精通 Objective C 或 Kotlin API，所以這被認(rèn)為是一個(gè)缺陷。
大部分跨平臺(tái)愛(ài)好者都是大學(xué)生，他們?cè)趫D書(shū)館中創(chuàng)建了他們的第一個(gè)軟件，不能忘記他們的“初戀”。他們構(gòu)建跨平臺(tái) App 是用來(lái)發(fā)布，而不是維護(hù)。
但當(dāng)你被迫下載一個(gè)包來(lái)實(shí)現(xiàn)一個(gè)簡(jiǎn)單的功能，例如 設(shè)備信息，真正的痛苦就開(kāi)始了。
大部分跨平臺(tái)愛(ài)好者都是大學(xué)生，他們?cè)趫D書(shū)館中創(chuàng)建了他們的第一個(gè)軟件，不能忘記他們的“初戀”。
平均而言，雖然一個(gè)移動(dòng)應(yīng)用開(kāi)發(fā)人員開(kāi)發(fā)一個(gè)單一代碼庫(kù)只節(jié)省了 20% 時(shí)間（而不是 50%，因?yàn)樾枨筠D(zhuǎn)化 + 定制化），包管理占用了維護(hù)者 70% 多的時(shí)間。
一個(gè) React Native 應(yīng)用程序被一些 非常嚴(yán)重的功能 + 性能相關(guān)問(wèn)題 困擾，這些問(wèn)題會(huì)在開(kāi)發(fā)周期的后期被發(fā)現(xiàn)。
相比于原生開(kāi)發(fā)者的 IPA 和 APK，一個(gè)典型的 flutter app 的尺寸要大得多。
在我的上一個(gè)組織中，我修改了 70 多個(gè)文件，來(lái)處理 Flutter 的 Equatable 實(shí)現(xiàn)的兼容性中斷。
這并不痛苦，直到我了解了其背后的原因：早期的哈希算法對(duì)于一個(gè)對(duì)象內(nèi)屬性值的交換產(chǎn)生相同的哈希值！
換句話說(shuō)，以下對(duì)象將在舊的有缺陷的實(shí)現(xiàn)中產(chǎn)生相同的哈希值，除非你顯式地重寫(xiě) Equatable 哈希函數(shù)，在 1.0 之前，這從不是一個(gè)強(qiáng)制要求！
對(duì)象 A:
x = 3, y = 4
對(duì)象 B:
x = 4, y = 3
想象一下，檢查所有 500 多個(gè)包是否存在 equality 檢查漏洞...?
我問(wèn)我的架構(gòu)師，為什么像我們這樣的數(shù)據(jù)密集型應(yīng)用程序首先采用了 Flutter。
他的回答非常經(jīng)典：
“管理人員常說(shuō)：敏捷的目標(biāo)之一，就是避免無(wú)價(jià)值的操作，例如文檔。通用代碼庫(kù)就是我們的文檔和唯一信源。”
這個(gè)問(wèn)題不是跨平臺(tái)固有的。但這個(gè)問(wèn)題通過(guò)開(kāi)源共享與跨平臺(tái)緊緊綁定在了一起。
庫(kù)所有人具有不可思議的權(quán)力
這個(gè)問(wèn)題的存在有兩個(gè)原因。
首先，GitHub（和它的競(jìng)品）是未評(píng)級(jí)的，但要對(duì)國(guó)家法律負(fù)責(zé)。它可以在任何時(shí)候通過(guò)合法的改組來(lái) 摧毀任何東西。
其次，庫(kù)所有人對(duì)于貢獻(xiàn)者的工作具有不可思議的權(quán)力，無(wú)論這個(gè)庫(kù)有多大。
庫(kù)所有者的暴政 已經(jīng)在區(qū)塊鏈領(lǐng)域臭名昭著，創(chuàng)始貢獻(xiàn)者在制定鏈幣發(fā)行規(guī)則方面占據(jù)上風(fēng)。
所有頭部公司（包括 FAAMG）都已經(jīng)在利用開(kāi)源，來(lái)使他們的 SDK 可以被獲取 + 對(duì) bug 修復(fù)開(kāi)放。公司雇傭開(kāi)發(fā)者來(lái)維護(hù)社區(qū)意識(shí)，關(guān)注開(kāi)發(fā)者的興趣，并根據(jù)大眾需求來(lái)發(fā)布特性。
如果他們不這么做，他們的核心產(chǎn)品就會(huì)受損。
對(duì)于跨平臺(tái)供應(yīng)商則不是這樣。事實(shí)上，他們對(duì)嚴(yán)重的 bugs 或關(guān)鍵的增強(qiáng)請(qǐng)求沒(méi)有任何反映。因此，錯(cuò)誤處理 GitHub 問(wèn)題不會(huì)對(duì)他們?cè)斐扇魏魏蠊?/p>
如果 Flutter 有嚴(yán)重的 bugs，谷歌在已經(jīng)微不足道的 Pixel 銷量或龐大的搜索流量方面不會(huì)有任何減少。
如果 React Native 缺少一個(gè)功能，F(xiàn)acebook 的廣告收入不會(huì)縮減。
但是，如果 Android/Kotlin 或 iOS/Swift 有嚴(yán)重的漏洞，谷歌和蘋(píng)果肯定會(huì)遭受損失——谷歌在授權(quán)收入方面受損，蘋(píng)果在 iPhone 銷量方面受損。開(kāi)發(fā)者會(huì)削減 30% 收入。
因此，與那些在午夜發(fā)布修補(bǔ)程序的原生平臺(tái)所有者不同，跨平臺(tái)開(kāi)發(fā)者對(duì)開(kāi)發(fā)人員的請(qǐng)求置若罔聞。
稍好點(diǎn)的回應(yīng)者會(huì)對(duì)問(wèn)題寫(xiě)一個(gè)正式的回應(yīng)，并單方面關(guān)閉它們，而不進(jìn)行后續(xù)處理。在沒(méi)有適當(dāng)文檔的情況下，開(kāi)發(fā)人員的唯一辦法就是深入研究包 / 庫(kù)代碼，修復(fù)問(wèn)題，然后發(fā)布他們的應(yīng)用程序。
有時(shí)，他們被庫(kù)開(kāi)發(fā)者誘導(dǎo)回饋，而這也沒(méi)有任何激勵(lì)措施，這一切都是基于開(kāi)源精神。
對(duì)于一個(gè)被承諾了高效跨平臺(tái)實(shí)現(xiàn)的開(kāi)發(fā)者來(lái)說(shuō)，這是 2 個(gè)缺點(diǎn)：花在 bug 上的時(shí)間更多 + 特性請(qǐng)求是開(kāi)源的。
但還有更糟糕的。
雪上加霜的是，他們的 PR 有時(shí)候會(huì)被庫(kù)所有者拒絕或忽視，理由是為了保證他們的記錄簿干凈。
除非高薪的跨平臺(tái)庫(kù)所有者平等對(duì)待他們的低薪同行創(chuàng)新者，否則情況只會(huì)惡化。
隨著有經(jīng)驗(yàn)的開(kāi)發(fā)人員轉(zhuǎn)向更好的平臺(tái)原生的解決方案，跨平臺(tái)項(xiàng)目注定會(huì)是一個(gè)偽裝成創(chuàng)新的巨大漸進(jìn)改動(dòng)。
跨平臺(tái)開(kāi)發(fā)將很快意味著對(duì)于多種設(shè)備的單平臺(tái)開(kāi)發(fā)
在所有的移動(dòng)開(kāi)發(fā)廠商中，蘋(píng)果是唯一一家真正的業(yè)務(wù)線是硬件的公司。隨著他們平臺(tái)的統(tǒng)一，它向開(kāi)發(fā)者發(fā)出了一個(gè)明確的信息：你對(duì)我們的服務(wù)業(yè)務(wù)至關(guān)重要，我們關(guān)心你們的增長(zhǎng)。
現(xiàn)在預(yù)測(cè)其長(zhǎng)期市場(chǎng)主導(dǎo)地位還為時(shí)過(guò)早。谷歌有足夠的財(cái)力來(lái)為其原生安卓平臺(tái)提供燃料，使其對(duì)開(kāi)發(fā)者更有吸引力。
雖然單靠蘋(píng)果無(wú)法撼動(dòng)整個(gè)跨平臺(tái)社區(qū)，但它肯定能夠迫使其競(jìng)爭(zhēng)對(duì)手采用一種更結(jié)構(gòu)化更易于維護(hù)且更不易出現(xiàn)故障的移動(dòng)開(kāi)發(fā)方案。
跨平臺(tái)開(kāi)發(fā)領(lǐng)域?qū)⒑芸煲馕吨鴮?duì)多種設(shè)備的單平臺(tái)開(kāi)發(fā)，就像.NET 早期那樣。
創(chuàng)業(yè)公司最好不要跨平臺(tái)。公共代碼庫(kù)的誘惑必須被良好的老文檔取代，這樣才能在開(kāi)發(fā)人員心中培養(yǎng)真正的通用商業(yè)邏輯。
你的客戶值得原生平臺(tái)提供的最佳統(tǒng)一體驗(yàn)。
你的開(kāi)發(fā)者？休息（不是雙關(guān)語(yǔ)） + 尊敬。
Pen Magnet 創(chuàng)業(yè)作家、程序員、科技職業(yè)博主、教育愛(ài)好者。
https://medium.com/swlh/the-end-of-cross-platform-as-we-know-it-dad658d96b8
END 前線推出學(xué)習(xí)交流群，加群一定要備注： 研究/工作方向+地點(diǎn)+學(xué)校/公司+昵稱（如前端+上海+上交+可可） 根據(jù)格式備注，可更快被通過(guò)且邀請(qǐng)進(jìn)群，領(lǐng)取一份專屬學(xué)習(xí)禮包
掃碼加我微信進(jìn)群，內(nèi)推和技術(shù)交流，大佬們零距離
歷史推薦
網(wǎng)易云音樂(lè)的消息隊(duì)列改造，到底做了啥？ 5個(gè)常用的大數(shù)據(jù)可視化分析工具 VS Code竟然能約會(huì)談戀愛(ài)，找對(duì)象不看臉，主要看編程水平 為什么 Google 的技術(shù)這么牛？ 好文點(diǎn)個(gè)在看吧！
