2020年了，跨平臺開發框架現在怎樣了？
轉載請註明出處：葡萄城官網，葡萄城為開發者提供專業的開發工具、解決方案和服務，賦能開發者。
原文出處：https://dzone.com/articles/cross-platform-mobile-development-2020-trends-and
多年來，跨平臺移動開發已經獲得了最流行軟體開發趨勢之一的聲譽。這並不令人意外，因為採用跨平臺開發技術使得軟體工程師使用同一程式碼就能為不同平臺構建應用程式，從而節省時間、金錢以及不必要的工作。
移動市場的現狀
截至2019年12月，全球活躍網民已超45億。他們每人平均上網時間為6小時42分鐘，相當於每年上網超過100天。
再加上人們越來越渴望從掌上裝置中獲取海量的資訊，也就為之所以移動應用程式會如此受到歡迎提供了合理的解釋。截至 2019 年，全球移動應用收入達 4610 億美元，預計到 2023 年，付費下載和應用內廣告的收入預計將超過 9350 億美元。
移動開發的技術選型
十年前，老闆們必須決定他們的產品將涵蓋哪些移動作業系統：Android、iOS、微軟、RIM或Symbian。而今天，初創公司的創始人正面臨著一個不同的兩難抉擇，由於Android和iOS佔據了移動作業系統市場份額的98%，很顯然這兩個系統不容忽視，覆蓋什麼平臺不再是問題。但問題是，構建一個在兩個平臺上都可以使用的應用程式應該採用什麼方法？
每個作業系統對應一種開發環境
顧名思義，用於開發Android用的是Java或Kotlin，用於開發iOS則是Objective-C或SWIFT。作為開發不同應用而使用不同的開發語言，對開發者而言並不是一個好訊息。
雖然特定的開發環境對特定的作業系統擁有對資源更高效的調配效率，可防止發生效能問題。但缺點也很顯而易見，你的開發人員需要使用不同的開發語言構建兩個獨立的應用程式，這需要付出更多的時間、金錢和精力。
漸進式Web應用程式（PWA）
其中一個能解決問題的例子是漸進式 Web 應用（PWA），它基本上是模仿原生應用程式行為的一個網站（例如，在傳送推送通知、離線工作，或者只是新增到移動裝置的主螢幕上)。然而，就像任何其他選項一樣，PWA也不是完美無缺的，因為它們消耗更多的電池，並且不能授予應用使用裝置的所有功能。
跨平臺應用程式開發
但還好我們還有一個跨平臺開發的選項，它允許用一段程式碼同時為兩個作業系統開發應用。它並不固定使用某一種平臺的程式語言編寫程式碼。而且，由於直接使用了系統原生控制元件來呈現介面，它能為使用者提供近乎原生平臺應用的使用體驗。
我要不要使用跨平臺開發這項技術？
下面，我會通過一系列維度來幫助你去評估你是否應該採用跨平臺開發這種形式來適配你的業務。
平臺
首先，也是最重要的，您需要決定您的應用程式是需要在一個還是多個作業系統上可用。如果您的目標群是由不同平臺的使用者組成的，那麼跨平臺開發將是首選的解決方案。
另一方面，如果你的使用者群體只是Android或iOS的某一支，那麼用原生解決方案來開發是你的首選。
複雜性
此標準涉及你希望與產品走多遠。解決此問題的一種方法是你的目標是使用MVP測試你的願景，或是你準備使用成熟的應用程式開始執行。您需要回答的另一個問題是產品的功能(例如，訪問移動裝置的硬體或特定於平臺的功能)。
原生體驗
你的使用者是否需要使用原生或近似原生的體驗。使用Material Design(Android)或Human Interface Guidance(iOS)來設計的移動應用程式是移動產品對使用者直觀且友好的原因所在。在設計移動應用程式時應要考慮這些，但是，你可以使用跨平臺框架來實現類似的效果。
時間和成本
有一點是肯定的，原生開發成本不低、效率也不高。為不同的平臺構建不同的應用程式需要僱傭更多的開發人員，這可能會導致初創公司在專案初期就超出緊張的專案預算。同時，如果採用跨平臺的方法，你可以將專案外包給一個規模較小但同樣專業的團隊，這既是一個省時的解決方案，也是一個具有成本效益的解決方案。
跨平臺移動應用開發的優點（和缺點）
假設你已經得出結論，你更傾向於跨平臺的移動應用程式開發，但是在下決心之前，你需要對此解決方案的優缺點進行徹底的瞭解，沒關係，下面我逐一為你列舉。
跨平臺移動應用程式開發的好處
更廣泛的市場覆蓋範圍
雖然我們每個人都有自己喜歡的移動作業系統，但個人喜好不會妨礙你業務的成功。讓Android和iOS使用者同時可以使用您的移動應用，能在未來提升更高的收錄打下基礎。
一套程式碼
跨平臺開發允許您同時編寫包含多個作業系統的程式碼（有時也會有處理平臺差異）。儘管如此，一套程式碼肯定會影響軟體開發過程中的所有階段，因為它可能為你節省通常花在修復和升級兩組獨立程式碼上的成本。
更高效的釋出流程
儘管只需要一套程式碼，但跨平臺應用程式開發仍然需要開發人員考慮處理系統差異的方法，例如釋出應用到平臺商店的過程。
這種方法將縮短從設計到釋出的時間。換句話講，這可以為你節省很大一筆初始專案預算。
平臺一致性
毫無疑問，Android和iOS在使用者體驗和使用者介面方面都有很大的不同，這些差異中的大多數部分都能通過跨平臺開發框架幫你預設處理，這使得設計和實際表現不一致的情況發生的可能性進一步降低。
有什麼缺點？
儘管有上述各種優點，但它也絕不是一點缺點沒有，它的主要缺點包括效能可能較低及略差的使用者體驗和使用者介面等。
2020年還有哪些跨平臺移動開發框架值得考慮
雖然跨平臺的移動APP開發有利有弊。但從業務初創的角度來看，優點應該是大於缺點的。而且，隨著對跨平臺移動應用需求的不斷增長，現在可用的工具和框架數量也已經很可觀了。
但選擇過多會令人頭疼，這就是為什麼我們只關注最突出的跨平臺移動開發框架的原因：React Native, Flutter, NativeScript, 和Xamarin。
為了讓你更深入地瞭解是什麼使這些工具成為2020年軟體開發的可選選項，我們將根據以下標準對它們進行打分：社群支援、基於的程式語言、程式碼可重用性、效能、介面以及使用它們構建的重要應用程式。
React Native
Reaction Native是Facebook於2015年釋出的開源、跨平臺的應用開發框架。作為2013年舉辦的一場內部黑客馬拉松的產物，它已經成為最受歡迎的原生App開發替代方案之一，擁有2043名GitHub貢獻者，獲得了超過82900 GitHub標星。不斷增長的社群認知度使得找到一支可靠且經驗豐富的開發團隊來承接你的專案變得相對容易。
Learn Once and Write Anywhere
基於React.JS，React Native利用JavaScript(根據2019年Stack Overflow的調查，JavaScript成為了最受歡迎的程式語言)，為Android和iOS使用者提供真正原生的應用外觀和體驗。另外，使該框架脫穎而出的是，如果你需要，React Native允許你使用Java、Objective-C或SWIFT編寫部分原生模組來順利處理複雜的操作，如視訊播放或影象編輯。
雖然這些元件不能在不同的平臺之間共享，並且需要開發人員做更多的工作，但多達90%的React Native程式碼是可以重用的。很好地表明該框架的座右銘不是“Write Once, Use Anywhere”，而是“learn once, write anywhere”。
就GUI而言，React Native可以提供接近原生的使用者體驗，這要歸功於它使用了Android和iOS的本地控制器。它還使用帶有UI元素的ReactJS庫，這有助於加快UI設計過程。在開發移動應用程式時，使此框架值得考慮的另一個原因是，它可用在不丟失應用程式狀態的情況下對UI進行更改。
另一個使React Native成為2020年跨平臺移動開發框架的首選之一，是因為持續的更新，例如近期的版本 0.60 和 0.61 ：
- 多項輔助功能改進。
- 更清晰、更人性化的開始螢幕。
- 快速重新整理，融合了實時和熱重新載入，從而顯著加快了開發程序。
如上的Release Note只是React Native適應不斷變化的需求其中一個很小的樣本。
Flutter
2020年值得考慮的第二個框架是Flutter。它在Google I/O 2017上宣佈，並於2018年釋出，對於跨平臺的世界來說，它現在仍然是一個“新人”。但儘管如此，它已經獲得了超過80500 GitHub星標和絕大多數工程師將其稱為2019年Stack Overflow調查中最受歡迎的三個框架之一，Flutter無疑是一股不可忽視的力量。
Dart是如何使Flutter變得獨一無二的
Flutter 背後的程式語言是 Dart，谷歌稱之為"客戶端優化"，適合在任何平臺上"快速構建應用程式"。它於 2011 年推出，是一種響應式面向物件的語言，被開發者認為相對容易學習，其中原因有二：第一，語法上它借鑑了C/C++ 和 Java; 第二，在官方網站上，您可以找到內容廣泛且相當簡單的文件。值得一提的是，Dart 附帶了大量Flutter 相容軟體包的軟體包，允許您使應用程式更加複雜。
Flutter的一個主要優勢是，它的效能比本文提到的任何其他跨平臺移動開發框架都要好。這歸功於Dart的編譯器和Flutter擁有自己的一套小部件。結果是它能更快、更直接地與平臺直接通訊，而不需要JavaScript橋(例如，Reaction Native就是這種情況)。說到小部件：通過Flutter的“UI-as-a-code”方法，它們只用DART編寫，這就提高了程式碼的可重用性。
效率與使用者體驗和介面密不可分。如前所述，Flutter不依賴於一組原生元件，而是利用視覺化、結構化、平臺性和互動式小部件進行UI的設計，所有這些都由框架的圖形引擎呈現。更重要的是，Flutter留下了很大的定製空間，如果你想要設計一個很完美的UI，它是個很好的選擇。
說到Flutter的更新，最新的穩定版本是在12月12日釋出的，根據官方釋出說明，它合併了來自188個貢獻者的近2000個pull。例如，版本1.12.13中包括的改進：
- 重大的API變動。
- 新功能，例如SliverOpacity小部件和SliverAnimatedList。
- 修復了崩潰和效能問題。
- Beta版中的Web支援。
這不是一個完整的清單，因為Flutter的目標是讓每年釋出的四個版本中的每一個版本都能為框架的可用性提升一個臺階。
Flutter是一個年輕的跨平臺移動應用程式開發框架，所以它沒有像React Native受到眾多的大公司青睞也是不足為奇的。然而，這並不意味著它不好，截至2019年12月，它也為阿里巴巴、谷歌廣告、Groupon等眾多公司和業務所採用。
NativeScript
如果你要開始開發你的產品，“React Native”和“Flutter”絕不是唯一的解決方案。在 2020 年初，適合您的企業的替代框架也可能是 NativeScript。
這個開源框架於2015年3月公開發布，並迅速成為廣受歡迎的解決方案。例如，在釋出後的短短兩個月內，它就獲得了3000顆GitHub星標，並在Twitter上吸引了1500多名粉絲的關注。到今天為止，市場上已有超過700個外掛可供選擇。
在使用NativeScript構建跨平臺應用程式時，開發人員首先用JavaScript及其超集TypeScript編寫程式碼。然後，將程式碼庫編譯成各自平臺原生的程式語言。
另外值得一提的是，使用 NativeScript 的開發人員也可以使用第三方庫（CocoaPods 和 Android SDK），而無需包裝。
與React Native類似，NativeScript允許訪問Android和iOS原生API，這對跨平臺應用程式有明顯的積極影響。然而，不同之處在於，前者需要構建橋接API，而後者（用Progress首席開發者倡導者TJ VanToll的話說是“將所有iOS和Android API注入JavaScript虛擬機器”）。與Facebook框架的另一個相似之處在於程式碼重用，在這兩種情況下都可以達到90%。
Xamarin
Xamarin開源框架創建於2011年，這使它成為了這個列表中最“古老“的框架，但直到五年前它被微軟收購時，它才獲得了發展勢頭。截至今天，它號稱擁有超過6萬名貢獻者的社群。
從技術上講，要用Xamarin構建跨平臺的移動應用，需要很好地掌握.NET和C#兩種技術，前者是使用多種語言(包括C#程式語言)、編輯器和庫的開發平臺。Xamarin用一組工具補充了上述平臺，這些工具有助於構建跨平臺應用程式，例如庫、編輯器擴充套件和XAML。第二種技術是C#，這是一種面向物件的程式語言，它被認為比JavaScript學習起來稍難。Xamarin利用這種程式語言編寫整個應用程式，從後端到原生API，再到業務邏輯。
Xamarin.Native和Xamarin.Forms
Xamarin與其他框架的不同之處在於，它提供了兩種編譯跨平臺移動應用的方式：Xamarin Native(也稱為Xamarin.Android/iOS)和Xamarin.Forms。前一種方法優先考慮共享業務邏輯，並通過使用本機介面控制元件實現近乎本機的效能。
後者側重於共享程式碼，而不是業務原理，這一方面會導致程式碼重用比例增加(使用Xamarin，開發人員可以重用高達96%的C#程式碼)，但另一方面這樣會降低程式碼效能。
您可能已經注意到，跨平臺移動應用程式的效能和GUI密切相關，所以如果我說Xamarin構建應用程式的兩種方法對介面的最終外觀有很大影響，我可能不會感到驚訝。
Xamarin.Android/iOS允許開發人員使用原生控制元件和佈局，而Xamarin.Forms基於標準UI元素，允許從單個API設計應用程式，但如果你需要更完美的原生UI，則可能還不夠。
2020年跨平臺應用程式開發還值得考慮嗎？
不論如何，跨平臺確實是一個值得考慮和極具前景的方向，特別是我們上面提到的 “React Native”和“Flutter”。
前者是一個成熟而穩定的框架，利用了最流行的程式語言之一，並擁有成熟的大型開發人員社群。後者是一個快速發展的技術，儘管它比React Native年輕的多，它也已經贏得了世界各地許多開發人員的青睞。
但無論您選擇的是“React Native”、“Flutter”還是任何其他框架，跨平臺方法都一定會為您節省時間和金錢，同時能為你最大限度地擴大市場覆蓋範圍。
最後，值不值得考慮，最終還是取決於你的業務目標、預算和時限。