Xamarin 2.0 vs Appcelerator Titanium v​​s PhoneGap

时间:2013-06-22 10:07:16

标签: cordova xamarin titanium

在今年所有IDE演进(主题的所有平台都发生变化)之后,我想了解这些平台的技术状态。

每个人的优点和缺点是什么? 其中一种方法有一些限制吗?

我对C#和Javascript有很好的经验,而不是没有程序化的语言影响,可以倾向于一方。

6 个答案:

答案 0 :(得分:344)

概述

Tim Anderson

报道
  

跨平台开发是一个大交易,并将继续如此,直到每个人都使用相同的平台。 Android的?   HTML? WebKit的? iOS版?视窗? Xamarin? Titanum? PhoneGap的?电晕? ECC。

     

有时我听到它说基本上有两种方法   跨平台的移动应用程序。您可以使用 嵌入式   浏览器控件并编写一个 Web应用程序包装为本机应用程序,如   在Adobe PhoneGap / Cordova或Sencha采取的类似方法,或   您可以使用 创建原生的跨平台工具   应用,例如Xamarin Studio,Appcelerator Titanium或Embarcardero   FireMonkey。

     

但在第二类中,存在多样性。特别是,   它们在抽象用户的程度上有所不同   接口

     

这是权衡。如果您设计跨平台框架,那么   可以让您的应用程序在每个平台上的工作方式几乎相同。   如果您在所有平台上共享UI设计,那么很难   让您的设计在所有情况下都同样正确。它可能会更好   采用大多数游戏采用的方法,使用的设计   独特的应用程序,并在其中保持一致性   平台,即使它没有原生的外观和感觉   任何平台。

编辑 Xamarin v3在2014年开始提供Xamarin.Forms选择以及仍然遵循此处提到的哲学的纯粹本机(因为这样一个很好的答案而采取内联编辑的自由)

另一方面,Xamarin Studio不会尝试提供共享的GUI框架:

  

我们不会尝试提供有效的用户界面抽象层   跨所有平台。我们认为这是一种糟糕的方法   最小公分母用户界面。 (纳特弗里德曼给蒂姆安德森)

这是对的;但缺点是为您的应用程序维护两个或更多用户界面设计所需的努力。

关于PhoneGap和Titanium的比较,它在Kevin Whinnery博客中得到了很好的报道。

的PhoneGap

  

PhoneGap的目的是允许基于HTML的Web应用程序   部署并作为本机应用程序安装。 PhoneGap网站   应用程序包装在本机应用程序shell中,也可以   通过本机应用程序商店安装多个平台。   此外,PhoneGap致力于提供通用的本机API集   这通常对Web应用程序不可用,例如基本的   相机访问,设备联系人和尚未曝光的传感器   浏览器。

     

要开发PhoneGap应用程序,开发人员将创建 HTML,CSS,   和本地目录中的JavaScript 文件,就像开发一个   静态网站。接近原生品质的UI性能   浏览器是一项非常重要的任务--Sencha雇用了一个庞大的网络团队   编程专家专职专职解决这个问题。甚至   因此,在大多数平台上,在今天的大多数浏览器中,达到   即使使用与Sencha Touch一样先进的框架,原生品质的用户界面性能和响应能力也只是不可能。是个   浏览器已经“足够好”了吗?这取决于您的要求   和敏感,但毫无疑问,它比原生UI更不好。   有时甚至更糟糕,取决于浏览器。

PhoneGap并不像人们所认为的那样真正的跨平台,并非所有平台都支持所有功能。

  • Javascript不是一种应用程序规模的编程语言,太多的全局范围交互,不同的库通常不能很好地共存。我们花了很多时间试图让knockout.js和jQuery.mobile一起玩,我们仍然有问题。

  • 框架和库的碎片化格局。选择太多,太多选择还不够成熟。

  • 奇怪的是,为了满足我们应用的需求,可以实现不错的性能(不过jQuery.Mobile)。我们尝试了jqMobi(不是很成熟,但很快)。

  • 与其他应用程序或cdevice功能交互的能力非常有限,而且这不会是跨平台的,因为HTML5中没有任何标准,除了一些标准,如地理定位,相机和本地数据库。

Karl Waclawek

Appcelerator Titanium

