作者 | Sebastiano Poggi
審校 | 丁曉昀、核子可樂
本文整理自 QCon Plus 演講，Sebastiano Poggi 是 JetBrains 的開發專家，這次演講他主要讨論了在原生和跨平台移動開發之間進行選擇所需的技術知識和工具。
原生還是跨平台？
是時候抛開一切紛紛擾擾，專心聊聊原生和跨平台這個老大難選題了。從某種意義上講，原生永遠有自己的比較優勢，其性能永遠是任何跨平台架構都望塵莫及的。原生應用也能更好地跟作業系統、第三方庫相內建，擁有更龐大且技術支援更給力的社群生态。另外，人家“原生”二字可不是白講的，能夠更好地通路作業系統上的 API 和功能，支援 tvOS 乃至各種可穿戴裝置。如果大家更關注這些需求，那原生開發就是最正确的答案。另外，原生開發工具也在不斷改進，甚至 Xcode 如今也變得不那麼惱人了。當然，原生開發也有自己的問題，否則跨平台架構根本就不會出現。
原生的頭号難題，就是成本更高，企業需要為每種作業系統籌建專門的開發團隊，具體考慮基礎設施和流程中的注意事項。例如，我們可能需要為 Android 和 iOS 設定不同的持續內建（CI）流程。當然，這種情況在跨平台開發那頭也存在，畢竟兩種平台間的工具存在很大差異。此外，在把應用程式部署和釋出到蘋果 App Store 或者 Google Play Store，乃至 Android 平台上千奇百怪的軟體商店時，都有相應的規章制度需要遵守。他們各有不同的釋出标準、周期和要求，必須早做打算。
結合實際情況，跨平台可能才是大多數開發者最務實的選項。畢竟跨平台架構的效果基本夠用，有時候甚至不比原生移動平台差。而且經過多年發展，跨平台架構也迎來了巨大改進，比如說 Flutter 和 React Native 都開始支援熱重載，這樣大家就能像在 Web 上那樣測試各種變更，無需将應用程式重新部署到裝置或虛拟機上。但在選擇跨平台時，我強烈建議大家先選擇一種強大的設計語言，要明确跟 Android 和 iOS 區分開來。因為一旦你的設計太偏向于其中一種，那就會跟另外一種顯得格格不入。另外，如果不用原生控件，大家會很難模仿平台上的原生觀感和體驗。總之，軟體開發就是這樣一道 80%都較簡單，但最後 20%完善部分異常困難的大題。感興趣的朋友不妨試試 Duolingo——這雖然是一款原生應用，但卻能給跨平台開發者們好好上一節設計語言課。
以可穿戴裝置為例，來一場虛構案例的頭腦風暴
假定有這麼一家可穿戴裝置廠商，他們想要搞一款配套應用。比如說智能手表吧，他們希望在這款裝置上進行通信、資料下載下傳、顯示曆史趨勢。沒錯，這肯定是需要應用來實作的，使用者不可能總跑去浏覽網頁。下面問題就來了：我們需要的是原生應用嗎？其中是否大量通路作業系統 API？畢竟這就是原生代碼的優勢所在。而答案是肯定的，智能裝置需要在背景執行大量操作，是以肯定會經常通路作業系統 API。跨平台架構雖然能在藍牙等少部分比對機制上表現良好，但要對應用的所有功能有更好的把控力，原生恐怕才是正确答案。是以可穿戴裝置這類場景的判斷就很簡單，原生是要好過跨平台開發的。
架構選擇：React Native、Xamarin 還是 Flutter
我們總在讨論原生和跨平台，但這裡所說的“跨平台”到底對應哪種架構？目前的三大主流選項分别是 React Native、Xamarin 和 Flutter，當然還有基于 Web 的架構，比如 Cordova、Ionic 和 PhoneGap 等。這裡還有 Kotlin 值得一提，這是由 JetBains 設計并與其他公司合作開發的語言。但至少在基于 Web 的跨平台開發方面，我會盡量避免使用後面這幾種選項，畢竟它們往往過于陳舊且性能不佳。其中比較特殊的是 Kotlin 多平台，它跟 React Native、Xamarin 和 Flutter 有很大不同，相對更側重共享業務邏輯而非 UI 設計。是以在本文的讨論中，我們就專注于 React Native、Xamarin 和 Flutter 這三位。
React Native
React Native 是 Facebook 開發的一項技術，并以同樣來自 Facebook 的 ReactJS 為基礎。這樣做的好處是，如果您的企業中已經擁有經驗豐富的 ReactJS 開發團隊，那完全可以向 Web 團隊分享一些技能甚至是代碼。React Native 還對桌面、可穿戴裝置和智能電視等擁有實驗性的第三方支援。但大家千萬别因為關注這些元素而貿然選擇 React Native，因為這方面功能還遠稱不上成熟。React Native 本身倒是既強大又完善，完全可以用來開發 B2C 應用。實際上，市面上已經有很多大型 React Native 應用可供選擇。雖然在性能方面仍在局限，但 React Native 最近幾年來一直在探索和改進。不過如果各位開發的應用裡有大量動畫元素，那建議先别考慮 React Native。另外要注意的是，如果想要自定義 UI 元件，就得為不同的平台分别建立實作，這個過程相當枯燥。可好處是 React Native 确實能讓 UI 充滿了“原生範”，畢竟它确實用了不少原生的資産。最後說點壞消息，近年來不少知名應用都放棄了 React Native，其中的典型案例當數 Airbnb。但這跟我們自己的開發需求可能并無關系，結合自身實際才有指導意義。
Xamarin
Xamarin 走的完全是另一個路子。它是由微軟開發的工具，之前曾經收費，現在已經免費開放且開源。如果貴公司在 C#資産上投入了很多，而且也用過 ASP.NET 和 C#，那 Xamarin 将助您建立起從後端到前端的完整.NET 棧。從某種意義上講，Xamarin 的 UI 實作方法相當獨特。大家可以使用 Xamarin.Forms 探索多平台，也可以像 React Native 那樣采取原生視圖（但後者其實用得不多）。總之，Xamarin 跟 React Native 和 Flutter 的脾性正相反，強調貼近源作業系統 API。也就是說，開發者必須也了解作業系統，才能玩轉 Xamarin，畢竟後者的作用就是自動打包來自 Native SDK 的現有 API 并在 C#中公開。Xamarin 的第三方支援有限，可用的原生 Xamarin 庫不多。就個人來看，Xamarin 可能更适合那些内部應用，或者相對複雜度不高的應用程式。它更多面向企業，在開發 B2C 應用時最好别用。
Flutter
自谷歌的 Flutter 這套架構的人氣正在迅速上漲。谷歌對 Flutter 投入了大量營銷和宣傳，架構本身的水準也絕不拉胯。首先，Flutter 擁有衆多高品質的第一方和第二方內建，使用 Dart 語言并配合 Pub 生态作為依賴項。從技術上講，我們幾乎可以使用 Flutter 滿足一切開發需求——面向移動端、面向桌面端，還能支援 macOS、Windows 和 Linux，甚至是 Web 和嵌入式物聯網。簡單來講，任何能夠運作 Android APK 的地方都能運作 Flutter 應用。據我所知，它目前尚不支援的就隻有 WatchOS 和 tvOS 了。但如果真有需要，我也認識能幫大家解決問題的人。如果您的開發團隊熟悉 Dart，也可以直接用它做 UI。這就是 Flutter，因為出自谷歌之手，是以毫不掩飾地向 Android 開發者群體瘋狂示好。
下面咱們通過幾組統計數字，看看跨平台開發目前的市場規模。縱觀 Google Play Store 和蘋果 App Store 上采用跨平台架構的應用，可以看到 Cordova 在 iOS 上占比 17%，在 Android 端則占比 20%。React Native 位列第二，雙平台份額均稍遜 5%。Flutter 則緊随其後，而且繼續表現出強烈的親 Android 傾向。Ionic 和 Xamarin 完全無法跟前三甲相匹敵，接下來還有已經過時淘汰的 Titanium/Appcelerator 架構等。
這些數字也有沒講出來的“小秘密”，比如實際使用跨平台架構的開發者占比隻有三分之一。就是說如果選擇跨平台開發，就相當于放棄掉了市場上三分之二的候選人才。另外，中長期曆史趨勢顯示，Web 開發架構統計中 React Native 和 Xamarin 也赫然在列。過去三年來，使用跨平台開發技術的人數正在下降，其中 React Native 相對保持穩定，其他架構則情勢危急。另一方面，Flutter 則保持上升勢頭，有 42%的移動應用都在使用。最後，Kotlin 多平台開發也走勢良好。
虛構案例研究 II：金融科技業務
我們假定有一家金融科技公司，這樣的企業需要業務應用嗎？那是肯定的，畢竟競争對手都有自己的應用，是以咱也不能缺項。那需要是原生應用嗎？我們還是用之前提到過的标準來判斷，比如是否需要大量使用作業系統 API？答案是并不需要。雖然這類應用會頻繁用到通知功能，但這個問題已經有成熟解決方案，不需要額外費心。那使用者要用這款應用來幹什麼？假定用途是檢視股票價格，随時查詢并收取通知，那這些确實都用不着勞原生開發的大駕。選擇了跨平台之後，接下來是選擇哪種架構的問題。首先，假定這家公司沒有 ReactJS 團隊，比如他們之前用的是 Angular，内部也沒有經驗豐富的.NET 人才，那麼 React Native 和 Xamarin 就都被排除掉了。他們大量使用 Firebase 服務，而且需要多種自定義使用者界面，包括美觀的圖形和精緻的動畫，那麼綜合來看最理想的選項就是 Flutter。
移動端測試
最後，就是在移動裝置上做測試。注意，移動裝置上的單元測試同樣有成熟方案，真正的問題出在 UI 測試方面。Flutter 提供的 UI 測試可謂冠絕群倫，相比之下原生開發和 React Native 使用的還是各平台自己的工具。Xamarin 也差不多，但我印象中它用的是針對各平台開發的自定義工具。
在持續內建（CI）中運作 UI 測試時，往往需要運作緩慢的上機測試——可能是實體實機，也可能是模拟機。有些雲服務商雖然提供 UI 測試裝置，但設定和維護起來非常複雜、使用成本也相當昂貴。經典的解決方案就是做更多的單元測試，這一點在 Android 端特别重要。以 Robolectric 為例，它就能幫我們将內建測試作為單元測試來運作。面向移動項目的專有持續內建解決方案也不少見，比如 Bitrise 等。
決策審查
做出了開發決策，那麼在着手開發應用的同時，我們也該看看自己選得對不對、目前有哪些實際困難。畢竟很多錯誤不會立刻就顯現出危害。比如說，某些廠商在幾年之後放棄了 React Native，類似的情況最終也可能出現在 Flutter 當中。總之，請随時關注事态發展。問題發展得越早，我們的沉沒成本也就越低。
總結
第一，考慮移動開發到底有沒有必要。記得用資料來回答問題，别靠想象。
第二，確定企業有能力做移動開發，然後厘清組織結構和團隊職責。
第三，在做出決策之前評估權衡要素，意識到不存在百試百靈的最優選項，充分了解自身實際。
第四，做出正确選擇并努力推進。
互動問答
主持人：您讨論了好幾種行之有效的實作方式。根據個人經驗，您在絕大多數情況下會選擇哪一種？
Poggi：我自己就是搞原生開發出身的，是以在這個問題上有明顯的傾向性。但如果說必須要搞跨平台開發，那我可能更願意選擇 Flutter，因為我有一點這方面的經驗。雖然我不太熟悉 Dart，但它跟 Java 其實挺像的、也不難了解。作為次優選項，我可能會選擇 React Native。但先要承認，我對 JavaScript 一無所知，是以這麼選對不對我也不敢說。總之，隻要掌握了聲明式、響應式 UI 架構的工作原理，那不同的架構往往隻對應不同的語義和語言特性，在本質上還是相通的。
主持人：所言極是，大家在實際選擇時恐怕還是會以自己熟悉的語言為導向。
參考連結：
https://www.infoq.com/presentations/tools-native-cross-platform/
相關閱讀：
為什麼說 Flutter 無法成為移動應用開發的“頂流明星”？
Google 路線圖：Flutter 與 JavaScript、Wasm 內建
Flutter 和小程式容器技術的應用前景與發展潛力
移動應用架構與 React Native、Flutter 的關聯