1：iOS + Android + Webapp

• ? 三個(gè)代碼庫：需要分別為iOS（Swift）、Android（Kotlin）和Web（HTML+CSS+JS）維護(hù)獨(dú)立的代碼庫，Web應(yīng)用的代碼在本地不重復(fù)使用。

• ? 技術(shù)棧要求：開發(fā)人員需要精通iOS的Swift、Android的Kotlin和Web的JavaScript。

• ? 招聘挑戰(zhàn)：由于各平臺的人才池較小，可能難以形成統(tǒng)一的技能基礎(chǔ)，也增加了知識共享和團(tuán)隊(duì)協(xié)作的復(fù)雜度。

• ? 同步問題：維護(hù)和同步三個(gè)代碼庫可能具有挑戰(zhàn)性，因?yàn)樵诓煌脚_實(shí)現(xiàn)功能的難度和開發(fā)效率可能不同。可能需要在某些平臺（如iOS）上延遲發(fā)布功能，等待其他平臺（如Android）的功能開發(fā)完成。不同平臺的應(yīng)用商店審核時(shí)間不同也會(huì)導(dǎo)致發(fā)布時(shí)的延遲。

• ? 優(yōu)勢：一旦發(fā)布，即可立即利用本機(jī)功能和用戶體驗(yàn)改進(jìn)，無需等待第三方實(shí)現(xiàn)。例如，本地先實(shí)現(xiàn)共享元素過渡，然后在Web上復(fù)制。

• ? 啟動(dòng)時(shí)間：由于無需加載React Native或CapacitorJS等第三方框架，應(yīng)用啟動(dòng)時(shí)間可能更快。

2：React Native + React

• ? 兩個(gè)代碼庫：需要分別維護(hù)React Native和React的代碼庫，但可“學(xué)習(xí)一次React”。

• ? Expo OTA/EAS更新：使用Expo OTA/EAS更新，可立即向所有客戶端推送應(yīng)用更新，無需等待App Store審查（對于大幅更改除外，如bug修復(fù)等，這些仍需要通過App Store審查）。

• ? 多平臺支持：React Native不僅支持移動(dòng)設(shè)備，還可運(yùn)行在Windows、macOS甚至tvOS等其他平臺上，符合React Native的多平臺愿景。

• ? 性能優(yōu)勢：借助React Native的新Hermes引擎，應(yīng)用啟動(dòng)時(shí)間可能快到小于1秒。

• ? 后續(xù)升級功能：需等待React Native對每個(gè)平臺發(fā)布新本機(jī)功能的支持或自行實(shí)現(xiàn)，可能需要等待React Native構(gòu)建的bug修復(fù)。特定于iOS或Android的新本機(jī)功能通常需要等到另一個(gè)平臺提供相應(yīng)功能的支持，才能實(shí)現(xiàn)跨平臺利用。

• ? 單體存儲庫：可以在本地和Web代碼庫之間共享一些代碼，如業(yè)務(wù)邏輯、狀態(tài)管理、配置文件（翻譯文件、TS類型、URL端點(diǎn)、貨幣轉(zhuǎn)換等）、API調(diào)用、格式化請求/響應(yīng)數(shù)據(jù)和身份認(rèn)證。但通常不會(huì)共享UI渲染代碼（樣式、動(dòng)畫、導(dǎo)航），因?yàn)橛脩袅?xí)慣會(huì)影響在不同平臺上的外觀和體驗(yàn)一致性。這可能導(dǎo)致在多平臺使用或切換的用戶體驗(yàn)出現(xiàn)不一致性。

• ? 靈活性：不會(huì)受到Web標(biāo)準(zhǔn)化過程及其在各瀏覽器供應(yīng)商中實(shí)現(xiàn)的限制，可依賴或等待React Native生態(tài)系統(tǒng)的庫，或完全自主實(shí)現(xiàn)所需功能。

3. React Native for Web (RNW)

• ? 單一代碼庫：使用React Native Web（RNW），你可以"寫一次React"并在多個(gè)平臺上運(yùn)行應(yīng)用，即使不使用React Native引擎，而是簡單地將React Native API轉(zhuǎn)換為在Web上常用的react-dom API（如將轉(zhuǎn)換為）。

• ? 原生應(yīng)用需求：如果用戶最終需要原生應(yīng)用，最好從一開始就不使用React Native Web，以避免后續(xù)的轉(zhuǎn)換成本。

