应用程序开销
基于Xamarin的应用程序具有内置开销,平均而言它们更大。这会影响设备上的下载时间和存储空间。最少需要额外几兆字节的空间,并且随着代码使用更多API,这个空间可能会成比例地增长。这是因为.NET组件中的代码会被静态链接(作为本机代码)到应用程序中,随着引用组件的增加而增加。在Android上,由于特定于操作系统的原因,应用程序启动时还会有额外的延迟。值得赞扬的是,Xamarin在减少此开销方面已经取得了很大进展。然而,对应用程序用户的影响仍然是可衡量的。
iOS和Android之间UI代码共享的限制
用户界面开发在iOS和Android之间不具备可移植性。
这意味着必须为每个平台使用和编写不同的API、事件逻辑、小部件和设计师。对于一些常见的低级操作,有一些例外。
Xamarin认为,在非常不同的平台之间尝试抽象UI API会增加不必要的复杂性或导致LCD(最低公共分母)设计的糟糕用户体验。他们在这里有一点道理。Titanium试图部分地实现此功能,结果使许多开发人员对不一致或不可预测的结果感到不满。HTML5应用程序在不强制使用LCD设计的情况下更成功地实现了此UI抽象,但它们没有Xamarin的本地性能。
UI问题可能是开发移动应用程序中最耗时的方面之一。尽管有很好的理由,但重要的结论是:对于许多移动UI问题,Xamarin将不会为开发人员或设计师节省时间。
限制代码在 Xamarin 外部的共享
Xamarin 不允许在其环境之外创建可重用组件或模块。例如,使用 Xamarin 编写的代码无法在本机或 HTML5 应用程序中使用。这意味着由使用 Xamarin 的团队开发的任何代码都不能与使用其他工具对 iOS 和 Android 进行开发的团队共享或重用。这在多大程度上会产生影响,取决于具体情况,但问题在于我们无法预测所有情况。因此,这是一个不舒服的限制,从一开始就存在。
生态系统和社区
这并不是 Xamarin 的错。哪家公司拥有与 Apple、Google 或 HTML5 相匹配的移动生态系统呢?然而,它很重要。当开发人员在搜索有关问题的信息时,如果能够找到10倍的结果数量,这将直接影响生产力。可用支持、服务和第三方组件以及相关工具的生态系统将继续比基于原生或 HTML5 的应用程序小得多。
第三个学习曲线
某些概念和技术需要特定于 Xamarin 环境的专业知识。这实际上为开发人员增加了第三个学习曲线,超出了编程语言和本地 API。例如,开发人员必须理解 iOS 引用计数以避免在 Xamarin 的垃圾收集中出现问题(Is this a bug in MonoTouch GC?)。另一个例子是数据结构和泛型以微妙的不同方式工作(http://docs.xamarin.com/guides/ios/advanced_topics/limitations)。这些是在实际采用新平台之前难以看到的问题,因此需要特别考虑。
更多的移动部件
Xamarin引入了它自己的一套bug,影响了产品质量和开发者生产效率。问题不在于Xamarin有一个糟糕的产品,而是将任何大型或复杂系统添加到应用程序工具链中都会带来不存在于原生应用程序中的问题和错误。
这些错误的历史记录可以使用Xamarin的Bug跟踪器(https://bugzilla.xamarin.com)进行查看。
是的,所有软件都有漏洞。关键是当您衡量添加新工具的优势时,必须考虑到新问题的劣势。
总结
最终,我们必须尝试量化像Xamarin这样的开发抽象相对于其他抽象或本地开发的优势。C#比Objective-C好吗?以我的意见来说,是的,远远优于Objective-C,但这只是其中的一个因素。当您将所有内容加起来时,它倾向于其他移动开发方法,例如2013年时我更喜欢本地代码解决方案或HTML5/Cordova解决方案。我喜欢它们的不同之处,并将尝试在另一篇文章中解释一些决策因素。