Titanium Mobile的目标是提供高级别,跨平台JavaScript 运行时和 API for mobile 开发(今天我们支持iOS,Android和Windows Phone.Titanium实际上与MacRuby / Hot Cocoa,PHP或node.js有更多共同之处,而不是PhoneGap,Adobe AIR,Corona或Rhomobile.Titanium建立在两个关于移动开发的断言上:   - 移动开发API的核心可以跨平台进行规范化。这些区域应该成为代码重用的目标。   - 开发人员在为该平台开发时应该包含特定于平台的API,UI约定和功能。这些用例应该存在特定于平台的代码,以提供最佳体验。

因此,出于这些原因, Titanium并非尝试“一次编写,随处运行”。与Xamarin相同。

Titanium将朝着类似于Xamarin的方向迈出更大的一步。在实践中,他们将做两层不同的深度:钛层(在JS中),它为您提供了一个蜜蜂JS-of-Titanium。如果你想更低级别,已经创建了一个额外的层(称为Hyperloop),其中(总是使用JS)直接回调给SO的原生API

Xamarin(+ MVVMCross)

AZDevelop.net

  Xamarin(最初是Novell的一个部门)在过去的18个月里   推出了自己的IDE和Visual Studio管理单元。该   强调Mono的前提是创建不同的移动应用程序   在维护原生UI开发策略的同时使用C#。

     

除了创建一个开发原生的视觉设计平台   应用程序,他们已集成测试套件,并入原生   库支持和Nuget样式组件存储。最近他们   提供iOS视觉设计通过他们的IDE释放开发人员   从打开XCode。在Visual Studio中,现在都是三个平台   支持和云测试套件即将推出。

     

从一开始,Xamarin就提供了丰富的Android视觉设计   经验。我还没有下载或打开Eclipse或任何其他IDE   除了Xamarin。真正令人惊奇的是我能够使用LINQ   使用集合以及创建自定义委托和事件   这让我摆脱了客观C和Java的限制。很多人   我被宠坏了的库,比如Newtonsoft JSON.Net,工作   完美地适用于所有三种环境。

在我看来,有几个巨大的优势,包括

  • 原生表演
  • 更易于阅读代码(IMO)
  • 可测试性
  • 客户端和服务器之间的共享代码
  • 支持(虽然Xam可以在bugzilla上做得更好)

升级对我来说是使用Xamarin和MVVMCross的组合。它仍然是一个相当新的框架,但它源自其他几个框架(如MvvmLight和monocross)的经验,现在已经在几个已发布的跨平台项目中使用。

结论

在了解所有这些框架后,我的选择是选择基于产品需求的开发工具。一般情况下,如果你开始使用一个你觉得舒服的工具(即使它需要更高的初始开销),你将永远使用它。

我选择 Xamarin + MVVMCross ,我必须说对此选择感到满意。 我不害怕接近Native SDK进行软件更新或看到系统的有限功能或者最重要的功能图形。 编写相当结构化的代码(DDD + SOA)非常有用使核心项目与本机C#视图实现共享。

参考和链接

答案 1 :(得分:103)

我对Appcelerator Titanium的工作并不多,但最后我会理解它。

我可以更多地谈谈PhoneGap和Xamarin之间的差异,因为我每周工作这两天(或更多)。

如果您已经熟悉C#和JavaScript,那么我想问的是,业务逻辑是否位于更适合JavaScript或C#的区域?

的PhoneGap

PhoneGap旨在允许您使用 JavaScript和HTML 编写应用程序,并且它们提供的大部分功能旨在模仿当前提出的最终可用功能的规范使用HTML5。我认为PhoneGap的最大好处是,由于您使用HTML进行用户界面,因此可以轻松地在平台之间移植。缺点是,因为您在平台之间移植相同的UI,所以在任何一个平台上都不会感觉像在家一样。这意味着,如果不进一步调整,您无法在iOS和Android中拥有完全在家的应用程序,这意味着它具有iOS和Android样式。您的大部分逻辑都可以使用JavaScript编写,这意味着它也可以在平台之间移植。如果当前PhoneGap API完成了您想要的大部分内容,那么它很容易启动并运行。但是,如果您需要从设备中获得不属于API的内容,那么您将获得插件开发的乐趣,它将位于本机设备的开发中选择的语言(有一点需要注意,但我会谈到这一点),这意味着您可能需要在Objective-C,Java等中快速掌握这个模型的好处。 ,您是否通常可以调整许多不同的本地库来满足您的需求,许多库已经有PhoneGap插件。虽然您可能对这些语言没有多少经验,但至少可以使用过多的例子

Xamarin

Xamarin.iOS和Xamarin.Android(也称为MonoTouch和MonoDroid)旨在让您拥有一个业务逻辑库,并在您的应用程序中使用它,并将其挂钩到你的用户界面因为它基于.NET 4.5,所以你会得到一些 awesome lambda notations LINQ ,还有一大堆其他的C#awesomeness,它们可以让你的业务更好逻辑不那么痛苦。这里的缺点是,Xamarin希望您希望让您的应用程序在设备上真正感觉原生,这意味着您可能最终重写每个平台的UI ,然后将其与业务连接起来逻辑。我听说过 MvvmCross 旨在让您更轻松,但我还没有机会深入了解它。如果您熟悉C#中的 MVVM 系统,您可能需要查看此内容。当涉及到本地库时,MonoTouch变得有趣。 MonoTouch需要 Binding来告诉您的C#代码如何链接到底层的Objective-C和Java代码。其中一些库已经有了绑定,但是如果你没有绑定,创建一个可能很有趣。 Xamarin已经创建了一个名为 Objective Sharpie 的工具来帮助完成这个过程,并且在大多数情况下,它会让你<95>完成。剩下的5%可能会花费80%的时间来尝试绑定库。

<强>更新

如下面的评论中所述,Xamarin发布了Xamarin Forms,这是围绕特定于平台的UI组件的跨平台抽象。绝对值得一看。

PhoneGap / Xamarin Hybrid

现在因为我说我会接受它,上面的PhoneGap中提到的警告是混合方法,你可以使用PhoneGap作为部分,而Xamarin作为部分。我对此有很多经验,我会警告你反对它。的高度即可。这个问题,是这样的 no mans&#39;土地如果你遇到问题,几乎没有人会接近你正在做的事情,并会质疑你想要做的事情。这是可行的,但它绝对不好玩

Appcelerator Titanium

正如我之前提到的,我对Appcelerator Titanium没有多大帮助,所以对于它们之间的差异,我建议您查看Comparing Titanium and PhonegapComparison between Corona, Phonegap, Titanium,因为它非常彻底描述差异。基本上,似乎虽然他们都使用JavaScript ,但JavaScript的解释方式略有不同。使用Titanium,您将将JavaScript编写到Titanium SDK ,而使用PhoneGap,您将使用PhoneGap API编写应用程序。由于PhoneGap非常符合HTML5和JavaScript标准,因此您可以使用任何您想要的JavaScript库,例如JQuery。使用PhoneGap,您的用户界面将由HTML和CSS组成。使用Titanium,您将受益于跨平台XML ,它似乎生成原生组件。这意味着它肯定会有更好的原生外观。

答案 2 :(得分:38)

我曾与Xamarin合作过。以下是我发现的积极和消极因素:

<强>积极因素

  1. 易于编码,C#使工作更轻松
  2. 表现不会成为一个问题
  3. 原生UI
  4. 好的IDE,很像Xcode和Visual Studio。
  5. Xamarin Debugger
  6. Xamarin SDK是免费的开源软件。 Wiki
  7. <强>否定

    1. 您需要了解要定位的每个平台的API(iOS,Android,WP8)。但是,您不需要了解Objective-C或Java。
    2. Xamarin在平台上只分享一些东西(比如数据库和网络服务)。
    3. 你必须分别设计每个平台的UI(这可能是一种祝福或诅咒)。

答案 3 :(得分:11)

Phonegap非常慢:单击按钮最多可能需要3秒才能显示下一个屏幕。 iscroll是缓慢和跳跃的。

我能够克服其他有趣的错误和问题, 但总的来说 - 还没有完全成熟。

编辑: 根据Grumpy的评论,它不是Phonegap实际上很慢,它是JS / Browser本机引擎

答案 4 :(得分:8)

还有AppGyver Steroids很好地将PhoneGap和Native UI结合在一起。

使用类固醇,您可以在PhoneGap应用程序中添加本机标签,本机导航栏,本机动画和过渡,本机模态窗口,本机抽屉/面板(脸谱侧面菜单)等内容。

这是一个演示:http://youtu.be/oXWwDMdoTCk?t=20m17s

答案 5 :(得分:4)

作为替代方案,您可以在bridgeit.mobi查看BridgeIt。开源,它已经解决了上面讨论的浏览器性能/一致性问题,因为它利用了设备上的标准浏览器和Web视图浏览器。它还允许您访问本机功能,而无需担心应用商店部署和/或本机容器。

我已经使用过简单的基于相机的访问和扫描仪访问,它适用于简单的应用程序。文档有点轻松。不确定它将如何处理更复杂的应用程序。