使用一种编程语言(C#)针对多种移动平台进行定位/开发? 成本效益?

今天,可以使用C#编程来实现多种移动平台,例如:

  • WindowPhone7
  • Android – Monodroid
  • iPhone – Monotouch

(如果我错过了一些,可以随意编辑)当然,它仍然是UI的编程工作,但是应用程序的主库可以共享。

我们都可以感谢Mono项目周围的团队和超级英雄Miguel de Icaza,他们的努力是无价的。

令我困扰的是,这些选项有什么好处? 是否在多个移动平台上维护一个应用程序的成本较低,然后为了获得更好的性能而分别编码每个库。 学习每种语言的曲线? 作为所有交易的杰克与.NET忍者

或者知道,在本地环境中编程的应用程序的二进制文件的大小较小,甚至可能更好地优化,不要忘记,你必须等待新的平台的更新支持。

更新 :显然还有一件事要考虑,那就是支持。 由于Novell被Attachmate集团收购,所有Mono团队都被解雇。 然而由Miguel De Icaza领导的团队的核心成员成立了新的公司 Xamarin ,从头开始重塑Mono Mobile开发工具。

Solutions Collecting From Web of "使用一种编程语言(C#)针对多种移动平台进行定位/开发? 成本效益?"

在我看来,使用单一环境(即C#/。NET)的大亲是代码可移植性。 而像LINQ那样的酷炫的东西,一旦你习惯了,就不能没有。 但是,less数移动操作系统(iOS,Android,WP7)在UI方面有很大的不同。

而且,如果我没有弄错你的应用程序,如果它是在移动设备上运行的话,它将获得相当多的UI交互。 大多数移动应用程序就像80%的UI代码。

因此,您最终将为每个平台编写一组单独的UI代码 – 例如,您将使用Silverlight WP7(以及所有WPF的优点)来编写代码,您将编写一组完全不同的代码对于Cocoa(IB,视图,控制器和其他东西)中的iOS,您将会为Android编写一套完全不同的代码。

我的经验一直是,在任何平台上编写好的UI代码需要很多的经验 – 例如,学习WPF / SL已经是噩梦,抛出cocoa触摸和整个Android混乱。 当然,你可以编写三组看起来和感觉相似的用户界面,但很可能你会努力重复使用代码,并且具有共同的数据结构,与专用应用程序相比, – 在今天的这个手机应用程序的恶性世界里,一个非超级(更不用说低于标准)的用户界面体验意味着对你的应用程序的死亡。

而且,所有三个移动环境都有不同的连接范例,以及多媒体范例。 你最终写了三个版本,并学习三种环境,虽然用你熟悉的一种语言写作。

最重要的是后端模块。 决策引擎,search例程,数据pipe理等,甚至这些都会有问题,因为你会强迫在你的数据结构妥协,只是为了方便与三个不同的UI代码集合工作在三个不同的UI范例。 例如,您是否使用DependencyObjects来绑定到MVVM模型中的Silverlight视图? 如果你这样做,它将无法与cocoa的MVC模型一起工作,你必须单独编写这些绑定。

而且由于不是所有的移动环境都可以让你使用全套的function,例如,iOS版的MonoTouch不能在编译时无法确定的通用结构。 你基本上使用.NET的一个非常小的子集(并且必须不断地提醒自己在哪里可以使用哪些function),这样你就可以在三个不同的平台上运行它们,而不会发生显着的变化。

现在,图像在为支持整个.NETfunction集的WP7平台编写时具有所有这些限制。 我不了解你,但我会发疯的。 而且你的WP7应用程序永远不会与其他应用程序竞争。

在我看来,痛苦和妥协是不值得的。 你最终会得到三个马马虎虎的应用程序,这两个平台的人都不会喜欢这个应用程序。

除非所有的优点都在于你的应用程序的后端逻辑,否则人们就会忽略UI问题,只是为了获得应用程序的后端function。 根据我的经验,这几乎从来没有发生。

对我来说最大的好处是能够在移动平台之间重用业务逻辑和通信代码。 是的,我必须一遍又一遍地编写UI,需要时间来解决这个问题,但至less我的基础平台是可重用的。

根据我的经验,当学习一个新的平台时,学习UI框架要花费更多的时间,而不是学习一种新的语言。

由于接受的答案是在2011年编写的,所以出现了几种不同的框架,这些框架将MVC和MVVM模式带给了Mono for Android和MonoTouch,这为开发针对这些目标的应用程序提供了很多帮助。

对于MVC,请查看名为MonoCross的项目

对于MVVM,请查看Stuart Lodge的MvvmCross

后者包含了很多代码,用于在三个平台上打开图像,组成电子邮件,打开网页浏览器,播放声音等等。 它也处理ViewModels之间的导航。

代码/类库在整个平台上的可重用性肯定是一大优势。 考虑到这一点,您可以更快地移植/开发应用程序,从而降低成本。

而且,由于代码的可重用性,它将减less维护费用。

Monotouch / Droid-libraries有一些缺点。 有一点速度挫折(大约5%,在大多数情况下如此疏忽)。

根据我的经验,尺寸没有太大的差别。 大部分规模在资源 (数据资源,打包的图像和类似的 – 而不是处理器的使用),并且大多数应用程序不会携带那么多的资源(因为加载时间和在移动平台上的大量默认控件的可用性) 。

但我不认为你应该在游戏上使用框架。 我在手机游戏开发方面没有太多的经验,但是在游戏开发(XNA,Android的NDK ..)以及系统资源(处理器使用情况,内存等)方面使用的非常不同的框架使得它们非常没用恕我直言。

优点:

  • 使用相同的语言编码,并且(大部分)在每个平台上都可用
  • 缩短开发时间
  • 便宜

缺点:

  • 包括所需的库会极大地增加最小应用程序的大小 – 如果你的应用程序将会很大,那么差异就不那么显着了
  • 性能开销

如果你有钱和人,最好有一些专注于iPhone和Objective-C,一些Android和Java等人。这样你的程序员将有一个熟悉的平台,你的目标,将能够确保您的应用程序充分利用平台的function – 在所有平台上应用程序不应该完全相同(除了游戏),您需要发挥自己的优势和劣势:iPhone应用程序应该看起来像iPhone一样运行应用等

也就是说,如果你没有人力和财力,那么使用单一语言和几个框架肯定会更便宜,更快,并且可能会给你带来更好的结果,而不是单独为每个平台开发的努力。

另一种看待这个问题的方法是使用WebORB集成服务器,可以将现有的.NET / C#应用程序移植到各种移动客户端(包括本地和非本地),这相对容易。 在客户端,您必须以本地语言编写代码,或者您可以创build一个在不同的移动操作系统(如iOS,Android和BlackBerry PlayBook)之间相当便携的Adobe AIR应用程序。

跨平台解决scheme只适用于您的应用程序简单明了。 如果您需要具有复杂对象图的本地数据存储等复杂function,则可以使用本地数据库,也可以花费几个月来debugging问题