2015-09-05 34 views
2

我想評估Xamarin是否會成爲我的項目的一個很好的選擇。該項目是一個大型,複雜的Android和iOS應用程序,具有很多客戶端 - 服務器通信。用戶界面是一個重點,必須非常快速和流暢。此外,我們計劃大量使用UX圖形效果(可與Spotify應用程序相媲美)。Xamarin跨平臺用戶體驗與原生開發

現在我們正在計劃使用Java/Objective-C爲兩個獨立的本機應用程序。但是,跨平臺代碼共享的可能性對我們當然是非常方便的。

到目前爲止,我聽到的大多數意見都表示,Xamarin雖然遠遠優於HTML5應用程序,但卻無法與原生應用程序的用戶體驗相匹配。另外,我測試了Xamarin(Android上)做出瞭如下應用:

  • RDIO
  • 市場觀察
  • 布希花園發現指南
  • Sqor
  • Storyo

從我的印象,它們中的任何一個都不能完美匹配優秀原生應用的速度和平滑度。

如果我們專注於一流的用戶體驗,Xamarin會真的成爲一個可行的選擇嗎?它能真正匹配本地UX嗎?我特別希望從具有大型和複雜的跨平臺Xamarin應用程序經驗的開發人員那裏獲得意見。一些批評聲音會很有幫助。

非常感謝!

+0

我是我問了一個類似的問題,並做了與你相同的測試:Storyo,snap-attack和MarketWatch。但我的印象是它非常非常流暢,並不覺得它不是真正的本地應用程序。你可以測試這些應用程序,也許現在給我們你的印象plz? – Jerome2606

回答

6

我在Rdio移動開發團隊,所以我可以從這個角度進行一些個人反思。

Xamarin允許您使用C#編寫原生應用程序。任何緩慢,笨拙,醜陋或不合適通常與Xamarin層本身無關。

您可以節省一些時間在不同客戶端之間共享核心業務邏輯,但是您仍然從頭開始編寫特定於平臺的UI。你只是用C#編寫它。

但是,當你節省時間,你花在其他方式。所有您想使用的SDK都可能與Xamarin不兼容。您不會在iOS框架中安裝pod install,並且您可能正在爲少數事情重新發明輪子。 Xamarin利用NuGet repo,所以你有一個組件庫可以處理大多數人需要的東西(分析,測試,Facebook SDK,JSON解析,數據庫等等),但它並不包含所有內容。它當然不包括蘋果或谷歌產品發佈當天的內容。

任何您想要導入到項目中的第三方代碼都將通過編寫custom bindings完成。雖然不是通常困難,但它是耗時。 Xamarin有一個專門幫助你的人。這個事實說明了這個過程有時是混亂的。因此,雖然緩慢,笨拙,醜陋或不合適可能不是Xamarin的錯,但它可能是您在通常不會的地方花費時間,或者不能夠利用功能你通常會。如果該第三方合作伙伴SDK給您帶來問題,您的疑難解答可能需要兩倍的時間,因爲有一層您無法控制。

  • UI是一種洗滌劑。無論如何你都是從頭開始寫的。
  • 業務邏輯是共享的。如果您構建應用程序以利用它,則取決於可能贏得的應用程序。
  • 缺乏兼容性/出血邊緣的能力。這對你來說可能並不重要,或者你可能是那個想要在宣佈它的下一個操作系統版本中利用這個熱門新API的人。

我個人的想法,不知道具體情況,如果你想建立一個應用程序,你打算在將來幾年左右,這將利用最新最好的,我會告訴你寫本地爲每個平臺。除非您真的能看到共享該業務邏輯的巨大收益,否則前期收益極少。或者如果你真的喜歡C#。

2

Xamarin使用本機控件。所以你設計一個完全原生的UI每個平臺。用戶看不到您的應用是用Xamarin或Java/Objective-C製作的。 有時與平臺無關的UI封裝器Xamarin.Forms一起出現性能問題。但是你並沒有被迫使用它。當您的Xamarin.AndroidXamarin.iOS應用程序仍然存在性能問題時,請在代碼中生成它們。

有Android應用程序比較Xamarin.AndroidJava應用基準測試結果:Does anyone have benchmarks (code & results) comparing performance of Android apps written in Xamarin C# and Java?

正如你可以看到Xamarin的內部性能成爲在時間好。

結論:是的,您可以使用Xamarin編寫流暢的本地應用程序。