多年來，跨平臺移動開發(fā)已經(jīng)獲得了最流行軟件開發(fā)趨勢之一的聲譽。這并不令人意外，因為采用跨平臺開發(fā)技術(shù)使得軟件工程師使用同一代碼就能為不同平臺構(gòu)建應(yīng)用程序，從而節(jié)省時間、金錢以及不必要的工作。

移動市場的現(xiàn)狀

截至2019年12月，全球活躍網(wǎng)民已超45億。他們每人平均上網(wǎng)時間為6小時42分鐘，相當(dāng)于每年上網(wǎng)超過100天。

再加上人們越來越渴望從掌上設(shè)備中獲取海量的信息，也就為之所以移動應(yīng)用程序會如此受到歡迎提供了合理的解釋。截至 2019 年，全球移動應(yīng)用收入達(dá) 4610 億美元，預(yù)計到 2023 年，付費下載和應(yīng)用內(nèi)廣告的收入預(yù)計將超過 9350 億美元。

移動開發(fā)的技術(shù)選型

十年前，老板們必須決定他們的產(chǎn)品將涵蓋哪些移動操作系統(tǒng)：Android、iOS、微軟、RIM或Symbian。而今天，初創(chuàng)公司的創(chuàng)始人正面臨著一個不同的兩難抉擇，由于Android和iOS占據(jù)了移動操作系統(tǒng)市場份額的98%，很顯然這兩個系統(tǒng)不容忽視，覆蓋什么平臺不再是問題。但問題是，構(gòu)建一個在兩個平臺上都可以使用的應(yīng)用程序應(yīng)該采用什么方法?

每個操作系統(tǒng)對應(yīng)一種開發(fā)環(huán)境

顧名思義，用于開發(fā)Android用的是Java或Kotlin，用于開發(fā)iOS則是Objective-C或SWIFT。作為開發(fā)不同應(yīng)用而使用不同的開發(fā)語言，對開發(fā)者而言并不是一個好消息。

雖然特定的開發(fā)環(huán)境對特定的操作系統(tǒng)擁有對資源更高效的調(diào)配效率，可防止發(fā)生性能問題。但缺點也很顯而易見，你的開發(fā)人員需要使用不同的開發(fā)語言構(gòu)建兩個獨立的應(yīng)用程序，這需要付出更多的時間、金錢和精力。

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

其中一個能解決問題的例子是漸進(jìn)式 Web 應(yīng)用(PWA)，它基本上是模仿原生應(yīng)用程序行為的一個網(wǎng)站(例如，在發(fā)送推送通知、脫機工作，或者只是添加到移動設(shè)備的主屏幕上)。然而，就像任何其他選項一樣，PWA也不是完美無缺的，因為它們消耗更多的電池，并且不能授予應(yīng)用使用設(shè)備的所有功能。

跨平臺應(yīng)用程序開發(fā)

但還好我們還有一個跨平臺開發(fā)的選項，它允許用一段代碼同時為兩個操作系統(tǒng)開發(fā)應(yīng)用。它并不固定使用某一種平臺的編程語言編寫代碼。而且，由于直接使用了系統(tǒng)原生控件來呈現(xiàn)界面，它能為用戶提供近乎原生平臺應(yīng)用的使用體驗。

我要不要使用跨平臺開發(fā)這項技術(shù)?

下面，我會通過一系列維度來幫助你去評估你是否應(yīng)該采用跨平臺開發(fā)這種形式來適配你的業(yè)務(wù)。

平臺

首先，也是最重要的，您需要決定您的應(yīng)用程序是需要在一個還是多個操作系統(tǒng)上可用。如果您的目標(biāo)群是由不同平臺的用戶組成的，那么跨平臺開發(fā)將是首選的解決方案。

另一方面，如果你的用戶群體只是Android或iOS的某一支，那么用原生解決方案來開發(fā)是你的首選。

復(fù)雜性

此標(biāo)準(zhǔn)涉及你希望與產(chǎn)品走多遠(yuǎn)。解決此問題的一種方法是你的目標(biāo)是使用MVP測試你的愿景，或是你準(zhǔn)備使用成熟的應(yīng)用程序開始運行。您需要回答的另一個問題是產(chǎn)品的功能(例如，訪問移動設(shè)備的硬件或特定于平臺的功能)。

原生體驗

你的用戶是否需要使用原生或近似原生的體驗。使用Material Design(Android)或Human Interface Guidance(iOS)來設(shè)計的移動應(yīng)用程序是移動產(chǎn)品對用戶直觀且友好的原因所在。在設(shè)計移動應(yīng)用程序時應(yīng)要考慮這些，但是，你可以使用跨平臺框架來實現(xiàn)類似的效果。

