Xamarin介紹

  鄭重聲明:程序員

  本文非Xamarin使用詳解,也沒什麼有用的乾貨,只是給不知道Xamarin究竟是什麼的你們提供一點點微不足道的小介紹,看完之後啥收穫都沒有也不是沒可能的(*/ω\*)。so......ε=ε=ε=ε=ε=┌(つ•̀ω•́)つ(飛速逃離現場中......)app

  正文:工具

  前段時間去參加了一個微軟的Xamarin培訓,恰好最近準備要在公司給你們作分享,這裏先把我準備的內容寫出來分享一下好了。post

  開始以前,和你們分享一句來自Xamarin官網首頁的一句話:測試

  圖片上的中文是我本身翻譯的,意思可能不是特別到位,可是從英文原文來看仍是可以感覺到Xamarin本身對於它所提供的跨平臺移動開發解決方案仍是十分自信的。並且這句話也能給尚不瞭解Xamarin究竟是什麼的人一個很直觀的介紹——咱們(Xamarin)是一個能夠幫助你開發功能強大的移動應用的工具,而且你在移動開發過程當中所須要用到的東西咱們可都給你準備好了~spa

  下面就從Xamarin的基本狀況開始給你們作一個簡要介紹吧:翻譯

1、Xamarin簡介3d

  • 2011年5月16日成立,2016年2月24日被微軟正式收購。

  很是年輕的公司,成立不到五年的時間就被微軟這個巨頭給收購了。主要是Xamarin背後的商業價值確實很強大,而且它是用C#來進行跨平臺移動開發的。微軟親兒子無誤了~orm

  • 是Mono項目的一個分支。

  基於.NET的跨平臺實現的一個開源項目,Xamarin也正是由Mono項目中很是積極活躍的一批工程師所創立的。(不過我猜想多半是由於Mono做爲開源項目實在是不賺錢,以及雖然作的已經很大很紅火了,但維護什麼的仍是隻能靠開源社區的活躍分子們無償維護,長此以往天然是比不上能夠全身心投入效果來的好了。因此裏面最活躍的一批工程師乾脆把Mono裏移動開發這一塊專門拿出來作成了商業項目,果不其然,效果仍是很顯著的嘛。——P.S以上均爲我的臆測,不表明Mono項目參與者的真實想法!若是Xamarin創始人們順着網線摸過來了我是不會負責的!─=≡Σ(((つ•̀ω•́)つε=ε=ε=┌(;´゚ェ゚)┘)blog

  • 使得C#程序員開發原生的Android、iOS應用成爲可能。

  Windows應用就更不用說了,畢竟微軟的親兒子。

  • 一套代碼邏輯,三種平臺實現:Android、iOS、Windows。

  這點看上去和上面的感受上有點重複,其實仍是有差距的。上面那個只是說明了C#程序員不用去專門學Java或者Objective-C也能寫Android和iOS應用,可是這裏實際上是想說明若是你想同時開發一個三個平臺都能用的App,使用Xamarin的話就不須要Android寫一遍代碼,iOS寫一遍代碼而後到了Windows那邊再寫一遍代碼那麼麻煩了。不過這麼一解釋感受好像仍是有點多餘,跨平臺開發原本就是爲了解決重複寫代碼的問題嘛……

  • 強大的Xamarin Platform:Xamarin Studio,Xamarin.Forms,Xamarin for Visual Studio,Xamarin Test Cloud......

  這個就不用過多解釋了,Xamarin首頁那句霸氣的"Everything you need to deliver great mobile apps."依據就是從這來的,從開發、測試到發佈,Xamarin樣樣都有~

2、Xamarin UI開發簡介

  UI開發一直都是App開發中比較重要的一部分。既然Xamarin聲稱它能作到原生開發,那就簡單介紹一下它在UI開發方面的兩種途徑吧:

  1.Xamarin Native Approach

  說實話這種UI開發模式對於沒有接觸過Android或者iOS開發的C#程序員來講實在有點不友好,由於從名字上來講就能感覺到了:Native,N-a-t-i-v-e!說的這麼義正詞嚴也是讓人氣不打一處來哦?(P.S. 雖然不是Naive,但仍是有種被嘲諷了的感受。)就是說你想實現「原生」UI開發是嗎?那就老老實實寫人家原生的UI代碼吧!雖然很可氣,不過相對PhoneGap,Sencha之類的基於HTML5,JavaScript以及CSS的跨平臺開發方案來講,Xamarin好歹是提供了一種可使用Android和iOS原生UI控件的可能。有Android或者iOS開發基礎的人選擇這種方式來開發UI天然更駕輕就熟;沒有基礎可是有上進心而且很勤奮的孩紙們也能夠趁這個機會去學點Android和iOS的UI開發知識,反正多學一點東西總歸是有好處的嘛。

  至於那些既沒有移動開發基礎,又不勤奮的懶癌患者們,(沒錯,我就是這羣人當中的佼佼者!(๑‾ ꇴ ‾๑))只能說Xamarin大概是算到了咱們這羣人的存在,因此提供了下面的這種開發方式:

  2.Xamarin.Forms Approach

  這種方式對C#程序員就很友好啦,在寫界面的時候你們只須要調用Xamarin.Forms裏已經封裝好的UI組件就能夠了,編譯階段Xamarin會根據代碼自動生成相應的原生UI組件的。固然啦,Xamarin.Forms還作不到100%提供Android和iOS中全部的UI控件的,不過對於絕大多數應用場景都是夠用的了。若是實在沒有你們也能夠發揮本身的聰明才智稍加組合一下,畢竟不少hacks就是在這種貧窮的現實中創造出來的嘛。

  下面是一張Xamarin Native Approach和Xamarin.Forms的代碼共享程度對比:

  

 

  從上圖能夠明顯感覺到,若是使用Xamarin Native的方式來開發的話,共享代碼基本上就只剩後臺邏輯代碼了,剩餘大約1/4的代碼仍是個平臺相關的代碼。(看這麼有規律和數字這麼整的數據也能猜到對於這種數據的來源不能太苛刻~僅供直觀感覺一下二者之間的代碼量差距。)若是使用Xamarin.Forms開發的話,那幾乎沒有什麼平臺相關的代碼了。

  總而言之,從個性化角度來講,Xamarin Native的方式要好一些;從維護角度來講,Xamarin.Forms維護起來更爲輕鬆些。

3、Xamarin API簡介

  其實這部分要認真介紹起來仍是蠻費勁的,因此我就直接甩張圖給大家感覺一下好了(懶癌發做中……(*/ω\*)):

  這裏要說明的其實就是Xamarin能夠調用到Andriod和iOS中的全部API。實現所謂的100%原生API。這一點相較於PhoneGap之類的跨平臺移動開發方案來講確實要優秀不少,由於每次Android或者iOS發佈新功能的時候,就不用苦等通過封裝後才能調用的API了。而且開發出來的App使用體驗上接近原生開發的應用效率。

  舉顆栗子(栗子來源於培訓老師。),iOS和Android剛推出健康功能裏的記錄用戶每日行走步數功能時,使用PhoneGap等跨平臺開發技術所開發的應用是無法在第一時間就能調用到這個功能的API的,他們只能等PhoneGap根據Andriod和iOS所提供的原生API封裝好可被本身用戶調用的API後,用戶們才能調用到該功能的接口實現相應功能。因此對於調用非原生API開發的應用來講,其在功能更新方面會存在必定的滯後性。Xamarin傲嬌的表示他們能夠作到Andriod或iOS發佈新功能API的當天,Xamarin的開發者也能調用到這些API們!ヽ( ̄▽ ̄)و

  可以調用原生API的另外一好處是,對於一些特殊的功能,譬如iOS的3D Touch功能之類的,Xamarin也能保障其開發者能夠訪問到,而大多數基於H5+JS+CSS的跨平臺開發技術對於這些特殊功能的支持可能就沒有那麼到位了。(我的理解,這裏若是有說的不對的地方敬請指正!)

4、Xamarin底層技術簡介

  這一小節推薦你們去閱讀《Xamarin技術全解析》一文,介紹的很是詳細。做者一看就知道和我這種重度懶癌患者不同,由於我接下來又要甩圖了……

  等等,甩圖以前再說一下Xamarin三大底層技術吧:MonoBinding(綁定)以及P/Invoke(平臺調用)

  好,下面請你們欣賞一下Xamarin.Andriod實現原理圖:

  怎麼樣?這圖是否是看着不是很好懂?(已經看懂的就略過我接下來的內容吧,怕看完後反而不懂了(*/ω\*)......)其實上面推薦的那篇文章裏有很好的介紹,我就簡單複述(複製)一下吧。

  咱們用C#代碼寫的Andriod應用在運行的時候實際上是在Mono虛擬機中運行的,而Mono虛擬機又是寄宿在ART(也就是Andriod虛擬機Dalvik)中運行的,因此ART經過ACWs(Andriod Callable Wrappers)的方式能夠執行到Mono中的C#代碼。由於要打包Mono的環境,因此用C#開發出的Andriod應用apk文件會比原生開發出來的要大,效率嘛天然也是要低一些的。

  C#代碼要是想調用系統功能或者Java的實現類庫,能夠藉助MCW(Managed Callable Wrapper)的方式來實現。MCW是JNI(Java Native Interface)的橋樑,可使用託管代碼調用Andriod代碼。MCW經過將全部Andriod.*及相關的命名空間用jar綁定的方式暴露出來使得C#能夠直接調用。

  (粘貼)完Xamarin.Android,下面再(粘貼)下Xamarin.iOS吧:

  

  相較於Xamarin.Andriod而言,Xamarin.iOS就很簡單啦~用C#開發的iOS應用被編譯成IL(Intermediate Language,中間語言)代碼,就轉交給Apple Compiler,由其直接編譯成iOS的本機代碼。本質上來講,用C#寫的iOS應用和Objective-C寫出來的沒有什麼差異,是否是很棒!( • ̀ω•́ )

  爲表慶祝,再甩張圖慶祝一下:

  最後的最後,放上一張來自微軟的吶喊圖來結束這篇沒有什麼養分的介紹:

相關文章
相關標籤/搜索