• ? 生態(tài)系統(tǒng)挑戰(zhàn)：大部分React Native庫并不一定支持Web開發(fā)，反之亦然。這可能導(dǎo)致在本地和Web上難以找到匹配的組件，并編寫一致的包裝組件。截至2022年10月，僅有166/1142個(gè)React Native包被官方支持為Web。React Native的庫數(shù)量約占React生態(tài)系統(tǒng)的24%。截至2022年10月，React在NPM上有212,722個(gè)庫，比React Native多出171,107個(gè)Web庫。因此，如果計(jì)劃僅部署到Web，使用純React可能更為合適。

• ? 技術(shù)選型建議：傳統(tǒng)上，React Native Web更適合單頁應(yīng)用（SPA），它使用CSS-in-JS的StyleSheet.create解決方案。但對于需要服務(wù)端渲染（SSR）以及響應(yīng)式設(shè)計(jì)（通過CSS媒體查詢），一些人可能會(huì)感到困擾。

• ? 解決方案推薦：推薦使用Tamagui來獲得最佳體驗(yàn)和SSR兼容性。Tamagui將您的樣式編譯為CSS媒體查詢，解決了上述問題，并提供了輕量級的原始樣式系統(tǒng)和功能齊全的組件UI庫。社區(qū)已經(jīng)制作了tamagui-extras以提供更多組件。

• ? 導(dǎo)航/路由解決方案：推薦使用跨平臺導(dǎo)航/路由解決方案如Solito（統(tǒng)一了react-navigation和nextjs/router）、react-native-url-router（使用React Router + react-native-screens + react-native-pager-view）或即將推出的Expo Router（基于expo-auto-navigation的概念驗(yàn)證/實(shí)驗(yàn)）。

• ? 折中方案：一種折中的方法是只使用RNW構(gòu)建基本組件庫（如按鈕、標(biāo)題、卡片等），而不共享導(dǎo)航/路由和樣式。

• ? 手勢交互：在瀏覽器中實(shí)現(xiàn)手勢交互（如滑動(dòng)）可能并不直接，因?yàn)槭褂肅SS或JS的方法多種多樣且質(zhì)量參差不齊。由于React Native專為移動(dòng)設(shè)備設(shè)計(jì)，它更適合處理手勢交互。因此，可以考慮重用現(xiàn)有的React Native手勢庫。

4.Flutter

• ? 單一代碼庫：Flutter使得開發(fā)獨(dú)立的iOS（Swift）和Android（Kotlin）原生應(yīng)用的工作量減少至約一半。如果適用于您的用例，F(xiàn)lutter Web 可能僅需大約三分之一的工作量，因?yàn)樗梢詣?chuàng)建Web應(yīng)用。

• ? 語言要求：必須學(xué)習(xí)Dart語言來開發(fā)Flutter應(yīng)用。

• ? Flutter Web的適用性：Flutter團(tuán)隊(duì)自稱，F(xiàn)lutter Web不適合面向內(nèi)容/文檔的應(yīng)用或需要服務(wù)端渲染（SSR）和搜索引擎優(yōu)化（SEO）的應(yīng)用，因?yàn)樗鼘⑺袃?nèi)容渲染到單一的Canvas上。然而，對于跨平臺游戲開發(fā)，F(xiàn)lutter與Flutter Web可能特別有用。

• ? 統(tǒng)一UI優(yōu)化與平臺差異：Flutter提供完全控制的渲染，雖然以犧牲特定于平臺的功能和外觀為代價(jià)，但通過優(yōu)化實(shí)現(xiàn)了跨平臺統(tǒng)一的用戶界面。Flutter提供了Cupertino小部件來模擬iOS外觀，同時(shí)使用Material UI小部件來支持Android外觀。您還可以使用flutter_platform_widgets自動(dòng)選擇UI小部件的外觀，根據(jù)運(yùn)行平臺（iOS或Android）進(jìn)行適配。

• ? 原生UI創(chuàng)新和迭代：每個(gè)平臺的新的原生UI功能可能會(huì)稍有延遲，因?yàn)樗鼈冃枰贔lutter中重新實(shí)現(xiàn)。

