從事程式設計那些年經歷的跨平臺開發工具框架演變歷史

AWeiLoveAndroid發表於2019-12-19

前言:不知道是幸運還是不幸,從職業生涯早期開始就常常在做各種跨平臺開發,從早期的Cordova到現在的ReactNative,從SmartTV到Android、iOS、MacOS以及Windows(還有死去的Windows Phone,我可愛的Lumia 720只能變成老年機了),雖然不敢說全部都融會貫通,但多少也累積了一些心得與想法。趁著記憶力退化忘光光之前,寫篇文章來記錄近年來跨平臺開發的發展史,順便總結一下心得,有些可能年代久遠記憶有誤或用法有更新,還請各位不吝指正。

先送上一首鄧麗君的老歌《往事只能回味》獻給大家。

從事程式設計那些年經歷的跨平臺開發工具框架演變歷史,你想要的都在這裡。Cordova,Xamarin,Titanium,NativeScript,React Native,Electron,uni-app,Flutter

我做了一個詳細的來龍去脈的分析以及優缺點對比,花了一個通宵整理的,喜歡的話,點個贊支援一下吧,感謝大家關注。

更多幹貨歡迎關注公眾號【Flutter那些事】,精彩多多,別錯過哦。


Cordova & Ionic(底層使用Angular)

說到跨平臺,一般人好像都會先想到這隻小機器人.

從事程式設計那些年經歷的跨平臺開發工具框架演變歷史

Cordova是很早期的跨平臺解決方案,它是從更早期的PhoneGap分支出來的。在我剛開始接觸跨平臺開發的那個年代(大概2012年),它是最熱門的跨平臺解決方案。為什麼呢?因為它簡單好上手,而且那時候它的對手是Xamarin跟Titanium,兩者都是要付費的(這兩個後面會作介紹)。

下面看看Cordova的架構圖:

從事程式設計那些年經歷的跨平臺開發工具框架演變歷史

Cordova的架構很簡單,就是一個簡單的Activity(為了避免麻煩,底下的架構都用Android的觀點來解釋,絕對不是我iOS不熟喔,只是內容有限,就做一部分解讀了),上面搭載一個CordovaWebView Component,他是一個改造過的WebView,加裝了一些Cordova API,讓你藉此和Native的部分互動。你的App基本上就是一個Mobile Web,只是多了一些跟Native互動的能力。

優點: 1.好上手:前端工程師(或Web工程師,那個年代還不是大家都聽過前端這個詞)只要知道怎麼做Mobile Web(只要會Web,然後剛好遇到了Cordova,剛好一拍即合),就可以無痛的構建出一個跨平臺的App,Ionic入門很容易,用Web寫App簡直就是無腦操作,快得很,寫程式碼就是一把梭!聽起來是不是很吸引人呢?

從事程式設計那些年經歷的跨平臺開發工具框架演變歷史

2.Cordova的跨平臺解決方案,尤其是ionic,已經看起來和大部分原生app一樣了。

3.Cordova有豐富的外掛去銜接Native平臺(Android和iOS),你基本上很少去管Native的互動,社群也比較完善,還是很不錯的。

4.使用Ionic可以一套程式碼在安卓端、iOS端、網站端、小程式端通吃,做到了“write once, run everywhere”,開發和學習成本極低。

但是事情總是沒有想像中的美好。Cordova這種簡單明瞭的架構是個兩面刃,它也有它的缺點:

Cordova(Ionic)成也WebView,敗也WebView,使用Web效能體驗很差。雖然它開發起來很快,但是終究是個Web,也成不了Native,就好比你再怎麼打扮也成不了吳彥祖,胡歌一樣的道理。那個年代Mobile裝置的硬體條件非常有限,還只是1GB RAM的時代,Mobile Web的效能體驗和Native相比起來差距非常大。比如:Android上的Web UI跟Native UI比起來差異很大,比如iOS上的高延遲,掉幀,黑屏等。相同硬體條件下,iOS 上面就沒有那麼明顯的差距,原因歸結於Android和iOS兩個平臺的底層渲染機制架構不同所產生的差異。

後來的改進方案:

Web工程師們也意識到了這個問題的嚴重性,在js或是css部分可以做一些trick來做GPU加速來改善Android上的UI體驗。其中最好的當然就是Inoic了。PS:那個年代我買了第一臺小米手機,體驗一下什麼是:“為發燒而生”,那個年代小米那個配置確實很牛逼啊(純粹為了懷舊)。那個年代也是智慧手機快速發展的時候,當然隨著而來的就是各種Mobile Web框架了,比如:JQuery Mobile、Bootstrap等等,還有各大廠推出的開源框架和工具,當然還有一些叫不出名字的。Inoic雖然推出的晚一些,不過也算是“長江後浪推前浪”,也算是不錯的了。最新的ionic4控制元件做的相當完美,為了一些十分微小的UX細節不斷的改進。另外Ionic4好像有想要解決一些效能問題,推出了一個capacitor的工具,Ionic team是想做一個工具來優化web-based的跨平臺開發體驗。但是Cordova的效能部分(特別是渲染效能)基本上Ionic team這邊應該是不太能做什麼大的改進的,因為框架就是那樣設計的。或許在js或是css部分可以做一些trick來做加速(他們也確實花了很多工在這上面),但是整體的效能還是依賴於平臺上的WebView。之前有人提出把Cordova webview替換成Chromium,雖然會造成app體積臃腫,不過也在一定程度上提升了效能。當然功能是滿足不了需求的,也可以通過原生外掛來進行修補。

【Phonegap、Ionic、Angular和Cordova的區別和聯絡】:

很多人都搞不清楚的問題,在這裡我也幫大家解答一下:Phonegap、Ionic、Angular和Cordova的究竟有什麼區別和聯絡?

Phonegap原本由Nitobi公司開發的,現在由Adobe擁有,它是一個使用HTML、Javascript、CSS等Web API開發跨平臺的移動應用程式的框架。 2011年,Adobe/Nitobi把PhoneGap的原始碼貢獻給Apache軟體基金會(ASF)託管,後來社群將這份開源的程式碼取名位:“Cordova”。PhoneGap是Apache Cordova的一個分支。你可以這樣想,Apache Cordova是一臺發動機,執行在PhoneGap上,就像WebKit瀏覽器引擎執行在Chrome瀏覽器和Safari瀏覽器上。

Ionic 是一個全堆疊的混合應用開發框架, Ionic = Cordova + Angular + Ionic UI,Ionic主要功能是負責頁面的實現。

Angular 是一個JavaScript的前端框架。

Cordova提供了一組原生裝置相關的API,通過這些API可以使用JavaScript訪問原生的裝置功能,如攝像頭、麥克風等。同時Cordova負責將實現的頁面包裝成原生應用(Android是apk的形式;iOS是ipa的形式)。

簡單的打個比方吧:就像你吃柚子一樣,最內層的柚子瓤是Angular,柚子瓤外面的一層皮就是Ionic,而最外層的厚厚的柚子皮就是Cordova。

在那個年代Cordova風風火火了一陣子,但是在在架構及硬體環境下呈現出來的視覺表現,不太樂觀,遠遠比不上原生平臺的體驗,所以給人一種“跨平臺=效果差勁”的錯覺。後來其他的跨平臺推出時的時候,很多開發者都會說:“我之前使用Cordova,那個體驗太差了,我寧願原生的做,也不做跨平臺了”,所以說成了WebView,敗也WebView,樹大招風,Cordova招你惹你了,居然躺槍,看來火起來了在哪裡都被提起,躲都躲不過啊。

從事程式設計那些年經歷的跨平臺開發工具框架演變歷史


Xamarin

接下來登場的是C#家族的框架“Xamarin”了。

從事程式設計那些年經歷的跨平臺開發工具框架演變歷史

Xamarin跟Cordova差不多是同一個時期的產物,它在被微軟收購之前,就已經是小有名氣的跨平臺框架了,不過跟開源的Cordova不同,Xamarin當時是需要收費的,這也可能是它的名氣不如Cordova的原因吧。另一個Xamarin沒有紅起來的原因是:它使用C#當主導開發語言。

