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

移動(dòng)市場(chǎng)的現(xiàn)狀

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

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

移動(dòng)開(kāi)發(fā)的技術(shù)選型

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

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

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

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

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

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

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

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

我要不要使用跨平臺(tái)開(kāi)發(fā)這項(xiàng)技術(shù)?

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

平臺(tái)

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

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

復(fù)雜性

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

原生體驗(yàn)

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

時(shí)間和成本

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

跨平臺(tái)移動(dòng)應(yīng)用開(kāi)發(fā)的優(yōu)點(diǎn)(和缺點(diǎn))

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

跨平臺(tái)移動(dòng)應(yīng)用程序開(kāi)發(fā)的好處

更廣泛的市場(chǎng)覆蓋范圍

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

一套代碼

跨平臺(tái)開(kāi)發(fā)允許您同時(shí)編寫包含多個(gè)操作系統(tǒng)的代碼(有時(shí)也會(huì)有處理平臺(tái)差異)。盡管如此，一套代碼肯定會(huì)影響軟件開(kāi)發(fā)過(guò)程中的所有階段，因?yàn)樗赡転槟愎?jié)省通常花在修復(fù)和升級(jí)兩組獨(dú)立代碼上的成本。

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

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

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

平臺(tái)一致性

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

有什么缺點(diǎn)?

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

2020年還有哪些跨平臺(tái)移動(dòng)開(kāi)發(fā)框架值得考慮

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

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

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

React Native

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

Learn Once and Write Anywhere

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

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

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

另一個(gè)使React Native成為2020年跨平臺(tái)移動(dòng)開(kāi)發(fā)框架的首選之一，是因?yàn)槌掷m(xù)的更新，例如近期的版本 0.60 和 0.61 ：

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

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

Flutter

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

Dart是如何使Flutter變得獨(dú)一無(wú)二的

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

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

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

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

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

這不是一個(gè)完整的清單，因?yàn)镕lutter的目標(biāo)是讓每年發(fā)布的四個(gè)版本中的每一個(gè)版本都能為框架的可用性提升一個(gè)臺(tái)階。

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

NativeScript

[[320835]]

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

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

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

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

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

Xamarin

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

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

Xamarin.Native和Xamarin.Forms

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

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

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

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

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

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

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

但無(wú)論您選擇的是“React Native”、“Flutter”還是任何其他框架，跨平臺(tái)方法都一定會(huì)為您節(jié)省時(shí)間和金錢，同時(shí)能為你最大限度地?cái)U(kuò)大市場(chǎng)覆蓋范圍。

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