为了最大化Mono代码的可移植性,我应该注意哪些约束?

时间:2011-10-04 09:36:50

标签: c# mono xamarin.ios portability xamarin.android

我有兴趣使用Mono编写一些跨平台代码,以便定位移动iOS和Android运行时。

我已经仔细阅读过Mono和MonoTouch网站,但没有看到任何特别建议不使用的方法,或Mono钩子应该避免。但是,这似乎有点太好了。

进入这个项目应该注意哪些限制,以确保代码的最大可移植性?

4 个答案:

答案 0 :(得分:3)

API明智的是,当使用MonoTouch或Mono for Android(M4A)时,你会得到一个非常相似的基类库(BCL),因为它们共享相同的移动配置文件(这是最初基于Silverlight配置文件并增强使用更多FX 4.0 API。

这是很多常用代码。 BCL的差异很小但有些确实存在,主要是因为在 iOS 设备上运行需要一些妥协,这会产生一些limitations

BCL 之外,MonoTouch和M4A都为其平台提供绑定。例如。 MonoTouch提供了monotouch.dll,它绑定了大多数iOS(基于C或基于ObjectiveC的)API。该部分不适用于Android的Mono(对于M4A提供的Android绑定也是如此)。

这就是你需要设计一个最小化差异的地方。在许多情况下,不同的方面是用户界面,并且有一些方法,其中许多是基于MVC(例如MonoCross)来实现这一点开发人员更容易,同时为每个平台提供原生外观。

答案 1 :(得分:2)

除了UI之外,养成确保外部依赖项具有跨所有所需平台运行的变体的习惯,或者准备将它们分解出来。

对我来说,陷阱是:

  • 压缩 - 在silverlight中不可用,用户sharpziplib if 需要(我知道你不是针对silverlight,但为了以防万一。)
  • 序列化 - Protobuf-net是您的朋友。
  • 存储空间 - 这是最棘手的。您使用的是常规IO,还是 孤立存储,或在一个平台上的一件事和其他东西 另一个?此外,mono.sqlite几乎可以在任何地方工作,除了 银光,所以顺其自然,并有一个应急计划 如果需要,银光。
  • 在MS上发明 - 忘了这些东西。 WCF,实体框架, SQL-CE,LINQ to SQL,以及on和on。 Mono完美地完成了核心.NET的工作,但是外围技术非常不完整,无论如何IMO都没有多大价值。

话虽这么说,我发现便携性非常无痛。事实上,我能够在一两天内将用于桌面的代码移动到移动设备上,这是非常好的,但之后我不得不花费大量时间进行优化。仅仅因为代码是可移植的并不意味着它将在所有平台上执行相同的操作!我认为最好在性能最敏感的平台上进行绿色字段编码,IMO是monodroid,因为它在移动设备上有JIT的复杂性,跨VM垃圾收集等等。

答案 2 :(得分:1)

你试过Mono Migration Analyzer (MoMa)吗?它不是终极解决方案,但它可以确保您在Mono运行时间内具有良好的可移植性。

答案 3 :(得分:0)

我使用MonoTouch(iOS),Mono for Android和Silverlight for Windows Phone 7完成了一些跨平台的.Net编码。我发现一个很好的方法是将我的代码基于Silverlight运行时,因为大部分是也支持Mono。

如果您只想定位iOS和Android,那么它们之间的主要区别就是UI。只要你远离任何与UI相关的东西,那么你的代码应该在两个平台上运行良好。

平台之间存在一个主要区别:在iOS上,您的代码是预编译的,因此对反射的支持有限。大多数东西都可以正常工作,但是你应该小心使用iOS上的反射代码。