c# – Xamarin：与原生SDK和基于JS的框架进行比较

因此,使用 Android和iOS提供的本机SDK进行编码的主要功能之一是,您不仅可以获得更好的性能,还可以获得每个平台的外观和感觉：例如,在iOS上,选项卡导航bar会位于屏幕的底部,而在Android中它位于顶部(是的,我知道它也可以是顶部和底部,但你得到我的观点),或者导航抽屉底座是Android导航样式虽然(据我所知),iOS原生sdk没有类似的东西.我的观点是,您可以通过设计指南来感受平台的不同,这是一件好事,因为它使您的应用看起来很专业.

因此,考虑到性能并保持应用程序的感觉,使用基于JS的框架(如Titanium或PhoneGap)将不会做出明智的选择.

然后是Xamarin.正如我在这里读到的：Xamarin how it is getting the Native Look and Feel?它似乎是原生SDK的C#包装器,据我所知,它不应该影响性能.但是外观和感觉部分在哪里.由于XML布局不完全是Android或iOS应用程序的感觉,而且导航(来自控制器类)Xamarin如何处理这些？据说在他们的网站上你可以在平台之间共享代码,但这也意味着我必须共享导航系统和类似的？

最后,为了“不为每个平台编写代码”,不值得使用原生SDK并与Xamarin一起使用(我在为iOS和Android编写代码时没有问题),或者是这个框架目标对于C#开发人员来说,他们不必学习Objective-C或Android.

任何额外的解释都会很棒,并提前感谢.

解决方法

我在去年(2013年)内使用不同的组件构建了一个大型应用程序：主要是API(ASP.NET Web API => C#),网站(ASP.NET MVC => C#AngularJS),以及两个应用程序Android(Xamarin.Android => C#)和iOS(Xamarin.iOS => C#).使用Xamarin的决定有其优点和缺点,但总而言之,我对此非常满意.

正如您在上面的列表中所看到的,几乎所有内容都是使用C#完成的(好吧,网站主要用JavaScript编写;-)).它是一种非常好的成熟语言,具有非常好的功能(如LINQ).在我的场景中,它变得清晰：我不需要学习和完善四种语言(Swift / Objective-C,Java,C#,JavaScript),但只有两种：C#和JavaScript.

关于代码共享方面尤其如此：我们的客户端应用程序并不是真正的瘦客户端,因为某些离线功能需要大量的同步逻辑,因此两个应用程序的UI部分只是奖牌的一面.事实证明,我真的可以在iOS和Android上使用90％的非接口代码.这是一个非常巨大的好处,因为它不仅涉及Swift / Objective-C或Java的一些语言原创性,还涉及您在iOS和Android上使用的不同框架.要使用.NET Framework / Mono作为每个Xamarin应用程序的基础,您可以从底层操作系统中抽象出数据访问或网络通信等内容.

在速度和UI方面,您没有任何缺点,因为您使用本机API 1：1.无论在iOS还是Android上都可以通过Xamarin获得.每当Apple发布新版本的iOS时,Xamarin将在几天内发布更新,因此您无需等待Apple能够使用新推出的功能.

Xamarin在iOS上使用了一种名为Ahead of Time Compiling的技术,因此您在C#中编写的所有内容在部署到您的设备之前都会编译为本机iOS内容.这意味着“本机”Objectice-C应用程序和Xamarin应用程序之间执行的内容没有区别(除了一些小的开销,这是我的经验中不值得注意的).

在Android上即时编辑也可以与任何其他“原生”Android应用程序一起使用.

如果您选择使用Objective-C或Java,那就意味着您拥有所有完全相同的API和可能性.您甚至可以使用相同的对象来构建具有完全相同类型和名称的UI(有时稍微优化;)).因此,如果您需要为应用程序显示标签栏 – 您可以使用UITabBarController.见iOS与Xamarin.

在与Xamarin一起旅行多年后,我只有一个缺点：

可能的内存泄漏.他们的整个样本有很多关于防止内存泄漏的基本知识的废话.如果您正在使用应用程序中的媒体文件等“昂贵的资源”,那么您应该从第一天开始就注意.当我的应用程序已经增长到多达35个不同(复杂)的对话框时,我不得不摆脱所有这些问题.这花了我差不多两个月,换句话说花了几千美元. They provide some documentation关于它,但这个工具很差.并且可能出现错误并且很难找到(example).

但总而言之,这是我与Xamarin一起做出的最佳决定之一.