原文出處:https://dzone.com/articles/cr...編程
多年來,跨平臺移動開發已經得到了最流行軟件開發趨勢之一的聲譽。這並不使人意外,由於採用跨平臺開發技術使得軟件工程師使用同一代碼就能爲不一樣平臺構建應用程序,從而節省時間、金錢以及沒必要要的工做。後端
截至2019年12月,全球活躍網民已超45億。他們每人平均上網時間爲6小時42分鐘,至關於每一年上網超過100天。
再加上人們愈來愈渴望從掌上設備中獲取海量的信息,也就爲之因此移動應用程序會如此受到歡迎提供了合理的解釋。截至 2019 年,全球移動應用收入達 4610 億美圓,預計到 2023 年,付費下載和應用內廣告的收入預計將超過 9350 億美圓。app
十年前,老闆們必須決定他們的產品將涵蓋哪些移動操做系統:Android、iOS、微軟、RIM或Symbian。而今天,初創公司的創始人正面臨着一個不一樣的兩難抉擇,因爲Android和iOS佔據了移動操做系統市場份額的98%,很顯然這兩個系統不容忽視,覆蓋什麼平臺再也不是問題。但問題是,構建一個在兩個平臺上均可以使用的應用程序應該採用什麼方法?框架
顧名思義,用於開發Android用的是Java或Kotlin,用於開發iOS則是Objective-C或SWIFT。做爲開發不一樣應用而使用不一樣的開發語言,對開發者而言並非一個好消息。
雖然特定的開發環境對特定的操做系統擁有對資源更高效的調配效率,可防止發生性能問題。但缺點也很顯而易見,你的開發人員須要使用不一樣的開發語言構建兩個獨立的應用程序,這須要付出更多的時間、金錢和精力。編程語言
其中一個能解決問題的例子是漸進式 Web 應用(PWA),它基本上是模仿原生應用程序行爲的一個網站(例如,在發送推送通知、脫機工做,或者只是添加到移動設備的主屏幕上)。然而,就像任何其餘選項同樣,PWA也不是天衣無縫的,由於它們消耗更多的電池,而且不能授予應用使用設備的全部功能。編輯器
但還好咱們還有一個跨平臺開發的選項,它容許用一段代碼同時爲兩個操做系統開發應用。它並不固定使用某一種平臺的編程語言編寫代碼。並且,因爲直接使用了系統原生控件來呈現界面,它能爲用戶提供近乎原平生臺應用的使用體驗。ide
下面,我會經過一系列維度來幫助你去評估你是否應該採用跨平臺開發這種形式來適配你的業務。工具
首先,也是最重要的,您須要決定您的應用程序是須要在一個仍是多個操做系統上可用。若是您的目標羣是由不一樣平臺的用戶組成的,那麼跨平臺開發將是首選的解決方案。佈局
另外一方面,若是你的用戶羣體只是Android或iOS的某一支,那麼用原生解決方案來開發是你的首選。性能
此標準涉及你但願與產品走多遠。解決此問題的一種方法是你的目標是使用MVP測試你的願景,或是你準備使用成熟的應用程序開始運行。您須要回答的另外一個問題是產品的功能(例如,訪問移動設備的硬件或特定於平臺的功能)。
你的用戶是否須要使用原生或近似原生的體驗。使用Material Design(Android)或Human Interface Guidance(iOS)來設計的移動應用程序是移動產品對用戶直觀且友好的緣由所在。在設計移動應用程序時應要考慮這些,可是,你可使用跨平臺框架來實現相似的效果。
有一點是確定的,原生開發成本不低、效率也不高。爲不一樣的平臺構建不一樣的應用程序須要僱傭更多的開發人員,這可能會致使初創公司在項目初期就超出緊張的項目預算。同時,若是採用跨平臺的方法,你能夠將項目外包給一個規模較小但一樣專業的團隊,這既是一個省時的解決方案,也是一個具備成本效益的解決方案。
假設你已經得出結論,你更傾向於跨平臺的移動應用程序開發,可是在下決心以前,你須要對此解決方案的優缺點進行完全的瞭解,不要緊,下面我逐一爲你列舉。
雖然咱們每一個人都有本身喜歡的移動操做系統,但我的喜愛不會妨礙你業務的成功。讓Android和iOS用戶同時可使用您的移動應用,能在將來提高更高的收錄打下基礎。
跨平臺開發容許您同時編寫包含多個操做系統的代碼(有時也會有處理平臺差別)。儘管如此,一套代碼確定會影響軟件開發過程當中的全部階段,由於它可能爲你節省一般花在修復和升級兩組獨立代碼上的成本。
儘管只須要一套代碼,但跨平臺應用程序開發仍然須要開發人員考慮處理系統差別的方法,例如發佈應用到平臺商店的過程。
這種方法將縮短從設計到發佈的時間。換句話講,這能夠爲你節省很大一筆初始項目預算。
毫無疑問,Android和iOS在用戶體驗和用戶界面方面都有很大的不一樣,這些差別中的大多數部分都能經過跨平臺開發框架幫你默認處理,這使得設計和實際表現不一致的狀況發生的可能性進一步下降。
儘管有上述各類優勢,但它也毫不是一點缺點沒有,它的主要缺點包括性能可能較低及略差的用戶體驗和用戶界面等。
雖然跨平臺的移動APP開發有利有弊。但從業務初創的角度來看,優勢應該是大於缺點的。並且,隨着對跨平臺移動應用需求的不斷增加,如今可用的工具和框架數量也已經很可觀了。
但選擇過多會使人頭疼,這就是爲何咱們只關注最突出的跨平臺移動開發框架的緣由:React Native, Flutter, NativeScript, 和Xamarin。
爲了讓你更深刻地瞭解是什麼使這些工具成爲2020年軟件開發的可選選項,咱們將根據如下標準對它們進行打分:社區支持、基於的編程語言、代碼可重用性、性能、界面以及使用它們構建的重要應用程序。
Reaction Native是Facebook於2015年發佈的開源、跨平臺的應用開發框架。做爲2013年舉辦的一場內部黑客馬拉松的產物,它已經成爲最受歡迎的原生App開發替代方案之一,擁有2043名GitHub貢獻者,得到了超過82900 GitHub標星。不斷增加的社區認知度使得找到一支可靠且經驗豐富的開發團隊來承接你的項目變得相對容易。
基於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適應不斷變化的需求其中一個很小的樣本。
2020年值得考慮的第二個框架是Flutter。它在Google I/O 2017上宣佈,並於2018年發佈,對於跨平臺的世界來講,它如今仍然是一個「新人」。但儘管如此,它已經得到了超過80500 GitHub星標和絕大多數工程師將其稱爲2019年Stack Overflow調查中最受歡迎的三個框架之一,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中包括的改進:
這不是一個完整的清單,由於Flutter的目標是讓每一年發佈的四個版本中的每個版本都能爲框架的可用性提高一個臺階。
Flutter是一個年輕的跨平臺移動應用程序開發框架,因此它沒有像React Native受到衆多的大公司青睞也是不足爲奇的。然而,這並不意味着它很差,截至2019年12月,它也爲阿里巴巴、谷歌廣告、Groupon等衆多公司和業務所採用。
若是你要開始開發你的產品,「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開源框架建立於2011年,這使它成爲了這個列表中最「古老「的框架,但直到五年前它被微軟收購時,它纔得到了發展勢頭。截至今天,它號稱擁有超過6萬名貢獻者的社區。
從技術上講,要用Xamarin構建跨平臺的移動應用,須要很好地掌握.NET和C#兩種技術,前者是使用多種語言(包括C#編程語言)、編輯器和庫的開發平臺。Xamarin用一組工具補充了上述平臺,這些工具備助於構建跨平臺應用程序,例如庫、編輯器擴展和XAML。第二種技術是C#,這是一種面向對象的編程語言,它被認爲比JavaScript學習起來稍難。Xamarin利用這種編程語言編寫整個應用程序,從後端到原生API,再到業務邏輯。
Xamarin與其餘框架的不一樣之處在於,它提供了兩種編譯跨平臺移動應用的方式:Xamarin Native(也稱爲Xamarin.Android/iOS)和Xamarin.Forms。前一種方法優先考慮共享業務邏輯,並經過使用本機接口控件實現近乎本機的性能。
後者側重於共享代碼,而不是業務原理,這一方面會致使代碼重用比例增長(使用Xamarin,開發人員能夠重用高達96%的C#代碼),但另外一方面這樣會下降代碼性能。
您可能已經注意到,跨平臺移動應用程序的性能和GUI密切相關,因此若是我說Xamarin構建應用程序的兩種方法對界面的最終外觀有很大影響,我可能不會感到驚訝。
Xamarin.Android/iOS容許開發人員使用原生控件和佈局,而Xamarin.Forms基於標準UI元素,容許從單個API設計應用程序,但若是你須要更完美的原生UI,則可能還不夠。
不論如何,跨平臺確實是一個值得考慮和極具前景的方向,特別是咱們上面提到的 「React Native」和「Flutter」。
前者是一個成熟而穩定的框架,利用了最流行的編程語言之一,並擁有成熟的大型開發人員社區。後者是一個快速發展的技術,儘管它比React Native年輕的多,它也已經贏得了世界各地許多開發人員的青睞。
但不管您選擇的是「React Native」、「Flutter」仍是任何其餘框架,跨平臺方法都必定會爲您節省時間和金錢,同時能爲你最大限度地擴大市場覆蓋範圍。
最後,值不值得考慮,最終仍是取決於你的業務目標、預算和時限。