PS:我不是針對C#,不是說它不好,我也用過C#寫過程式,很像Java語言的。當年就是借鑑Java語言出道的(Java:你C#可以模仿我的臉,你不能模仿我的靈魂)。在.NET Core還沒出現之前,C#家族的產物都是相對的比較封閉的,開源的資源比較少,相比當時的慢慢火起來的Javascript來說,簡直是太少了,這就造成了Xmamrin先天上的劣勢。

Xamarin android端架構圖:

從事程式設計那些年經歷的跨平臺開發工具框架演變歷史

Xamarin iOS端架構圖:

從事程式設計那些年經歷的跨平臺開發工具框架演變歷史

從圖中可以看出Xamarin比Cordova複雜多了,有一組完整的Android & Java binding,還有一個跨平臺的.NET runtime — Mono。Xamarin大致上分成幾個部分:Xamarin.Android、Xamarin.iOS、Xamarin.Mac(後來才出現的)以及Xamarin.Forms。

感興趣的可以看看官網介紹:dotnet.microsoft.com/apps/xamari…

這裡我又要來順便科普一下,Xamarin和Cordova都出現過改名風波,肯定有人會問的Xamarin的幾個框架之間的關係:

【.NET Framework、.NET Core、Mono、Xamarin之間的區別和聯絡】:

.NET Framework:微軟2002年2月釋出第一個版本,只支援在Windows平臺上開發和執行(重點圈起來:閉源,商業化)。

Mono:Mono是一個開源框架,它是第三方公司Ximian釋出的,最早在2004年6月釋出了Mono 1.0版本,支援在Linux、Windows、Unix、Android等平臺。(野生版的.NET Framework開源實現)

.NET Core:微軟在2014年將.NET Core開源,2016年6月釋出其實現.NET Core 1.0。內容包括跨平臺虛擬機器CoreCLR、.NET Framework APIs的實現子集以及新增類庫等。(重點:開源,基於.NET Framework新增一些類庫)

Xamarin:Xamarin的前身是Mono,Mono專案幾經轉手,2011年落入Xamarin公司手中,2016年2月,微軟正式收購Xamarin。支援包括Windows、Linux、macOS、iOS、Android在內的各種主流平臺和作業系統。

為了更好地說明這個問題,借鑑網友的一張圖表示: 此圖片來源於博主:www.cnblogs.com/wer-ltm/p/8…

從事程式設計那些年經歷的跨平臺開發工具框架演變歷史

最後來看看優點:

1.使用C#編寫程式碼,可以重複利用多達96%的原始碼加快工程週期。同時Xamarin使維護和更新變得更加簡單。

2.效能接近原生。它的效能損耗比起Cordova少的多。Cordova必須承擔Web Rendering所帶來的巨大損耗,但Xamarin只有跨語言層面的損耗而已,相較起來相當輕微,這也是它在視覺渲染上帶來的優勢。比如:使用Xamarin.Forms工具構建,該工具可在應用程式執行時將應用程式UI元件轉換為平臺特定的介面元素。

3.豐富內建功能。Xamarin元件提供了數千個自定義UI控制元件,各種圖表,圖形,主題和其他強大的功能,可以僅新增到應用程式中點選次數很少。這包括內建支付處理(如Stripe),信標和可穿戴裝置整合,開箱即用推送通知服務,雲端儲存解決方案,多媒體串流功能等等

再來看看缺點:

1.與第三方庫和工具的相容性問題:以前是新的Native API必須等待官方的封裝才能使用,不過現在Xamarin也開源了,但是還是比較慢。另外,儘管Xamarin擁有自己的元件商店,但您可能需要在您的應用中需要特定的功能或整合,而這些平臺並未提供這些功能或整合,所以這一點就很蛋疼了。有些網友也給我反饋過:android和iOS的一些互動細節也會不太好。

2.對原生平臺的最新更新的支援不會很及時。這完全取決於Xamarin開發團隊,這些更改和/或引入新的外掛等需要一些時間,儘管Xamarin聲稱提供當天的支援,但仍然可能有些延誤。