• ? Flutter與其他框架的比較：在架構(gòu)層面上，F(xiàn)lutter與React Native和原生iOS應(yīng)用（Native）相比，提供了不同的混合應(yīng)用開發(fā)方法。雖然Flutter和React Native都可以被視為混合開發(fā)的一種形式（因?yàn)樗鼈儾皇羌冊模恰盎旌稀币辉~通常用于描述通過Web View在原生外殼或封裝應(yīng)用中渲染W(wǎng)eb應(yīng)用的方法，這些方法通常只需一個(gè)代碼庫。

5. CapacitorJS + Webapp

• ? 原生API訪問：CapacitorJS 提供了一個(gè)WebView，允許你訪問原生API。

• ? UI外觀：使用Ionic UI工具包，可以實(shí)現(xiàn)原生外觀，或者選擇Framework7來復(fù)制iOS和Android組件的樣式。

• ? 框架選擇：Web應(yīng)用程序可以使用任何Web框架構(gòu)建，如Solid、Vue、Svelte或Qwik。

• ? 原生插件：Capacitor支持使用NativeScript和NativeScript插件。

• ? 性能對比：與React Native的UX/性能對比，或者React Native與Ionic React+Capacitor的對比。

• ? 打包策略：Capacitor默認(rèn)會(huì)將整個(gè)Web應(yīng)用打包到App Store包中，以避免從Web加載，確保應(yīng)用不會(huì)因缺乏原生功能而被拒絕。

• ? 即時(shí)更新：Ionic Appflow或Capgo可以解決App Store發(fā)布問題，實(shí)現(xiàn)近乎即時(shí)的代碼更新。

6.Hotwire Turbo Native + Webapp

•  混合導(dǎo)航體驗(yàn)：結(jié)合原生導(dǎo)航和網(wǎng)絡(luò)內(nèi)容，實(shí)現(xiàn)混合原生和網(wǎng)頁屏幕的無縫體驗(yàn)。

• ? 共享WebView：使用iOS的WKWebView和Android的WebView，實(shí)現(xiàn)跨平臺的WebView重用。

• ? 框架兼容性：雖然Hotwire Turbo Native最初為Ruby on Rails開發(fā)，但也可與其他框架配合使用。

• ? HTML在線傳輸：通過HTML在線傳輸，簡化開發(fā)流程，無需構(gòu)建復(fù)雜的SPA和API，支持MPA方法或結(jié)合SPA+MPA的混合方法。

• ? Hotwire Strada：提供標(biāo)準(zhǔn)化的橋接，簡化原生導(dǎo)航的實(shí)現(xiàn)。盡管原計(jì)劃2021年發(fā)布，但因開發(fā)人員變動(dòng)推遲至2022年，但即便沒有Strada，Turbo Native仍可立即使用。

• ? 避免混淆：注意Hotwire的Turbo Native與React Native的Turbo Native模塊架構(gòu)、Turborepo構(gòu)建系統(tǒng)或Turbopack打包工具不要混淆，它們各自服務(wù)于不同的技術(shù)棧和需求。

6.1 Turbo Native 搭配 iOS + Android shell

• ? 默認(rèn)應(yīng)用選擇：Turbo Native 是使用 Hotwire Turbo 構(gòu)建應(yīng)用的默認(rèn)選項(xiàng)。

• ? 原生外殼：Turbo Native 包含 turbo-ios 和 turbo-android，它們是為 iOS 和 Android 分別設(shè)計(jì)的外殼/包裝應(yīng)用。這些應(yīng)用提供即開即用的體驗(yàn)，但在需要維護(hù)和調(diào)試 iOS 和 Android 開發(fā)時(shí)，可能需要額外處理。

• ? 導(dǎo)航模式限制：您必須自行處理自定義導(dǎo)航和過渡。

• ? 原生屏幕/功能：任何潛在的原生屏幕或功能都必須使用 Swift (iOS) 和 Kotlin (Android) 編寫。

• ? 性能對比：與 React Native 外殼相比，使用這些特定的原生外殼（適用于 iOS 或 Android）可能會(huì)有更快的啟動(dòng)時(shí)間。

• ? 推薦演示：根據(jù) Basecamp CTO DHH 的說法，Turbo Native for iOS 或 Turbo Native for Android 的演示是最佳的開始方式。

• ? 開發(fā)人員訪談：2021年8月2日，開發(fā)人員 Jay Ohms 主導(dǎo)的播客提供了關(guān)于整體方法的更多信息。