時間和成本

有一點是肯定的，原生開發(fā)成本不低、效率也不高。為不同的平臺構(gòu)建不同的應(yīng)用程序需要雇傭更多的開發(fā)人員，這可能會導(dǎo)致初創(chuàng)公司在項目初期就超出緊張的項目預(yù)算。同時，如果采用跨平臺的方法，你可以將項目外包給一個規(guī)模較小但同樣專業(yè)的團隊，這既是一個省時的解決方案，也是一個具有成本效益的解決方案。

跨平臺移動應(yīng)用開發(fā)的優(yōu)點(和缺點)

假設(shè)你已經(jīng)得出結(jié)論，你更傾向于跨平臺的移動應(yīng)用程序開發(fā)，但是在下決心之前，你需要對此解決方案的優(yōu)缺點進(jìn)行徹底的了解，沒關(guān)系，下面我逐一為你列舉。

跨平臺移動應(yīng)用程序開發(fā)的好處

更廣泛的市場覆蓋范圍

雖然我們每個人都有自己喜歡的移動操作系統(tǒng)，但個人喜好不會妨礙你業(yè)務(wù)的成功。讓Android和iOS用戶同時可以使用您的移動應(yīng)用，能在未來提升更高的收錄打下基礎(chǔ)。

一套代碼

跨平臺開發(fā)允許您同時編寫包含多個操作系統(tǒng)的代碼(有時也會有處理平臺差異)。盡管如此，一套代碼肯定會影響軟件開發(fā)過程中的所有階段，因為它可能為你節(jié)省通常花在修復(fù)和升級兩組獨立代碼上的成本。

更高效的發(fā)布流程

盡管只需要一套代碼，但跨平臺應(yīng)用程序開發(fā)仍然需要開發(fā)人員考慮處理系統(tǒng)差異的方法，例如發(fā)布應(yīng)用到平臺商店的過程。

這種方法將縮短從設(shè)計到發(fā)布的時間。換句話講，這可以為你節(jié)省很大一筆初始項目預(yù)算。

平臺一致性

毫無疑問，Android和iOS在用戶體驗和用戶界面方面都有很大的不同，這些差異中的大多數(shù)部分都能通過跨平臺開發(fā)框架幫你默認(rèn)處理，這使得設(shè)計和實際表現(xiàn)不一致的情況發(fā)生的可能性進(jìn)一步降低。

有什么缺點?

盡管有上述各種優(yōu)點，但它也絕不是一點缺點沒有，它的主要缺點包括性能可能較低及略差的用戶體驗和用戶界面等。

2020年還有哪些跨平臺移動開發(fā)框架值得考慮

雖然跨平臺的移動APP開發(fā)有利有弊。但從業(yè)務(wù)初創(chuàng)的角度來看，優(yōu)點應(yīng)該是大于缺點的。而且，隨著對跨平臺移動應(yīng)用需求的不斷增長，現(xiàn)在可用的工具和框架數(shù)量也已經(jīng)很可觀了。

但選擇過多會令人頭疼，這就是為什么我們只關(guān)注最突出的跨平臺移動開發(fā)框架的原因：React Native, Flutter, NativeScript, 和Xamarin。

為了讓你更深入地了解是什么使這些工具成為2020年軟件開發(fā)的可選選項，我們將根據(jù)以下標(biāo)準(zhǔn)對它們進(jìn)行打分：社區(qū)支持、基于的編程語言、代碼可重用性、性能、界面以及使用它們構(gòu)建的重要應(yīng)用程序。

React Native

Reaction Native是Facebook于2015年發(fā)布的開源、跨平臺的應(yīng)用開發(fā)框架。作為2013年舉辦的一場內(nèi)部黑客馬拉松的產(chǎn)物，它已經(jīng)成為最受歡迎的原生App開發(fā)替代方案之一，擁有2043名GitHub貢獻(xiàn)者，獲得了超過82900 GitHub標(biāo)星。不斷增長的社區(qū)認(rèn)知度使得找到一支可靠且經(jīng)驗豐富的開發(fā)團隊來承接你的項目變得相對容易。

Learn Once and Write Anywhere