2.Xamarin開源生態系統問題。Xamarin社群比iOS或Android的小得多。因此,找到一個有經驗的Xamarin開發人員可能是一個挑戰。

4.應用程式比較大。Xamarin應用程式通常比Native應用程式大,比如:Android的一個簡單的“hello,world”應用程式最多可能需要16 MB。

5.不適用於重圖形應用程式。在Xamarin中構建遊戲,豐富的自定義使用者介面或複雜的動畫變有很大的限制。

6.使用MvvmCross(www.mvvmcross.com/),需要做兩套介面,android效能有所提高,但佔用資源少,第三方的庫轉換麻煩。MvvmCross是專門為Xamarin和移動生態系統開發的框架。它支援Xamarin.iOS,Xamarin.Android,Xamarin.Mac,Xamarin.Forms,通用Windows平臺(UWP)和Windows Presentation Framework(WPF)。


Titanium

Titanium的logo就是下面這個:

從事程式設計那些年經歷的跨平臺開發工具框架演變歷史

對不起,我跟這個不熟,只記得當初也是要收費的,然後走的是JS to Native Binding的形式,可是聽說雷超級多,就沒有去踩了,如果有曾經用過的朋友們,可以來聊聊你的體驗。我以外的發現了github有開原始碼,難道現在開始開源了?github程式碼如下所示: github.com/appcelerato…

以下優缺點總結來源於部落格: devblog.axway.com/mobile-apps…

優點:

1.直接呼叫原生平臺特性和功能,無需其他的工具。Titanium的目的是為跨平臺的原生移動開發提供一種更高階的API,所以你可以直接訪問一系列廣泛的原生特性和功能,從使用者介面元件、插座介面到通知系統整合。Titanium的目的是,將Titanium應用程式和純原生應用程式之間在功能方面的差異縮小到幾乎為零。

2.整合和擴充套件很方便。由於Titanium可以用插入到與應用程式其餘部分一樣的檢視層次體系的可視元件來擴充套件,你最終能夠在底層原生平臺上實現任何可能的使用者介面。需要使用特殊的原生程式碼,讓表格檢視(TableView)以60fps的速度滾動?你能做到這一點。想無縫地整合遊戲的OpenGL繪製曲面,同時用JavaScript保留執行迴圈的邏輯?你能做到這一點。你可以把這些使用者介面擴充套件直接整合到用核心Titanium API編寫的應用程式中。

3.接近原生體驗。使用常用的使用者介面視窗元件時,Titanium應用程式的外觀和感覺也是這種平臺的一個優點。不用進行可視模擬(或通過應用CSS,或者使用OpenGL或Flash渲染使用者介面視窗元件)。當你建立NavigationGroup時,它得到iOS上的實際UINavigationController的支援。動畫和行為與原生應用程式使用者預期的相一致,因為你使用同樣的使用者介面控制元件。

4.入手門檻低。由於Titanium通過JavaScript提供了一種高階的原生程式設計API,為用過基於ECMAScript的語言的任何人大大降低了原生程式設計方面的准入門檻。

缺點:

1.Titanium API的範圍使得新增新平臺有難度。在一種新的原生平臺上實現Titanium API是項艱鉅任務。正由於如此,Titanium平臺只出現在目前被認為最重要的移動平臺上:iOS、Android和Web。

2.移動Web瀏覽器支援還沒有達到可以投放市場的質量。Titanium在繼續致力於改進我們的使用者介面視窗元件集的效能和感覺上,同時完善核心Titanium API的實現。

3.由於Titanium提供的抽象層很龐大Titanium的內部框架仍存在API實現未達到最佳標準的問題。在一些情況下,一些使用者介面元件還無法做到效能與原生使用者介面元件一樣好,比如佈局高度定製化的非常龐大的表格檢視。優化核心的使用者介面元件對Titanium團隊來說仍是首要的技術任務。

4.另外由於Titanium平臺的巨集偉目標,擴充套件Titanium並非易事。想有效地整合一種新的原生控制元件或API,深入瞭解Titanium的架構和環境必不可少。開發者體驗、API文件和麵向模組開發者的總體指南。


NativeScript(三個方向:js/ts或Angular或Vue)

網友對 NativeScript 的評價:

如果本身是走Angular陣營的話,NativeScript是一個相當值得嘗試的東西。

【待完成】


Election

Electron:PC跨平臺。

【待完成】


uni-app(底層使用Vue)

後來朋友推薦使用HBuilder工具(後來升級為HBuilderX),開發很方便,然後我就去HBuilder工具官網搜尋了一下,發現了一個叫做uni-app的框架,uni-app是一個使用Vue.js開發所有前端應用的框架,開發者編寫一套程式碼,可釋出到iOS,Android,H5,以及各種小程式(微信/支付寶/百度/頭條/ QQ /釘釘)等多個平臺,簡直就是Web極致跨埠的工具(算不上真正意義的跨平臺,但是比前面的Cordova感覺要厲害一些,畢竟多吃了紀幾年飯,研究出來的東西就是不一樣啊。。。O(∩_∩)O哈哈~)。可以說uni-app是懶人必備吧,它使用Vue.js編寫你的業務程式碼。

先來說說它的優點:

1.使用HBuilderX工具開發,一鍵建立專案模板,快捷方便,HBuilderX和uni-app都是同一家公司推出的,該公司還有其他一些框架,都可以使用HBuilderX建立你要的專案型別以及編寫你的程式碼。

2.uni-app對前端開發人員比較友好,封裝的元件和微信小程式的元件一毛一樣,熟悉小程式的朋友應該會覺得很不錯。

3.uni-app擴充能力強,封裝了H5+,支援nvue,也支援原生Android,ios開發。可以將原有的移動應用和H5應用改成uni-app應用。uni-app的App端,內建一個完整小程式引擎,並補充了可選的weex引擎給對效能要求更高的開發者。這也是uni-app在App端能夠正常執行微信小程式程式碼的原因。其他Web跨平臺框架做不到這點。

再說說它的缺點:

1.使用Vue開發,你必須要熟悉h5,vue,小程式,學習成本很高。如果不熟悉這些話,需要花時間學習新框架,比如小程式、Vue都要學習。

2.uni-app問世的時間還比較短,移動端平臺的相容性有很多地方還不是完善,坑很多,在Android平臺上表現較微信小程式和iOS上差,需要完善。

3.效能還是一個問題。畢竟uni-app底層使用的js,就算能夠編譯成原生程式,那個效能和相容性方面也是個問題,如果只是做Web還行,小程式什麼的還算出色。


React Native(底層使用React)

React Native:手機端跨平臺。

網友對 React Native 的評價:

React Native,要和原生相結合,沒辦法自己寫pugin,要依賴第三方的特性。不過作為一個跨平臺的過渡框架,可以說應有盡有了。雖然還不夠完美,但是高擴充套件性以及廣大的社群支撐,這也成了一個好框架很大的優勢所在。

【待完成】


Weex(底層使用Vue)

【待完成】


Flutter

網友對 Flutter 的評價:

Flutter是Google的親兒子,目前最火爆的跨平臺框架,也是跨平臺框架中最接近原生的一種框架,也是效率最高的。目前應用在移動端(安卓端,iOS端),Web也釋出了預覽版,但是還無法真正放在小程式或者Web專案中實戰。目前來看,Web上面還是無法真正的替代ionic框架。雖然脫離了JS強大的社群,但是這一年多以來Dart語言社群也在逐漸長大,pub.dev上面各種Flutter和Dart的開源庫和工具都有,開發專案起來還是不錯的,只是Flutter Web發展還不夠完善,很多Web的一些包一級瀏覽器的功能還不完善。

網友對 Flutter 的評價:

我是做前端的,我朋友是移動端的,他走的Flutter路線,他是做安卓開發的,用的java,他說Flutter接近原生體驗,非常好。而我們公司需要快速上線,還是走的是WebView的路線,我和他同時做一個小Demo出來對比了一下,發現App的效能體驗真的很大,排序如下:原生 >= Flutter > WebView。

【待完成】


最後來提幾個問題?

1.跨平臺最難的就是各平臺之間的差異性這個問題如何解決?

2.Cordova 和 RN, NativeScript 有什麼不同呢?

相關文章