为了最大化Mono代码的可移植性,我应该注意哪些约束?
本文关键字:约束 我应该 最大化 Mono 代码 可移植性 | 更新日期: 2023-09-27 18:10:34
我有兴趣使用Mono编写一些跨平台代码,以瞄准移动iOS和Android运行时。
我已经仔细阅读了Mono和MonoTouch网站,但没有看到任何特别建议不要使用的方法,或者应该避免的Mono钩子。然而,这似乎好得令人难以置信。
为了确保代码的最大可移植性,在这个项目中我应该注意哪些限制?
API wise你得到一个非常相似的基类库 (BCL)当使用MonoTouch或Mono Android (M4A),因为两者共享相同的移动配置文件(它最初是基于Silverlight配置文件和增强使用更多的FX 4.0 API)。
有很多常见的代码。BCL的差异很小,但有些确实存在,主要是因为在iOS设备上运行需要一些妥协,这产生了一些限制。
在BCL之外,MonoTouch和M4A都为它们的平台提供绑定。例如,MonoTouch提供了MonoTouch .dll,它绑定了大多数iOS(基于c或基于objective)的API。这部分在Android的Mono上不起作用(M4A提供的Android绑定也是如此)。
这就是你需要想出一个设计来最小化差异的地方。在许多情况下,最不同的方面是用户界面,有一些方法,其中许多是基于MVC(例如MonoCross),使开发人员更容易,同时为每个平台提供本机外观和感觉。
除了UI之外,要养成确保外部依赖具有跨所有所需平台运行的变体的习惯,或者准备好将它们提取出来。
对我来说,陷阱是:
- 压缩 -在silverlight中不可用,用户sharpziplib如果需要(我知道你不是针对silverlight,但以防万一。)
- 序列化 - Protobuf-net是你的朋友。
- Storage——这是最棘手的。你是使用普通IO还是隔离存储,或者一个东西在一个平台上,另一个在另一个平台上另一个?同时,mono。Sqlite几乎可以在任何地方工作,除了onSilverlight,所以要有一个应急计划silverlight,如果需要。
- 发明于MS -忘记这些东西。WCF,实体框架;SQL- ce, LINQ到SQL,等等。Mono完美地完成了。net的核心工作,但是外围技术非常不完善,在我看来没有多大价值。
话虽如此,我发现可移植性令人惊讶地无痛。事实上,它非常棒,以至于我能够在一两天内将原本用于桌面的代码转移到移动设备上,尽管之后我不得不花费大量时间进行优化。仅仅因为代码是可移植的并不意味着它在所有平台上的表现都是一样的!我认为最好在对性能最敏感的平台上进行绿场编码,在我看来,这种平台是monodroid的,因为它在移动设备上具有JIT的复杂性,跨vm垃圾收集等等。
您尝试过单声道迁移分析器(MoMa)吗?这不是最终的解决方案,但它可以确保您跨Mono运行时的良好可移植性。
我使用MonoTouch (iOS)、Mono (Android)和Silverlight (Windows Phone 7)编写了一些跨平台。net代码。我发现一个很好的方法是将我的代码建立在Silverlight运行时上,因为大部分代码也支持Mono。
如果你只想瞄准iOS和Android,那么它们之间的主要区别就是UI。只要你远离任何与UI相关的东西,那么你的代码应该可以在两个平台上运行良好。
这两个平台之间有一个主要的区别:在iOS上,你的代码是预编译的,所以对反射的支持有限。大多数的东西工作得很好,但你应该小心在iOS上使用重反射代码。