基于React.JS，React Native利用JavaScript(根據(jù)2019年Stack Overflow的調(diào)查，JavaScript成為了最受歡迎的編程語言)，為Android和iOS用戶提供真正原生的應(yīng)用外觀和體驗。另外，使該框架脫穎而出的是，如果你需要，React Native允許你使用Java、Objective-C或SWIFT編寫部分原生模塊來順利處理復(fù)雜的操作，如視頻播放或圖像編輯。

雖然這些組件不能在不同的平臺之間共享，并且需要開發(fā)人員做更多的工作，但多達(dá)90%的React Native代碼是可以重用的。很好地表明該框架的座右銘不是“Write Once, Use Anywhere”，而是“learn once, write anywhere”。

就GUI而言，React Native可以提供接近原生的用戶體驗，這要歸功于它使用了Android和iOS的本地控制器。它還使用帶有UI元素的ReactJS庫，這有助于加快UI設(shè)計過程。在開發(fā)移動應(yīng)用程序時，使此框架值得考慮的另一個原因是，它可用在不丟失應(yīng)用程序狀態(tài)的情況下對UI進(jìn)行更改。

另一個使React Native成為2020年跨平臺移動開發(fā)框架的首選之一，是因為持續(xù)的更新，例如近期的版本 0.60 和 0.61 ：

• 多項輔助功能改進(jìn)。
• 更清晰、更人性化的開始屏幕。
• 快速刷新，融合了實時和熱重新加載，從而顯著加快了開發(fā)進(jìn)程。

如上的Release Note只是React Native適應(yīng)不斷變化的需求其中一個很小的樣本。

Flutter

2020年值得考慮的第二個框架是Flutter。它在Google I/O 2017上宣布，并于2018年發(fā)布，對于跨平臺的世界來說，它現(xiàn)在仍然是一個“新人”。但盡管如此，它已經(jīng)獲得了超過80500 GitHub星標(biāo)和絕大多數(shù)工程師將其稱為2019年Stack Overflow調(diào)查中最受歡迎的三個框架之一，F(xiàn)lutter無疑是一股不可忽視的力量。

Dart是如何使Flutter變得獨一無二的

Flutter 背后的編程語言是 Dart，谷歌稱之為"客戶端優(yōu)化"，適合在任何平臺上"快速構(gòu)建應(yīng)用程序"。它于 2011 年推出，是一種響應(yīng)式面向?qū)ο蟮恼Z言，被開發(fā)者認(rèn)為相對容易學(xué)習(xí)，其中原因有二：第一，語法上它借鑒了C/C++ 和 Java; 第二，在官方網(wǎng)站上，您可以找到內(nèi)容廣泛且相當(dāng)簡單的文檔。值得一提的是，Dart 附帶了大量Flutter 兼容軟件包的軟件包，允許您使應(yīng)用程序更加復(fù)雜。

Flutter的一個主要優(yōu)勢是，它的性能比本文提到的任何其他跨平臺移動開發(fā)框架都要好。這歸功于Dart的編譯器和Flutter擁有自己的一套小部件。結(jié)果是它能更快、更直接地與平臺直接通信，而不需要JavaScript橋(例如，Reaction Native就是這種情況)。說到小部件：通過Flutter的“UI-as-a-code”方法，它們只用DART編寫，這就提高了代碼的可重用性。

效率與用戶體驗和界面密不可分。如前所述，F(xiàn)lutter不依賴于一組原生組件，而是利用可視化、結(jié)構(gòu)化、平臺性和交互式小部件進(jìn)行UI的設(shè)計，所有這些都由框架的圖形引擎呈現(xiàn)。更重要的是，F(xiàn)lutter留下了很大的定制空間，如果你想要設(shè)計一個很完美的UI，它是個很好的選擇。

說到Flutter的更新，最新的穩(wěn)定版本是在12月12日發(fā)布的，根據(jù)官方發(fā)布說明，它合并了來自188個貢獻(xiàn)者的近2000個pull。例如，版本1.12.13中包括的改進(jìn)：

• 重大的API變動。
• 新功能，例如SliverOpacity小部件和SliverAnimatedList。
• 修復(fù)了崩潰和性能問題。
• Beta版中的Web支持。

這不是一個完整的清單，因為Flutter的目標(biāo)是讓每年發(fā)布的四個版本中的每一個版本都能為框架的可用性提升一個臺階。

Flutter是一個年輕的跨平臺移動應(yīng)用程序開發(fā)框架，所以它沒有像React Native受到眾多的大公司青睞也是不足為奇的。然而，這并不意味著它不好，截至2019年12月，它也為阿里巴巴、谷歌廣告、Groupon等眾多公司和業(yè)務(wù)所采用。

NativeScript

[[320835]]

