如今，可以对多种移动平台使用 C# 编程，例如：
（如果我错过了，请随时编辑一些）
当然，这仍然是UI的编程工作，但应用程序的主要库可以共享。
我们都应该感谢围绕 Mono 项目和超级英雄Miguel de Icaza，他的努力是无价的。
让我困扰的是，这些选择有什么好处？
跨多个移动平台维护一个应用程序的成本是否比必须单独编码每个库以获得更好的性能的障碍更少？每种语言的学习曲线？成为万事通 vs .NET Ninja
或者知道在本机环境中编程的应用程序二进制文件的大小更小，甚至可能优化得更好，并且不要忘记您必须等待新平台操作系统更新的支持。
更新：显然还有一件事需要考虑，那就是支持。由于Novell被Attachmate Group收购，所有Mono团队都被解雇。然而，Miguel De Icaza 领导的团队核心成员 创立了新公司 Xamarin 将从头开始重塑 Mono Mobile 开发工具。
Today it is possible to use C# programming for multiple mobile platforms such as:
(feel free to edit if I missed some)
Of course, it is still programming effort for UI, but main libraries of app can be shared.
We can all thank to a team gathered around Mono project and superhero Miguel de Icaza whose effort is priceless.
What bothers me is, what are the benefits of these options?
Is it cost of maintaining one app across multiple mobile platforms less impediment then having to code each library separately for better performance. Learning curve of each language? Being Jack of All trades vs .NET Ninja
Or knowing that binaries of app programmed in native environment are less in size, maybe even optimized better and not to forget that you have to wait support of new platform os updates.
UPDATE: Obviously there is one more thing to consider and that is support. Since Novell is bought by Attachmate Group, all Mono team is laid off. However the core member of the team lead by Miguel De Icaza founded new company Xamarin which will reinvent Mono Mobile development tools from the scratch.
发布评论
评论（8）
Monotouch/Droid 库有一些缺点。有一点速度下降（大约 5%，因此在大多数情况下可以忽略不计）。
根据我的经验，尺寸差别不大。大部分大小都在资源中（数据资源、打包图像等 - 不是处理器使用情况），并且大多数应用程序不会携带那么多资源（因为加载时间和可用性）移动平台上有很多默认控件）。
然而，我认为你不应该在游戏中使用框架。我在手机游戏开发方面没有太多经验，但是您在游戏开发中使用的截然不同的框架（XNA、Android 的 NDK...）以及对系统资源（处理器使用、内存等）的需求使它们变得毫无用处恕我直言。
There are certain drawbacks to the Monotouch/Droid-libraries. There is a little speed setback (about 5%, so neglectable in most of the cases).
In my experience, the size does not differ that much. Much of the size is in the resources (data resources, packed images and alike - not processor usage), and most apps don't carry that much resources with them (because of loading times and the availability of much default controls on mobile platforms).
I don't think you should use the frameworks on games however. I don't have much experience in mobile game development, but the pretty different frameworks you're using in game development (XNA, Android's NDK..) and the need for system resources (processor usage, memory etc.) make them pretty useless imho.
优点：
缺点：
如果你有钱和人，最好让一些人专注于 iPhone 和 Objective-C，一些人专注于 Android 和 Java 等。这样你的程序员将对你的目标平台有深入的了解，并且能够确保您的应用程序充分利用平台的功能 - 应用程序在所有平台上不应该完全相同（游戏除外），您需要发挥它们的优点和缺点：iPhone 应用程序的外观和功能应该像 iPhone也就是说
，如果您没有人员或资金，使用单一语言和多个框架肯定更便宜、更快，并且可能会给您带来比单独为每个平台进行开发的紧张尝试更好的结果。
Advantages:
Disadvantages:
If you have the money and the people it's always better to have some people focused on the iPhone and Objective-C, some Android and Java etc. That way your programmers will have an intimate knowledge of the platform you are targeting and will be able to make sure your application takes full advantage of the platform's features -- an app should not be exactly the same (except perhaps games) across all platforms, you need to play to their strengths and weaknesses: an iPhone app should look and function like an iPhone app etc.
That said, if you don't have the people or the money, using a single language together with several frameworks is certainly cheaper and faster, and may give you better results than the result of strained attempt to develop for each platform individually.
另一种看待这个问题的方法是，您可以使用 WebORB 集成服务器。在客户端，您必须使用本地语言进行编码，或者您可以创建一个在不同移动操作系统（例如 iOS、Android 和 BlackBerry PlayBook）之间相当可移植的 Adobe AIR 应用程序。
Another way to look at this is you could port an existing .NET/C# application to a variety of mobile clients (both native and non-native) relatively easy using WebORB integration server. On the client side you would have to code in either the native language or you could create an Adobe AIR application that is fairly portable across different mobile OS' such as iOS, Android and BlackBerry PlayBook.
仅当您的应用程序简单明了时，跨平台解决方案才有效。
如果您需要复杂的功能，例如具有复杂对象图的本地数据存储，请使用本机或预计花费数月时间来调试问题
Cross-platform solution only works if your application is simple and straightforward.
If you require complex features such as local data store with complex object graphs, go native or expect to spend months to debug problems
在我看来，使用单一环境（即 C#/.NET）的一大优点是代码可移植性。还有像 LINQ 这样很酷的东西，一旦你习惯了它，你就离不开它。然而，少数移动操作系统（iOS、Android、WP7）在 UI 方面有很大不同。
而且，如果我对您的应用程序没有误解的话，如果它要在移动设备上运行，它就会有相当一部分的 UI 交互。大多数移动应用程序的 80% 都是 UI 代码。
因此，无论如何，您最终都会为每个平台编写一组单独的 UI 代码 - 例如，您将在 Silverlight WP7（以及所有 WPF 优点）中编写，您将编写一组完全不同的代码对于 Cocoa 中的 iOS（IB、视图、控制器等），您将为 Android 编写一组完全不同的代码。
我的经验一直是，在任何平台上编写好的 UI 代码都需要大量的经验——例如，学习 WPF/SL 已经是一场噩梦，再加上 Cocoa Touch 和整个 Android 的混乱。当然，您可以编写三组外观和感觉相当相似的 UI，但很可能您会非常努力地重用代码并拥有通用的数据结构，以至于与专用应用程序相比，您的 UI 最终会低于标准 - - 在当今这个竞争激烈的移动应用程序世界中，非超级（更不用说低于标准）的 UI 体验意味着您的应用程序的死亡。
此外，所有三种移动环境都具有不同的连接范例以及多媒体范例。尽管是用您熟悉的一种语言编写，但您最终还是编写了三个版本，并学习了三种环境。
您最常重用的是后端模块。决策引擎、搜索例程、数据管理等。甚至这些也会出现问题，因为您将被迫在数据结构中做出妥协，只是为了能够与在三种不同 UI 范例上工作的三组不同 UI 代码轻松集成。例如，您是否使用 DependencyObjects 来绑定到 MVVM 模型中的 Silverlight 视图？如果这样做，它将无法与 Cocoa 的 MVC 模型一起使用，并且您必须单独编写这些绑定的代码。
而且，由于并非所有移动环境都允许您使用全套功能 - 例如，iOS 的 MonoTouch 不具有无法在编译时确定的通用构造。您本质上使用的是 .NET 的一个非常小的子集（并且必须不断提醒自己可以在哪里使用哪些功能），以便您可以在三个不同的平台上运行它们，而无需进行重大更改。
现在，当您为支持整个 .NET 功能集的 WP7 平台编写代码时，想象一下所有这些限制。我不知道你怎么想，但我会发疯的。而且您的 WP7 应用程序永远无法与其他应用程序竞争。
在我看来，痛苦和妥协是不值得的。最终你会得到三个马马虎虎的应用程序，两个平台上的人都不会喜欢它们。
除非所有优点都在于您的应用程序的后端逻辑，并且它太好了以至于人们会为了了解您应用程序的后端功能而忽略 UI 问题。根据我的经验，这种情况几乎不会发生。
In my opinion, the big pro of using one single environment (i.e. C#/.NET) is code portability. And cool things like LINQ that, once you get used to it, you can't live without. However, the few mobile OS's (iOS, Android, WP7) are quite different with regards to UI.
And, if I am not mistaken about your application, it's got a fair share of UI interactions if it is to run on a mobile device. Most mobile apps are like 80% UI code.
Therefore, you'll end up writing a separate set of UI code for each platform anyway -- for example, you'll be writing in Silverlight WP7 (and all the WPF goodness), you'll be writing a completely different set of code for iOS in Cocoa (IB, Views, controllers and stuff), you'll be writing yet a completely different set of code for Android.
My experience has always been that it take a lot of experience to write good UI code on any platform -- e.g. learning WPF/SL is already the nightmare that is, throw in Cocoa Touch and the whole Android mess. Of course you can write three sets of UI that look and feel reasonably similar, but chances are that you'll be trying so hard to reuse code and have common data structures that your UI's will end up sub-par when compared to dedicated apps -- and in this cut-throat world of mobile apps today, a non-super (not to mention sub-par) UI experience means death to your app.
Also, all three mobile environments have different connectivity paradigms, as well as multimedia paradigms. You end up writing three versions, and learning three environments, albeit writing in one language you're familiar with.
The most you're going to reuse is back-end modules. Decision engines, search routines, data-management etc. And even these are going to be problematic because you'll be force to have compromises in your data structures just to enable easy integration with three different sets of UI code working on three different UI paradigms. For example, do you use DependencyObjects for use to bind to Silverlight views in an MVVM model? If you do, it won't work with Cocoa's MVC model, and you have to code those bindings separately.
And since not all mobile environments enable you to use the full set of functionalities -- for example, MonoTouch for iOS does not generic constructs that cannot be determined at compile time. You're essentially using a very small subset of .NET (and must constant be reminding yourself what functionality can be used where) just so that you can run them all on three different platforms without significant changes.
Now image having all these limitations when you are writing for the WP7 platform, which supports the entire .NET features set. I don't know about you, but I'll go crazy. And your WP7 app is never going to be even close to being competitive with other apps out there.
In my opinion, the pain and the compromises are not worth it. You'll end up with three so-so apps, which people in neither of the platforms are going to like.
Unless all the goodness lies in your app's back-end logic, and it is so good that people are going to ignore UI issues just to get to your app's back-end functionalities. In my experience, this almost never happens.
对我来说最大的优势是能够在移动平台之间重用业务逻辑和通信代码。是的，我必须一遍又一遍地编写 UI，并且需要时间来理解这一点，但至少我的基础平台是可重用的。
根据我的经验，当迁移到新平台时，学习 UI 框架比学习新语言花费的时间要长得多。
The biggest advantage for me is the ability use reuse the business logic and communications code between mobile platforms. Yes, I have to write the UI over and over again, and it takes time to get your head around that, but at least my base platform is reusable.
In my experience when moving to a new platform, it takes me a lot longer to learn the UI framework than to learn a new language.
由于接受答案自 2011 年编写以来，已经出现了几个不同的框架，它们将 MVC 和 MVVM 模式引入 Mono for Android 和 MonoTouch，这在为这些目标开发应用程序时有很大帮助。
对于 MVC，请查看名为 MonoCross 的项目
对于 MVVM，请查看 Stuart Lodge 的 MvvmCross
后者包含大量用于在三个平台上打开图像、撰写电子邮件、打开网络浏览器、播放声音等等的代码。它还处理 ViewModel 之间的导航。
Since the accepted answer had been written in 2011, a couple of different frameworks have emerged, which bring MVC and MVVM patterns to Mono for Android and MonoTouch, which helps quite a lot when developing applications for these targets.
For MVC check out the project called MonoCross
For MVVM check out Stuart Lodge's MvvmCross
The latter contains a lot of code for opening images on the three platforms, composing e-mails, opening webbrowsers, playing sounds and much more. It aslo handles navigation between ViewModels.
一个很大的优势当然是跨平台的代码/类库的可重用性。考虑到这一点，您可以更快地移植/开发应用程序，从而降低成本。
另外，由于代码的可重用性，也会减少维护费用。
a big advantage is certainly the reusability of code / class libraries across the platforms. With that in mind you`re able to port/develop applications even faster, which in turn reduces the costs.
Also, because of the reusability of code, it will reduce maintenance expenses.