• ? SaaS 產(chǎn)品集成：如果您使用 Ruby on Rails 并且正在構(gòu)建 SaaS 產(chǎn)品，Jumpstart Rails 似乎可以為您節(jié)省大量工作，并且價(jià)格合理，且與 Turbo Native 集成。2022年5月23日的播客采訪提供了更多細(xì)節(jié)。

6.2 Turbo Native 搭配 React Native shell

• ? React Native Turbo 實(shí)現(xiàn)：通過使用 react-native-turbo，可以在 GitHub 上找到名為 react-native-turbo-demo 的示例。

• ? 工作原理：react-native-turbo-demo 提供了對 Turbo Native 工作原理的直觀理解，如果你想在 React Native 中嘗試實(shí)現(xiàn)類似功能，可以參考這個(gè)示例。

• ? 原生屏幕開發(fā)：允許使用 React Native 來編寫原生屏幕，對于不想學(xué)習(xí) iOS 和 Android 開發(fā)的 Web 開發(fā)人員來說，這非常有用。

7.React Native WebView

• ? 看似矛盾的選擇：盡管聽起來有些反常，但你可能會(huì)更傾向于采用 React Native Web。

• ? 快速移動(dòng)端移植：如果你需要將現(xiàn)有的網(wǎng)絡(luò)應(yīng)用快速移植到移動(dòng)端，特別是為了利用 iOS 推送通知功能（此功能于 2023 年 2 月 16 日發(fā)布，僅適用于 iOS 16 及以上版本的用戶，且在 Safari 中暫不可用），這種方法可能非常有用。一些開發(fā)者通過這種方法取得了成功，避免了傳統(tǒng) React + React Native 方法所需的雙倍代碼庫。

• ? 豐富的第三方包生態(tài)系統(tǒng)：與 Capacitor 等其他框架相比，React Native 的第三方包生態(tài)系統(tǒng)更為豐富，這可能是選擇 React Native 作為外殼應(yīng)用的原因。此外，將屏幕轉(zhuǎn)換為 React Native 屏幕也相對容易。

• ? 部署優(yōu)勢：與通過 App Store 部署相比，這種方法可能有助于實(shí)現(xiàn)更快的部署流程。盡管對于僅使用 React Native (Web) 制作的應(yīng)用，Expo OTA / EAS Update 也能實(shí)現(xiàn)快速部署，但你仍需關(guān)注這些工具的使用。

• ? App Store 審核風(fēng)險(xiǎn)：如果 React Native 外殼應(yīng)用沒有充分利用原生功能來增強(qiáng) Web 應(yīng)用，可能會(huì)面臨 App Store 的審核拒絕。僅僅添加推送通知可能不足以被視為足夠的原生功能。因此，保持謹(jǐn)慎并確保應(yīng)用符合 App Store 的要求是明智的。

• ? 兼容性：此方法不僅適用于使用 React 制作的應(yīng)用，還可以與任何 Web 框架或渲染庫制作的 Web 應(yīng)用一起使用。盡管在 React Native 外殼上工作時(shí)，React 可以實(shí)現(xiàn)一些知識的重用。

• ? 共享與重用：如果需要將應(yīng)用重寫為完全的 React Native 應(yīng)用，使用 React Native 外殼可以加速這一過程。

• ? 通信橋接：react-native-react-bridge 是一個(gè)橋接工具，它簡化了通過 WebView 在 React 和 React Native 之間的通信，或者你可以嘗試通過直接在 WebView 和 React Native 組件之間運(yùn)行彼此的函數(shù)來簡化通信。

8.NativeScript + Webapp

• ? 原生平臺支持：NativeScript 提供了 iOS 和 Android 的運(yùn)行時(shí)環(huán)境。

• ? 原生 API 訪問：通過 JavaScript 可以直接訪問原生平臺的 API。

• ? 聲明式 UI：支持使用基于 XML 的語言和 CSS 子集來聲明 UI。

• ? 跨平臺應(yīng)用構(gòu)建：通常，開發(fā)者會(huì)構(gòu)建一個(gè) Web 應(yīng)用，并通過以下方式實(shí)現(xiàn)跨平臺：

• ? 使用 CapacitorJS 訪問原生 API，將 Web 應(yīng)用與 App Store 發(fā)布的應(yīng)用捆綁，實(shí)現(xiàn)更快的啟動(dòng)速度。