如果你要開始開發(fā)你的產(chǎn)品，“React Native”和“Flutter”絕不是唯一的解決方案。在 2020 年初，適合您的企業(yè)的替代框架也可能是 NativeScript。

這個開源框架于2015年3月公開發(fā)布，并迅速成為廣受歡迎的解決方案。例如，在發(fā)布后的短短兩個月內(nèi)，它就獲得了3000顆GitHub星標(biāo)，并在Twitter上吸引了1500多名粉絲的關(guān)注。到今天為止，市場上已有超過700個插件可供選擇。

在使用NativeScript構(gòu)建跨平臺應(yīng)用程序時，開發(fā)人員首先用JavaScript及其超集TypeScript編寫代碼。然后，將代碼庫編譯成各自平臺原生的編程語言。

另外值得一提的是，使用 NativeScript 的開發(fā)人員也可以使用第三方庫(CocoaPods 和 Android SDK)，而無需包裝。

與React Native類似，NativeScript允許訪問Android和iOS原生API，這對跨平臺應(yīng)用程序有明顯的積極影響。然而，不同之處在于，前者需要構(gòu)建橋接API，而后者(用Progress首席開發(fā)者倡導(dǎo)者TJ VanToll的話說是“將所有iOS和Android API注入JavaScript虛擬機”)。與Facebook框架的另一個相似之處在于代碼重用，在這兩種情況下都可以達(dá)到90%。

Xamarin

Xamarin開源框架創(chuàng)建于2011年，這使它成為了這個列表中最“古老“的框架，但直到五年前它被微軟收購時，它才獲得了發(fā)展勢頭。截至今天，它號稱擁有超過6萬名貢獻(xiàn)者的社區(qū)。

從技術(shù)上講，要用Xamarin構(gòu)建跨平臺的移動應(yīng)用，需要很好地掌握.NET和C#兩種技術(shù)，前者是使用多種語言(包括C#編程語言)、編輯器和庫的開發(fā)平臺。Xamarin用一組工具補充了上述平臺，這些工具有助于構(gòu)建跨平臺應(yīng)用程序，例如庫、編輯器擴展和XAML。第二種技術(shù)是C#，這是一種面向?qū)ο蟮木幊陶Z言，它被認(rèn)為比JavaScript學(xué)習(xí)起來稍難。Xamarin利用這種編程語言編寫整個應(yīng)用程序，從后端到原生API，再到業(yè)務(wù)邏輯。

Xamarin.Native和Xamarin.Forms

Xamarin與其他框架的不同之處在于，它提供了兩種編譯跨平臺移動應(yīng)用的方式：Xamarin Native(也稱為Xamarin.Android/iOS)和Xamarin.Forms。前一種方法優(yōu)先考慮共享業(yè)務(wù)邏輯，并通過使用本機接口控件實現(xiàn)近乎本機的性能。

后者側(cè)重于共享代碼，而不是業(yè)務(wù)原理，這一方面會導(dǎo)致代碼重用比例增加(使用Xamarin，開發(fā)人員可以重用高達(dá)96%的C#代碼)，但另一方面這樣會降低代碼性能。

您可能已經(jīng)注意到，跨平臺移動應(yīng)用程序的性能和GUI密切相關(guān)，所以如果我說Xamarin構(gòu)建應(yīng)用程序的兩種方法對界面的最終外觀有很大影響，我可能不會感到驚訝。

Xamarin.Android/iOS允許開發(fā)人員使用原生控件和布局，而Xamarin.Forms基于標(biāo)準(zhǔn)UI元素，允許從單個API設(shè)計應(yīng)用程序，但如果你需要更完美的原生UI，則可能還不夠。

2020年跨平臺應(yīng)用程序開發(fā)還值得考慮嗎?

不論如何，跨平臺確實是一個值得考慮和極具前景的方向，特別是我們上面提到的 “React Native”和“Flutter”。

前者是一個成熟而穩(wěn)定的框架，利用了最流行的編程語言之一，并擁有成熟的大型開發(fā)人員社區(qū)。后者是一個快速發(fā)展的技術(shù)，盡管它比React Native年輕的多，它也已經(jīng)贏得了世界各地許多開發(fā)人員的青睞。

但無論您選擇的是“React Native”、“Flutter”還是任何其他框架，跨平臺方法都一定會為您節(jié)省時間和金錢，同時能為你最大限度地擴大市場覆蓋范圍。

最后，值不值得考慮，最終還是取決于你的業(yè)務(wù)目標(biāo)、預(yù)算和時限。