• ? 制作 NativeScript 包裝器/外殼應(yīng)用，通過 NativeScript 的 WebView 渲染 Web 應(yīng)用，便于更新但可能影響啟動(dòng)速度。

• ? NativeScript 與 Angular 和 Vue 集成，允許在不使用 WebView 的情況下實(shí)現(xiàn)代碼共享。

• ? Web 上的 NativeScript：NativeScript 直接在 Web 上運(yùn)行仍是一個(gè)待解決的問題。

• ? React NativeScript：提供了一種選擇，允許使用 React 與 NativeScript 結(jié)合，適合那些希望為 React 編寫原生模塊但又不想使用 Swift/iOS 和 Kotlin/Android 的開發(fā)者。

• ? 成熟度和社區(qū)：NativeScript 在 2021 年 4 月 12 日時(shí)被認(rèn)為還不夠成熟，部分原因是生態(tài)系統(tǒng)中許多插件存在問題。一位早期和多產(chǎn)的貢獻(xiàn)者在 2022 年 7 月 1 日離開了項(xiàng)目。社區(qū)規(guī)模相對較小，與 Flutter 或 React Native 相比，NativeScript 的貢獻(xiàn)者數(shù)量較少。

9.Xamarin

• 代碼共享：Xamarin Forms 允許在不同平臺間共享高達(dá)98%的相同代碼，這對于實(shí)現(xiàn)跨平臺應(yīng)用的開發(fā)非常高效。

• ? API 完整性：Xamarin Forms 提供了100%的API覆蓋率，這意味著開發(fā)者可以訪問所有原生平臺的API，無需編寫額外的本機(jī)包裝器。

• ? 適合C#開發(fā)者：對于已經(jīng)擁有C#開發(fā)人員和C#后端服務(wù)的企業(yè)來說，Xamarin Forms 提供了一個(gè)無縫的開發(fā)體驗(yàn)，因?yàn)樗鼈兛梢岳矛F(xiàn)有的C#技能和資源。

10.PWA(漸進(jìn)式Web應(yīng)用程序)

• ? 移動(dòng)設(shè)備訪問：PWA 允許用戶通過移動(dòng)設(shè)備的主屏幕添加應(yīng)用程序快捷方式，實(shí)現(xiàn)類似原生應(yīng)用的訪問體驗(yàn)。

• ? 跨平臺能力：PWA 幾乎可以在任何支持瀏覽器的平臺上運(yùn)行，但不使用原生組件，用戶體驗(yàn)可能略遜于原生應(yīng)用。

• ? Konsta UI：Konsta UI 提供了基于 Tailwind CSS 的移動(dòng)組件，實(shí)現(xiàn)了 iOS 和 Android 設(shè)計(jì)風(fēng)格，是 Ionic 的現(xiàn)代替代品。

• ? 潛在挑戰(zhàn)：對于使用 SPA 架構(gòu)并重新實(shí)現(xiàn)基本瀏覽器功能的 Web 應(yīng)用，PWA 可能面臨加載時(shí)間長、滾動(dòng)體驗(yàn)差等問題，但這些問題可通過優(yōu)化解決。

• ? 技術(shù)棧簡化：PWA 通常使用 HTML、CSS 和 JavaScript 構(gòu)建，簡化了技術(shù)棧，減少了重復(fù)工作。

• ? 安裝過程：PWA 不通過應(yīng)用商店安裝，用戶可能需要引導(dǎo)才能將其添加到主屏幕，這可能需要額外的市場教育。

• ? 推送通知：PWA 在 iOS 上長期缺乏推送通知支持，但隨著 iOS 16 的發(fā)布，蘋果開始支持推送通知，為用戶提供了一種新的通知方式。

• ? 渲染庫選擇：PWA 支持多種渲染庫，如 React、Solid、Voby、Qwik、Vue、Svelte 等，開發(fā)者可以根據(jù)項(xiàng)目需求選擇合適的庫。

• ? 原生權(quán)限訪問：現(xiàn)代瀏覽器為 Web 應(yīng)用提供了廣泛的原生權(quán)限訪問，盡管仍有一些功能尚未實(shí)現(xiàn)。

• ? 桌面集成：PWA 可以通過 Electron 或 Tauri 等框架引入桌面環(huán)境，實(shí)現(xiàn)跨平臺的桌面應(yīng)用體驗(yàn)。